Blog

The Monolith vs. Microservices Debate

2025-12-20

We Have More Microservices Than Developers

Here is an opinion based on my daily routine: if your team has more microservices than actual human beings, you are going to spend your days doing infrastructure chores instead of shipping software.

At some point, the software industry convinced us that monoliths are legacy and microservices are the future. But in my day-to-day work, I see the opposite.

If you are a team of five developers managing thirty microservices, you don't have a modern architecture. You have thirty tiny codebases that are slowly drifting out of date.

The Daily Chore of Upgrades

In a monolith, upgrading a library is a one-time task. You run the upgrade, fix three compilation errors, push to main, and you're done.

In our current world of microservice overload, a simple security patch is an ordeal:

  1. You get a Dependabot alert for a shared package.
  2. You open PRs in twelve different repositories.
  3. You wait for twelve separate CI/CD pipelines to build.
  4. You coordinate twelve deployments, hoping you didn't break a contract somewhere.

By the end of the day, you haven't written a single line of feature code. You've just updated dependencies. When you have more services than people, maintenance becomes your full-time job.

Local Development is a Nightmare

How does local testing work in a massive microservice stack?

It usually looks like this: you want to check a small frontend change, but to run it, you need the Auth service, the User service, the Billing service, and the Notification queue running on your local machine.

You end up running Docker containers that eat up 100% of your RAM, or you fight with SSH tunnels to a shared staging environment. When setting up a dev environment takes half a day, developers stop testing locally and just "test in prod."

My Opinion: Keep it in One Place

Microservices make sense for giants like Netflix or Amazon, where thousands of engineers work on the same product. It lets teams deploy without stepping on each other's toes.

But for the rest of us, a Modular Monolith is simply better.

Keep your code in one repository. Share one database. Deploy it as one single unit. If you want to keep the code clean, use strict folder boundaries (/src/billing, /src/users).

If your team is small, prioritize developer velocity. Don't build distributed systems until you have the headcount to actually maintain them.