Summary: A popular idea holds that a team must first master a good modular monolith before it's "allowed" to build microservices. Fritzsche's objection is to the framing: it turns an architectural decision into a maturity ladder. Microservices are not a next level, a reward for experienced teams, or a promotion — and a modular monolith is not a training phase. Both are context-driven choices about where to place boundaries and responsibility. The question is never "what comes next," but "what fits the boundaries, responsibility, and organizational reality of the system being built."

Not a maturity ladder

Lewis and Fowler described microservices as services built around business capabilities, independently deployable through automated delivery, with decentralized control, decentralized data management, product ownership, and design for failure. A monolith is deployed as one unit. These are different ways of placing boundaries — not beginner and advanced versions of the same architecture. Skills clearly matter: a team building microservices needs to understand distributed communication, operational failure, monitoring, automated deployment, and the consequences of independently managed data. But those capabilities describe what's required to operate the chosen architecture responsibly — they don't create an educational sequence the team must complete on a monolith first.

Crucially, neither shape guarantees good boundaries on its own. A single deployable unit can contain cleanly separated capabilities or deeply coupled code and shared data structures. Separating code into services doesn't automatically produce autonomy — several services can still require coordinated deployments, share a database, or depend on each other for every operation. Engineering maturity affects how well an architectural choice can be implemented. It does not decide which architecture the business needs.

What the monolith-first argument gets right

The monolith-first position isn't wrong — it's contextual. Fowler grounded it in two concerns: the cost of running a distributed system while a product is still being validated, and the difficulty of identifying stable service boundaries before the domain is understood. Moving functionality between modules inside one process is easier than moving behavior and data between deployed services. So a modular monolith is a sensible option when product direction is uncertain, the domain is still being explored, and boundaries are expected to change. That's a contextual argument, not a universal law — and Fowler acknowledged the counterargument: starting with microservices can be right when the intended boundaries are already understood, particularly when replacing an existing system.

When the target architecture is already known

Not every new system begins with an unknown domain. A company may be replacing an application whose business responsibilities have been understood for years; different capabilities may already have separate ownership, release authority, and availability requirements. These conditions don't automatically make microservices correct — they provide evidence that can support the decision. A future need to "scale" is not enough: the relevant question is which part needs to scale differently, on what measurements, and whether independent scaling produces a meaningful benefit. Where the need for independent deployment is already concrete, building a monolith first "because the team has to learn from it" isn't a technical argument — it replaces the actual constraints with a generic prescription.

Microservices depend on organizational reality

Sam Newman treats independent deployability as the most important principle and ties domain boundaries to autonomy: once high-level boundaries are agreed, the responsible team should decide how the capability is implemented within them. The relevant property is not the number of repos, processes, or containers — it's the ability to change a capability without forcing coordinated changes elsewhere. Mel Conway's 1968 How Do Committees Invent? connects system structure to organizational communication structure (Conway's Law); in this context it's a way to check whether intended service boundaries are supported by how responsibility is actually organized. Amazon's "you build it, you run it" is the concrete example of end-to-end ownership: the people making a change also see how it behaves in production.

The failure mode: a service can be technically deployable while the responsible team has no authority to deploy it — depending on a central ops group, a shared database team, an architecture board, and several approvals. Then the process boundary exists but the intended autonomy doesn't. Service ownership that ends at the source-code repository is not end-to-end ownership.

Independent deployment must buy something

The defining characteristic of microservices isn't size — it's the ability to change and deploy selected capabilities independently, and that independence is valuable only when something actually needs to be independent. Separate deployment matters when release schedules genuinely differ; separate operation when responsibilities or availability requirements differ; separate scaling when measured resource profiles justify it; technology diversity when a capability benefits enough to justify the support cost. Each benefit is conditional. So the vague claims must be made concrete:

  • "Microservices will help us scale" → Which capability has a different load profile? What evidence? Can it scale without scaling its dependencies? Who owns its capacity?
  • "Microservices allow independent deployment" → Who needs to release independently? Can that team change its service without coordinated changes elsewhere? Does it own the data required for its decisions?

The architecture becomes defensible when these questions have concrete answers. And a collection of services that must always be released together has distributed the application without achieving the one property that defines microservices.

A modular monolith can be the destination

A modular monolith isn't training wheels — it can be the final architecture when coordinated deployment is acceptable, internal boundaries are sufficient, and distribution would add cost without useful independence. Microservices can also be the initial architecture when the relevant boundaries, ownership, and operational reasons are known. Architecture may change as the business changes, but that change is not a promotion: a system can stay a modular monolith, separate a few capabilities, begin with independent services, consolidate services, or combine shapes. Fowler cautions against treating monoliths and microservices as a binary — they're regions in a broader architectural space. There is no required arrow from one to the other.

Fritzsche's 2023 Microservices The Million-Dollar Mistake Your Company is Making focused on the infrastructure, operational, and organizational costs companies underestimate. He now states the point more precisely: the mistake is not choosing microservices — it's choosing them without a concrete purpose, and equally, rejecting them merely because a team hasn't first completed a prescribed monolith phase. Architecture should be justified, not earned.