Why I No Longer Use Microservices

I discovered microservices at a very early stage, and it didn’t take long for me to be amazed by all the benefits this architecture promised for businesses. However, it’s been years since I’ve chosen it for my new projects because, in practice, the costs tend to outweigh the benefits.

1. Expensive, very expensive

Anyone who’s seen an AWS bill for a microservices architecture knows what I’m talking about. What it has in sophistication, it has in cost. I’ve seen bills of several thousand dollars that could have been reduced to a few hundred if a monolithic architecture had been chosen. What makes it so expensive? Every service, no matter how small, has minimum hardware requirements that, when multiplied, quickly inflate the cost. On top of that, the orchestration and communication between these services add more dollars to the final bill.

2. Hard to develop

What benefits large companies is painful for smaller ones. In a large company, having small services speeds up the delivery cycle. However, for a startup with a small team, maintaining and developing numerous services becomes much more costly, as a single person might end up managing multiple microservices at once.

3. Complex to debug

A bug in production can turn into a nightmare with microservices. A single user request can pass through several services, making traceability highly complex. Additionally, replicating the case in a local development environment is, in many cases, nearly impossible.

4. Exaggerated latency

The idea that each microservice is a black box where the only relevant thing is its API sounds great. However, in practice, communication between microservices is often disastrous in terms of response times. No matter how well designed our system is, user experience is non-negotiable.

5. Low code reuse

Each microservice has its own encapsulated logic. So what happens when we need to reuse code across services? Many times, I’ve seen code duplicated again and again. Other times, “commons” or “utils” libraries emerge, turning into a grab bag where anyone can throw in anything, and many microservices end up depending on them, with all the pros and cons that entails.

6. Hard to update

When the day comes to apply, for example, a security patch to a common dependency used in almost all microservices, you have to go through each one, update the dependency, go through the corresponding release cycle, and monitor the production deployment. Now, multiply this by the number of microservices you have.

7. Ah, but Netflix…

Whenever someone dares to question the microservices architecture, the typical comment appears: “Ah, but Netflix has thousands of microservices and they’re not complaining.”" Yes, that’s true, but nobody else is Netflix except Netflix. In fact, it’s highly unlikely that your company needs anything remotely similar. For most startups, the cost of having such an over-engineered architecture will mean bankruptcy.

Long live the monolith.