Concerning Microservices...

I have been in the industry for some time now. Seen giant monoliths, seen distributed monoliths, seen a lot of messes. Microservices are, in most cases I have seen, a technical solution to a people problem. That is their only valid use case, and it is not a “great” one even in the best circumstances.

People try to give scaling arguments or some technical mumbo jumbo about why they are definitely needed. These are engineers working at big tech companies where “I will rewrite this into a Rust microservice” is their ticket to the next promotion. It does look good when you add “reduced p99 by 5% by rewriting X” to your performance review. It is the key to becoming an L5 engineer. However, all the technical reasoning they give is actually to convince their managers. Unfortunately, all the newcomers read these posts and believe them. Now there is a full generation of developers that want microservices and treat them as gospel, a solution to all problems.

This is not true.

It is resulting in pre-revenue startups building their architecture around microservices with unbelievable operational overhead. We need to stop overcomplicating things. Monoliths scale great when you do not have a dedicated platform team and an army of SREs. When you have one service to deploy and one service to rule them all, a couple of product-focused engineers can deploy and maintain it pretty easily. Every new deployment pipeline and environment means new things to keep in your mind, new edge cases, new infrastructure to maintain. Always remember: more moving parts = more things that can fail.

The Scaling Argument

When it comes to independently scaling things, you do not need to independently scale anything until you ACTUALLY have millions of users. Not “hey I WILL have millions of users, I need to be ready” - actually more than a million users, and throwing a couple hundred dollars more to Jeff Bezos is not solving your issues. The engineering time you will spend on maintaining microservices is going to cost a lot more than what you would spend on just going to a higher tier machine in your cloud.

So What Do Microservices Actually Solve?

Now that we have sufficiently criticized microservices, what do they actually solve?

They solve “release trains” and getting frustrated at the other team next door when they had a bug in the release and now your changes have to be reverted with theirs as well. This is a common problem as a company and the engineering effort gets bigger. Especially apparent when you do not have a single webapp you can quickly deploy and revert. Think of any sort of on-premise deployed apps or, worse, mobile apps that need to go through App Store review processes. These are lengthy and not easy to revert.

That is why, instead of continuous integration, most of these companies chose to create a “release train.” You have multiple teams working on different features. They all finish their independent tasks and everything gets merged into a release branch. This is the build that gets shipped out to millions of users around the world. Now imagine if one of the teams introduces a critical bug. You have to revert everything. Teammates get frustrated, targets are not hit, everybody is at each other’s throats because nobody can get their Christmas bonus.

Microservices are great at solving this problem. Each team can own their own parts and release at their own cadence. Nobody stepping on each other’s toes and nobody blaming each other. Companies that are successful with microservices architectures have a lot of different teams solving different problems. They might even have different agile methodologies, one working in 2-week sprints while another works in kanban. The company now has a lot of levers to play around with in terms of productivity and effectiveness for each different problem.

The Tradeoffs

This is all good, but it is important to remember that everything in life comes with tradeoffs. Microservices are not free, both from an infra cost perspective and from a maintenance burden perspective. More things mean more things can fail. You now have to do HTTP or gRPC calls instead of function calls. This comes with a lot of overhead. You now need a platform team that will create tools for other teams to reliably deploy to a somewhat uniform architecture. And you need some sort of uniformity because the new SREs you will need to hire will need training and well-maintained playbooks.

The Bottom Line

So to summarize, microservices are NOT useless by any means. They are useless for 90% of the companies that use them, and if not designed correctly, they become a chimeric hydra where each head speaks a different language.

Before you reach for microservices, ask yourself: Do I have a technical problem or a people problem? If you cannot point to multiple teams stepping on each other’s toes, release trains causing friction, or genuine scaling bottlenecks that a bigger machine cannot solve - you probably just need a well-structured monolith.

Build simple. Ship fast. Split later when you actually need to.