Microservices: Myths and Truths

While microservices allow for independent scalability, that is most often unnecessary. A replicated monolith will scale as well as a microservice 99% of the time. Unutilised code lying around in memory has a negligible footprint. A system of microservice clusters will consume more resources than a monolith cluster. The only scenario where microservices have an edge is when a part of the system is starving other parts of resources, but that means that the system is already overloaded.

Fault tolerance: only if “architected” for it

Replicating a single microservice for fault tolerance is no better than replicating a monolith. But a microservice based system could be designed to function without all of the microservices.

Any business processes spanning several microservices will be less reliable than their monolith counterpart. That is because the probability of one of several machines failing is higher than a single machine failing.

Simplicity: outright lie

In microservices complexity is moved from the design to the architecture. Architectural complexity is much more difficult to handle.

In addition to that the overhead of having a distributed system significantly increases the overall complexity.

When switching to microservices, the overall complexity of the system will increase, if architected properly, the complexity faced by each team will be lower. But only if architected properly.

Developer productivity: myth, unless you were already struggling

The overhead with dealing with a distributed system involves retrieving endpoints, marshalling objects, properly handling communication faults, propagating context, thinking about latency, consistency etc. Working on a distributed system is always significantly slower than working on a healthy monolith. But if the monolith is a big lump of spaghetti code where the build is constantly failing after dumping meaningless logs for 45 minutes, enforcing segregation through microservices could prove to be the lesser evil.

Knowledge burden: truth, provided a good separation of concerns

When microservices are loosely coupled teams don’t need to know about the internals of other teams’ microservices. However, when microservice boundaries break cohesion, introducing a feature in one microservice may require adjusting several other microservices. On the positive side, this will force your architecture to evolve towards loose coupling by punishment.

Faster CI/CD: truth for larger projects

Building individual microservices is faster than building the whole system. If your monolith is not too large and you’re trying to squeeze a few seconds from the build, then you will not see a difference.

More stable builds: truth

The probability that the build of an entire monolith will break is higher than the probability that a single microservice will break. However, this still leaves the question of end to end correctness open. Is the probability of the application being broken higher?

Heterogeneous environment: myth

Having different stacks across different microservices becomes a knowhow management problem. The more diverse the technical solutions, the less synergy among the developers. Most microservice projects benefit from enforcing the use of a single development stack.