tldr: “microservices - not a free lunch”
📰 https://www.feval.fr/posts/microservices/ –> read article for the full dish, it’s really good
benefits of microservices and how to get them
resiliency, HA, low coupling, agility
Most of what a microservice architecture brings can also be achieved with other solutions…a carefully planned application architecture
Containers and infrastructure as code can also be used with or without a microservice architecture. And in fact, they tend to be simpler to implement, since the networking is straight forward and the number of configurations is less important. They still bring the benefits of constructing and destroying environments at will, and facilitating the creation of development environments.
Build automation, and frequent releases, can be achieved through increased focus and reduced WIP, small batches, atomic change flow, and reduced coordination.
challenge - coordination
Next thing you know someone will start asking “how do we orchestrate our deployments to manage dependencies between services?”. This is the software version of hell on earth, also called a distributed monolith.
Each service needs to remain independent, and at the same time guarantee some stability to its consumers. Each time a service modifies its API, its consumers need to be updated as well. But these might not be known, and the upgrade of their clients should not be on the critical path to delivering new features. The direct consequence is that each individual microservice’s API needs to be versioned individually, and old versions need to be maintained for a while. This creates friction to change, which ironically might reduce your agility. The fact that cross service interaction is API based also removes all those nice refactoring features from your favorite IDE, when you want to refactor across services
challenge - performance
Since communication is happening over the network rather than in process, latency for each call is counted in 10s or 100s of milliseconds rather than fractions of nanoseconds. Assuming 100ms per service call (which isn’t unrealistic under load), if a call composes 3 services, that’s already 300ms in networking alone
challenge - organzational
They require an organization shift to autonomous, cross-functional teams
They require a change of process and practices. From a few large releases once in a while, to a lot of small releases often. From ticket-based provisioning, to self-service coded infrastructure.
The success of a microservice architecture depends on the capacity of organization and process to change, and those are the hardest things to reform.
Management also needs to be comfortable with refactoring early on, or even starting over if
things are really badthe learnings are strong. This is not natural, and is a skill that need to be acquired.
when to use
it might grow in the future, and have entire domains added to it ; in which case, switch to microservices when they actually approaching the threshold [of needing them]