Summary: Written by an early microservices champion who spoke at conferences and guided clients toward the architecture, this 2023 piece is a reversal born of a decade on the frontline. "Microservices are not a one-size-fits-all solution." The dream — independent teams delivering value rapidly and autonomously — collides with three realities: the infrastructure investment companies underestimate, a "DevOps culture" that's often cosmetic, and above all Conway's Law, which dooms centralized enterprises that adopt a decentralized architecture without decentralizing themselves.

The cost companies underestimate

Adopting microservices demands substantial infrastructure investment — not just financially, but in time and human resources. Maintaining the delicate balance a microservices architecture requires means pouring resources into a sophisticated DevOps setup. Companies routinely underestimate this toll before committing.

The cosmetic DevOps trap

In its ideal form, DevOps is a cultural shift where developers and operations collaborate seamlessly. In practice, many enterprises create separate "DevOps" squads to manage Kubernetes clusters, centralized CI/CD, infrastructure, and automation — leaving developers in a ready-made but restrictive environment, far from the promised autonomy. The gap between dev and ops persists under a trendier name; adding Infrastructure as Code doesn't dissolve the silo, it relabels it. In the true spirit of microservices, DevOps should be a role within each development team, not another team — that's what provides autonomy and rapid decision-making. (This is the same "you build it, you run it" ownership principle that Microservices Are Not the Next Step After a Modular Monolith later makes central.)

Conway's Law is the deciding factor

Larger organizations incline toward centralization — standardization and control override the autonomy microservices are supposed to bring. Decision-makers enforce strict rules on tech stacks and pipelines, creating an environment antithetical to the architecture's spirit. The root cause is Conway's Law: the structure of a software system reflects the social structure of the organization that produced it. A typical large enterprise is an intricate web of interconnected departments under a top-down hierarchy. Asking that organization to run an architecture that thrives on small, decentralized, cross-functional teams is "like trying to fit a square peg into a round hole." The centralization and tightly-coupled interdependencies of large enterprises run directly contrary to the philosophy of microservices — so they drain substantial resources trying to reap benefits they're structurally unable to obtain. The problem isn't the tool; it's forcing the tool into an environment it's not suited for.

Where microservices do work

Fritzsche is explicit that he isn't calling microservices inherently flawed — he's seen them work wonders where conditions are suitable. Start-ups and smaller companies with less bureaucratic inertia can genuinely harness the benefits. Implementing microservices isn't merely about breaking a monolith into smaller services; it's about understanding the readiness of the organization, the flexibility of the infrastructure, and the willingness of people to adapt.

No silver bullets

After nearly a decade on the frontline: "there are no silver bullets in software architecture. Each choice comes with its trade-offs, and the shiny new solution isn't always the best fit." The appeal to decision-makers is to pause before riding the latest trend and ask, "Does this really make sense for us?" Technology is a tool that serves the organization — not the other way around. Microservices should adapt to a business's needs, culture, and long-term vision, not force the business to adapt to them. The most effective solution is often a balanced approach that takes the lessons of both monoliths and microservices.