You're evaluating whether to split your monolith into microservices. The pressure is there - maybe from the team, maybe from leadership, maybe from what you're reading. Or someone just declared, "Microservices are the solution, decision makers never listened"
Here's what the industry's most credible voices actually say about this decision.
Martin Fowler analyzed microservices adoption patterns and found something stark: almost all successful microservice stories started with a monolith that got too big. Almost all systems built as microservices from scratch ended up in serious trouble.
Not "some." Almost all.
He calls it the "MicroservicePremium" - the cost of managing distributed services that slows down teams and makes monoliths the better choice for simpler applications. Even experienced architects struggle to get service boundaries right at the beginning.
Sam Newman wrote the literal books on microservices ("Building Microservices" and "Monolith to Microservices"). His recommendation? Start as a single deployable unit. Use microservices only when you're convinced of the benefits for your specific system.
He's explicit: the single-process monolith has real advantages. Simpler deployment. No distributed systems pitfalls. Simpler developer workflows. Easier monitoring and debugging.
Here are some useful metrics:
Sam Newman explicitly calls out "customer-installed and managed software" as a scenario where microservices become even harder.
Whether your customer installs it or you do it for them, someone ends up in a servicing nightmare . Different environments, remote debugging, version chaos across installations. (SOUND FAMILIAR :) )
Microservices on-prem: orchestrate multiple services across environments you don't fully control.
Can it work? Yes - with proper orchestration that abstracts the complexity. But you need that infrastructure built first. And you still need a legitimate reason (e.g. customer specific functionality) beyond "microservices are modern."
A small team can spend more time managing infrastructure than building features. Five engineers end up maintaining pipelines and debugging network issues instead of shipping product.
Performance degrades too. In a monolith, data access takes ~1 microsecond. In microservices, that same operation becomes JSON serialization + DNS lookup + network calls = 10-20 milliseconds. That's 10,000x slower for what used to be a function call.
However, these costs become acceptable when the value outweighs them.
Not when someone reads a blog post. Not because Netflix does it. When you have actual problems that microservices actually solve.
Your monolith isn't "not good enough." Monolithic architecture doesn't mean poorly designed. With proper modular design, you get reusability, easy refactoring, and organized dependencies - without distributed systems complexity.
The question isn't "should we use microservices?" The question is: do you have 15+ backend engineers, clear service boundaries from years of operation, mature DevOps infrastructure, and are these services deployed on-prem for each customer and specific scaling problems that a monolith can't solve?
If not, you're optimizing for problems you don't have while creating problems you can't solve.
Get the latest insights on architectural intelligence and platform updates.
3 min read
Code preserves what was built. It does not preserve why. AI coding agents make this gap worse, not better - they read the artifact and not the input. The fix is not better diagrams or longer system prompts. It is keeping the reasoning alive next to the code it explains.
6 min read
Sequoia Capital identifies a $10 trillion services automation opportunity, but calls this the "steam engine moment"—the foundational AI technology exists, but we're still decades from systematic deployment. Early agent-first implementations show 40-85% efficiency gains, yet success requires architectural expertise concentrated among technical specialists. The companies that democratize this knowledge—making agent system design as accessible as ChatGPT—will become the Westinghouse of the cognitive revolution.
5 min read
The software architecture community is undergoing a quiet revolution. Industry leaders report a fundamental shift from traditional "ivory tower" architects who control decisions from above, toward collaborative enablers who empower teams through coaching and guidance. This evolution isn't diminishing the architect's role—it's expanding their impact.
