Microservices: the management cost nobody talks about
Moving to microservices is not purely a technical decision. It introduces real operational load on the organisation that rarely appears in the pitch.
Microservices have been one of the most discussed architectural approaches for the past two years. Netflix, Amazon, SoundCloud - every major technology company has a story about how decomposing the monolith into small independent services gave them speed and scale.
I regularly see how these stories influence decisions at companies that are not Netflix. A team proposes a move to microservices, the case sounds compelling, the project starts. A year later things turn out to be harder, not easier.
I am not against microservices. I am against making that decision without understanding the full cost.
What actually gets harder
Each service is a separate process that needs to be deployed, monitored, logged, and updated. It has its own configuration, its own lifecycle, its own dependencies. When there are five services, that is manageable. When there are fifty, it becomes a dedicated infrastructure problem.
Locally this looks like a technical challenge. Organisationally it is a question of ownership: who is responsible for each service, who makes decisions during incidents, who watches interface compatibility between teams.
A monolith, with all its faults, is transparent. Microservices require explicit contracts, explicit owners, and explicit processes at every seam between components.
The hidden costs
The first hidden cost is network calls instead of in-process calls. What was a function in the monolith is now an HTTP request with everything that implies: latency, failures, the need to handle a partner service being unavailable.
The second is distributed debugging. When something goes wrong, the problem can be in any of several services or at the point where they interact. Investigating that requires a centralised logging and tracing system - without it, debugging becomes detective work without evidence.
The third is data management. In a monolith you have one database. In microservices each service often wants its own. That raises synchronisation and consistency questions that simply did not exist before.
When it is justified
A microservices architecture is justified when you have genuinely independent parts of a product with different rates of change, different scalability needs, and - crucially - when you have a mature engineering culture with automated deployments, proper monitoring, and real experience operating distributed systems.
Without those, you do not get the flexibility of microservices. You get the complexity of microservices on top of a monolith-era organisational culture.
Companies like Netflix started with a monolith, moved gradually, and built tooling around their own specific needs. Their story is not a recipe. It is a report on years of work.
Questions before deciding
If a team proposes a move to microservices, here is what is worth clarifying first:
- What exactly does not work in the current architecture, and why will microservices solve precisely that?
- Do we have automated deployment and testing that we can actually rely on?
- Who will own each new service?
- How will we investigate incidents in a distributed system?
- Are we ready for increased operational load during the first six months after the transition?
Answering these questions will not cancel the decision. It will make it a conscious one.