The monolith default
Ninety percent of production software would ship faster and break less as one deployable than as the distributed system most teams reach for instead. Not for a first year before graduating to services. As the actual architecture, for as long as the product exists.
I watched a startup with fourteen engineers run nineteen services in production.
Each with its own repo. Its own deploy pipeline. Its own on-call rotation nobody quite staffed correctly. Its own copy of a shared library that drifted six months ago, unnoticed until a bug reproduced in exactly one of them.
Nobody can point to the day this became the architecture. It accreted.
One "let's just split this out" at a time, every decision reasonable on its own, and the sum of them a company now spending more engineering time on the seams between services than on the product living inside them.
Not a rare company, and that's the part worth sitting with. Closer to the median outcome of advice that was right for a small number of organisations in 2015 and has been repeated as a default for everybody since.
The claim, stated plainly
Ninety percent of production software would ship faster, break less, and cost less to run as a single deployable today than as the distributed system most teams reach for instead.
Not eventually. Not for a first year before you graduate to services.
As the actual architecture. Indefinitely. For as long as the product exists.
Hardly a contrarian position. Just one that rarely gets said in public, because the loudest voices in the room are usually describing what worked at a company two hundred times your size, at a stage you aren't at and mostly won't reach.
What the pitch always skips
Microservices are sold as a solution to organisational scale, and at organisational scale they are one.
What the pitch skips is that they're a tax on everybody below that scale, paid in a currency the slide never shows.
Network calls failing in ways a function call never could. A debugging session that used to be a stack trace and is now a tracing tool spanning five systems. A local dev environment needing six things running before an engineer can test one change. A deployment where "did the thing I shipped actually go out" is a real question with a real chance of no.
All of it real, and all of it daily.
The operating cost of the architecture, paid by every engineer on every change, whether or not the org is big enough to need what it bought.
Same bill the Kubernetes tax describes, one layer down.
The one earned reason
Exactly one good reason to split a service out.
Size won't do it. Language preference won't. "The codebase feels big" certainly won't.
A specific team needing to own a specific slice of failure, cleanly, because that slice carries an operational profile the rest of the system doesn't share.
Elsewhere on this site, the modular monolith gets made as the actual mechanism for getting what people are really asking for.
Short version. Clear ownership. Changes that don't ripple. A piece you can reason about without holding the whole system in your head. All of it available inside one process, enforced with module boundaries and a build that fails on a forbidden import.
The operational bill is what costs money, and the operational bill is the one part nobody is asking for when they ask for services.
What they want is boundaries. Boundaries come free inside one process. A network between two services never does.
Why this doesn't stick as advice
I've said some version of this to founders and watched most of them nod and do the opposite within a year.
Disagreement has nothing to do with it.
A monolith is a boring thing to have built. A service mesh is an interesting thing to have built. And in a hiring market where engineers pick employers partly on what they'll get to work on, boring architecture is a cost landing on a different line item from the one anybody is optimising.
A real trade-off. I don't think it's stupid.
I think it's usually made without anybody naming it, which means it's rarely made on purpose. And a decision this expensive deserves to be made on purpose or not at all.
The test, if you want one
Before splitting anything out, name the team that will own the new service, and the specific failure it needs to contain independently.
Can't do both in one sentence? You don't have a reason.
You have an architecture diagram resembling the ones you've seen at companies you admire, which is about the worst basis available for a decision this expensive.