The microservices conversation has matured. The decade of over-decomposition is behind us, the operational debt is in the open, and the industry has converged on a slightly embarrassing consensus: most organizations should not have built microservices in the first place. The interesting question now is not microservices vs. monolith. It is modular monolith vs. selective service extraction, and when the second is worth the cost.
The Real Cost Of A Service Boundary
Every service boundary is a contract, a deployment unit, a monitoring concern, an on-call rotation, and a network hop. Sam Newman's writing on monolith decomposition and Martin Fowler's Microservice Premium essay both anchor the cost-side of the conversation. The premium is real, it is paid every quarter, and most organizations underestimate it before extraction and overestimate the difficulty of paying it down after.
The Modular Monolith As Default
The modular monolith — one deployable, internally decomposed by domain modules with enforced boundaries — has quietly become the right default for most teams. The deployment story is simple, the operational footprint is bounded, and the modules can be extracted into services if and when extraction earns its keep. Shopify and DHH's 37signals have written extensively about running enormous businesses on monolithic Rails apps with no apparent shipping disadvantage.
When Service Extraction Earns Its Keep
Service extraction earns its operational cost in three specific situations. When a module has genuinely independent scaling characteristics — for example, a video transcoder or a search index that needs different hardware. When team boundaries demand independent release cadences that the monolith cannot accommodate. And when blast-radius isolation is load-bearing, usually for security or regulatory reasons. Outside those three, extraction usually does not pay back.
The Distributed Systems Tax
Once a service boundary exists, the team has to budget for the distributed systems tax: idempotency, retries, eventual consistency, distributed tracing, and the operational overhead of running a fleet rather than an instance. The CNCF's cloud-native landscape is a useful reminder of how much surface area teams sign up for the moment they cross a network boundary. The tools are good. They do not change the fact that the work is real.
Architecture As A Reversible Decision
The single most useful frame for these decisions is reversibility. Extracting a module to a service is mostly reversible if the boundary was good. Re-monolithing a fragmented mesh of services is much harder. So the cost-asymmetric move is to default toward the modular monolith, enforce module boundaries seriously, and extract only when the operational cost is clearly earned. The teams that take this path tend to outship the teams that go straight to microservices, by a margin that is no longer controversial.
Key Takeaways
- Every service boundary is a contract, a deployment unit, an on-call rotation, and a network hop
- The modular monolith is the right default for most teams in 2025-2026
- Service extraction earns its keep on independent scaling, independent release cadence, or blast-radius isolation
- Once a service boundary exists, budget for the distributed systems tax in full
- Default toward reversible architectural decisions; extraction beats re-monolithing on cost
- Most teams that went microservices-first should have stayed monolithic and extracted selectively