It's almost impossible to have a conversation about software architecture without someone bringing up microservices. Just look at the discussion over my last post. They have become the default example of both "good architecture" and "over-engineering," depending on who you ask.
What's interesting is that everyone seems to recognize a microservice when they see one, yet almost nobody can explain what actually makes something a microservice.
The impossible definition
How small is micro? Should a service do exactly one thing? Two? Is there a maximum number of lines of code? A thousand? Ten thousand? Nobody has convincing answers, because there aren't any.
The industry has spent years trying to define microservices by technical characteristics, but those characteristics are surprisingly vague and fuzzy. The boundaries aren't measured in responsibilities or number of deployments per day. They're measured somewhere else entirely.
And that's the important realization: microservices aren't primarily a technical abstraction.
The problem they're actually solving
Listen to the reasons people usually give for moving away from a monolith: deployments are slow, tests take too long, builds are painful. These are real problems, but none of them require microservices. Every single one can be improved while staying inside a monolith.
So why do organizations migrate anyway?
Because the bottleneck usually isn't technical. It's organizational.
As companies grow, dozens or hundreds of engineers need to work independently. Teams need ownership. They need to release on their own schedules without constantly coordinating with everyone else. Microservices create boundaries that mirror organizational boundaries. That's their real value.
Every benefit comes with a bill
Engineering is the art of managing trade-offs. Microservices are no exception.
You gain autonomy, but you lose centralization. Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?" Static analysis can often tell you. Once the code is spread across dozens of independent services, those answers become much harder to obtain.
The same pattern repeats everywhere. Communication between functions becomes communication over the network. A method call becomes an HTTP request. A compiler error becomes a runtime failure. Every distributed system problem — latency, retries, partial failures, serialization, consistency — suddenly becomes part of your application.
None of these costs are surprising. They're simply the price you pay for the flexibility that distributed systems provide.
The hidden communication cost
When people talk about communication overhead, they usually think about APIs talking to each other. That's only half the story.
The teams now have to communicate too.
Changing an API is no longer a refactor. It's a negotiation. Consumers need advance notice. Versioning becomes necessary. Old versions have to remain alive while everyone migrates. Database changes become coordinated efforts instead of straightforward commits.
The software isn't the only thing that's distributed anymore. The decision making is as well.
Choose them for the right reason
None of this is an argument against microservices. They're an excellent architectural choice in the right environment. Many successful companies simply couldn't operate without them.
But it's worth being honest about why they work.
If your primary problem is organizational scaling, microservices might be exactly the right answer. If your problem is purely technical, you should first ask whether you're reaching for a solution that's far larger than the problem itself.
Architectures become much easier to reason about once we stop pretending microservices are magic technical tools. They're organizational tools with technical consequences.
I made a video version of this argument, if you'd rather watch it: What even are microservices?
Thanks for reading.