Microservices Are Dragging Us Back
Tags: architecture, microservices, cluster
Published: 2021-07-21 12:01:19

---
title: Microservices Are Dragging Us Back
published: true
description: Inconvenient truth about microservices.
tags: #architecture #microservices #cluster
//cover_image: https://direct_url_to_image.jpg
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4juz640dl2cfux4ip4kn.jpg
---
(image courtesy of [Jonathan Farber](https://unsplash.com/@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](https://aws.amazon.com/solutions/case-studies/netflix/#:~:text=Netflix%20uses%20AWS%20for%20nearly,100%2C000%20server%20instances%20on%20AWS.). This is a tiny fraction from ~4 million physical servers (my estimate based on numbers from [here](https://aws.amazon.com/about-aws/global-infrastructure/#:~:text=Availability%20Zones%20(AZ%E2%80%99s)-,81%20Availability%20Zones,-7%20Local%20Zones) and [here](https://en.wikipedia.org/wiki/Amazon_Web_Services#:~:text=As%20of%20December%202014%2C%20Amazon%20Web%20Services%20operated%20an%20estimated%201.4%20million%20servers%20across%2028%20availability%20zones.)), 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.