CloudNative eXchange 2020
I attended the (virtual) CloudNative eXchange recently, and have put down my thoughts in this article, so that future me, work colleagues and anyone else can get a good overview of the conference, and have convenient access to the presentations.
There were a few common themes across the talks. The most common one was that a “Distributed Monolith” combines all the worst aspects of Monolith and Microservice architectures, and so should be avoid at all costs, but also that it is often the path you end up on if you don’t actively take steps to avoid it. The 12 factor app principles and Loose Coupling / High Cohesion were cited as the way to cope with this.
The Accelerate book was also mentioned multiple times, as it was the last time I went to a conference. The primary output of this book is that there are 4 key metrics that separate high performing software teams. All software teams at RES are now required to keep track of one of these metrics, and most also keep track of the others.
The SAGA pattern came up a lot, and addresses transactions over multiple services.
You can see all the talks on the conference website, and there are individual notes and links to presentations below.
Process automation in cloud native architectures
This was a very interesting talk, advocating for modelling processes explicitly (Orchestration, or Command Driven) instead of using an Event Driven pattern, where the process is implicit (Choreography).
An event driven pattern is usually quicker / easier to set up, so there can be an argument for it, but the implicit nature of it means that the process isn’t defined in any one place. This means that no one team / service is responsible for it. It also makes the process less visible, to see it you need to do a deep dive on the code, across multiple services, or spend time observing the run time behaviour of the system. It can also lead to a pinball architecture where the logic / events bounce around across multiple services in a chaotic manner. Emergent behaviour is another word for this.
The author runs a company that sells a Process Orchestration tool.
https://skillsmatter.com/skillscasts/14961-process-automation-in-cloud-native-architectures
Evolving to CloudNative
This states that looking at how far away your app is from the 12 factor principles is a good proxy for how hard it will be to move it to the cloud. It also says that the question about retiring an application, should not be “is it going to be retired”, but “when will it be retired”, as this aids decision making.
Generally evolving a ball of mud to a modular monolith to microservices is the way to go.
https://skillsmatter.com/skillscasts/14923-evolving-to-cloud-native
Designing Loosely Coupled Microservices
There are various types of coupling, such as run time, design time and infrastructure.
An example of a run time coupling is having to wait for a payment to complete before shipping an order.
A design time coupling means that services have to be deployed together, in lock step, such as a shared database.
We can use the Iceberg principle to help (expose as little as possible, encapsulate as much as possible), by using Postel’s Law / Tolerant Reader pattern (“Be liberal in what you accept, and conservative in what you send”). Interestingly the client api libraries generated by tools such as Swagger usually don’t adhere to this pattern, and will break upon any change to the api.
Another example was an order message with no total, so all services have to calcualte total themselves. This means that adding a covid surchage requires all services to change. This could be fixed by calculating the total in the Order service, and then the other services just use this, instead of calculating it themselves.
Infrastructure coupling means multiple services rely on the same infrastructure, so are all affected if it has a problem. For example kubernetes clustsers have limited resource, so if multiple services are all deployed in the same one, then one rogue service can cause problems for all of them. The same is true for database and queues and similar. Queues are often shared, but probably it makes sense to limit the blast radius, so potentially having a separate queue for a critical service, and maybe share a queue across less critical ones.
https://skillsmatter.com/skillscasts/14926-designing-loosely-coupled-microservices
Service Mess to Service Mesh
This was mostly an interesting demo of two Service Mesh’s, LinkerD and Istio.
A service mesh can do a lot of useful things, such as security, a/b testing, canary releasing, circuit breakers, observability and suchlike. However they are shared infrastructure, and they could double the run time cost, so need to weigh it up.
https://skillsmatter.com/skillscasts/14916-service-mess-to-service-mesh
Technologies for Microservices
Often there is a microservice for an api, and then another microservice for a front end. These two things will always change in lockstep, so it makes sense to combine them in to one service.
If a front end is showing data from multiple other micro front ends, then an interesting pattern is to add links on the page to the various services, and then have some javascript to replace the links with the content. This still works reasonably well when a service is down, as the rest of the page is still visible, and the link remains useful.
https://skillsmatter.com/skillscasts/14919-technologies-for-microservices
Event-Driven Microservices: The Sense, Nonsense and a Way Forward
This talk makes an interesting parrallel between Git and Event Sourcing. It also has a similar theme to “Process automation in cloud native architectures”, advocating for Events, Commands and Queries, instead of just events.
NodeJS, ML, K8s, and Unethical Face Recognition
This talk is a lot of fun, and gives you an idea of the sort of things that are possible with relatively little work using todays technologies.
https://skillsmatter.com/skillscasts/14914-nodejs-ml-k8s-and-unethical-face-recognition
CircleCI Demo
Cicrcle CI looks like a good cloud build server. It is more complicated than what we currently use (Appveyor and Azure DevOps), but it is also more powerful. If a build fails it is possible to rerun the build, but keep the virtual machine alive at the end, which you can then ssh into and debug. This is definitely a very useful feature, and would save the attempt a fix, commit the fix, see if the fix works cycle that we sometimes get in to.
The caching requires set up, which again means that it is more complicated, but it is also more powerful, allowing finer control and the caching of arbitrary things.
It runs things in parrallel by default during the build, and has vulnerability scanning.
There is a “Hold for approval” step, that can be used for a human to approve the build before it continues, which could be very handy for releasing.
How Cities Heal: Minneapolis 2021
This talk makes some points about the “defund the police” movement that need challenging. As a policy initiative, “defunding the police” means the reallocation of local and state resources away from law enforcement and into public services, designed to address issues of poverty, inequality and mental health. The stats clearly show that incarcerating more people and arming the police with tanks is not a good way of reducing crime, and it is better to tackle the socio economic factors that contribute or lead to crime.
https://skillsmatter.com/skillscasts/14922-how-cities-heal-minneapolis-2021
