Wednesday, December 31, 2025

The Monolith vs Microservices Debate: What the Data Actually Says

Murali Ganta

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's Data

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 Agrees

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.

The Team Size Threshold factor

Here are some useful metrics:

  • Microservices benefits appear only with teams larger than 10-15 backend developers
  • Below that threshold, monoliths consistently outperform
  • You need 2-3 developers per service for proper ownership (varies by complexity)
  • Small teams (1-10): monolith
  • Medium teams (10-50): modular monolith
  • Large teams (50+): microservices might make sense

The On-Prem Deployment Multiplier

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."

What "Premature Optimization" Actually Costs

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.

Real Companies, Real Results

  • Basecamp: Ruby on Rails monolith for nearly two decades
  • Shopify: Started as monolith, evolved to modular monolith, extracts microservices only for specific needs
  • Stack Overflow: 1.3 billion page views per month with a horizontally scaled monolith

The Actual Strategy

  1. Build a well-structured modular monolith
  2. Pay attention to modularity at API boundaries and data storage
  3. Understand your domain through real usage
  4. Split into microservices when you have clear organizational and technical scaling reasons.

Not when someone reads a blog post. Not because Netflix does it. When you have actual problems that microservices actually solve.

What This Means for Your Architecture Decision

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.

Sources

Back to blog