Microservices get proposed as an upgrade path the same way DevOps tooling does — as something a growing company is supposed to eventually adopt. For most teams, that instinct is backwards, and adopting it early trades a manageable problem for a genuinely hard one.
What microservices are actually for
The real problem microservices solve is organizational: multiple teams need to deploy independently without stepping on each other's code, and different parts of a system need to scale at wildly different rates. Large tech companies didn't adopt microservices because they're inherently better — they adopted them because thousands of engineers can't all safely commit to one codebase.
What it costs, upfront, for everyone
Network calls where you used to have function calls. Distributed transactions where you used to have a database transaction. Debugging a request that touches five services instead of stepping through one process. Deployment and monitoring infrastructure multiplied by however many services you've created. None of this is optional overhead — it's the price of admission, paid whether or not you needed the benefit.
The well-built monolith nobody talks about
A cleanly modularized monolith — clear internal boundaries, well-defined interfaces between modules, one deployable unit — gives most of the organizational clarity microservices promise, without the network overhead. Plenty of companies serve millions of users this way, and split into services only years later, when a specific, felt problem justifies it.
The actual signal to split
Not "we're growing." Watch for: one part of the system needs to scale independently and it's dragging the whole deployment down, or two teams are genuinely blocked from shipping because they share one codebase and one deploy pipeline. Those are real, specific, felt problems. "It seems like the modern way to do things" is not.
Where to start
- If you're one team of under fifteen engineers, default to a well-structured monolith.
- Enforce clear module boundaries now — it's what makes a later split easy if you ever need it.
- Split a service out only when you can name the specific scaling or team-boundary problem it solves.
- Expect the first split to be harder than it looks; budget real time for it.
