(image courtesy of Jonathan Farber)
The microservices are all the hype today. Everyone does them, everyone wants them, everyone looks for devs who know them. Any critique or, at least, attempt to look at them with sober view immediately attacked and blamed in all possible sins.
But there is a very inconvenient truth behind the hype - microservices is a terrible solution from a technical point of view.
This is hard to accept at first, but let's look into the roots: any system built with microservices is a distributed system. And microservices represent the simplest possible type of distributed system - a bunch of unrelated services somehow communicating with each other via unreliable channels.
It is a distributed system only because we've turned traditional SOA-based application inside out and replaced direct invocations with unreliable external communication.
Such a system is not designed for the distributed environment in the first place, it is still monolith by the architecture, even if we're applying DDD, CQRS, event sourcing, circuit breakers and other fancy acronyms and names. The whole rest "microservices design" is a constant fight with consequences of initial decision: such a system has no coordination, no centralized configuration, no consistency, no consensus, no monitoring or logging, no means to even know if all parts of the system is actually working or not. All these tools must be provided externally, and without them any microservices-based system will fail quickly, even if it will be able to start at all.
For some strange reason, we've thrown out 50 years of development of the distributed systems and started building the simplest and worst ones!
We forgot, that there are other types of distributed systems, for example, clusters. Built on top of modern distributed consensus algorithms like RAFT, PAXOS or some variant of distributed hash table, they provide high reliability, availability and scalability which is far beyond the wildest fantasies of microservices proponents.
If we look at one of the largest microservices-based systems built by Netflix, we may find that it uses more than 100,000 server instances. This is a tiny fraction from ~4 million physical servers (my estimate based on numbers from here and here), where each physical server can run several server instances because of virtualization.
The clustered systems are the real backbone which keeps all these microservices-based toys somehow working.
Perhaps it's time to reconsider the way in which we build our apps and make them really prepared for the distributed reality, instead of building systems from cardboard pieces glued together with scotch tape and chewing gum.
Top comments (3)
Resonates so very well with me. Whenever some system like a database goes down which is connected to all the micro services we had to manually check every single one that connected to it. So very true with respect to reliability issues Unless well maintained(which is a passion by the way)
Oh no. 😠Why are multiple microservices connected to the same database? One of the main points of microservices is that they're autonomous and problems affecting one shouldn't affect others.
We felt it to be too much to have a separate database container running for each of the micro-service. So we created a database used by that service but the database is in a common container. So couldn't help much on that