When Not to Use Microservices, Michael Féval

Some of my favorite bits ⬇️ from this great article

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 bad~~ the 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]