The Great Microservices Reckoning: Why 42% of Teams Are Quietly Returning to Monoliths

[eng_director_luis]

We need to talk about something that’s been quietly happening across the industry: the microservices retreat.

According to the 2025 CNCF survey, 42% of organizations that initially adopted microservices have consolidated at least some services back into larger deployable units. The primary drivers? Debugging complexity, operational overhead, and network latency issues that impacted user experience.

This isn’t a hot take from a blogger. This is survey data from the Cloud Native Computing Foundation itself.

Our Own Reckoning

I lead a 40-person engineering team at a Fortune 500 financial services company. Three years ago, we went all-in on microservices. We decomposed our core platform into 12 services because… well, because that’s what you did in 2022 if you wanted to be “modern.”

Last year, we consolidated back to 3 modular services. The results:

• Deployment time: 45 minutes → 12 minutes
• Debugging time per incident: 4 hours average → 1.5 hours
• AWS monthly costs: Down 35%
• Developer velocity: Features shipping 2x faster

Was I embarrassed? A little. Was our team relieved? Absolutely.

The Amazon Wake-Up Call

When Amazon Prime Video published their case study showing a 90% infrastructure cost reduction by moving their video monitoring from microservices to a monolith, it gave permission for the rest of us to have this conversation openly.

Even Amazon’s CTO Werner Vogels said it best: “Building evolvable software systems is a strategy, not a religion. And revisiting your architectures with an open mind is a must.”

If Amazon—the original poster child for service-oriented architecture—can admit that microservices weren’t the right fit for a specific use case, why are the rest of us still pretending?

The Real Problem: We Built for the Wrong Scale

Looking back at our microservices adoption, we fell into classic traps:

1. Team size mismatch: We had 8 developers managing 12 services. The emerging industry consensus is:

   • 1-10 developers → Build monoliths
   • 10-50 developers → Modular monoliths
   • 50+ developers → Microservices might be justified

2. No real scaling needs: We didn’t have different components that needed to scale independently. We just… assumed we would someday.

3. 60% overhead: According to DZone research, teams spend 35% more time debugging microservices than modular monoliths. For us, it was worse—we were spending more time on service mesh configuration than shipping features.

4. The deployment lie: 90% of microservices teams still batch deploy like monoliths anyway. We did. So what was the point?

The Modular Monolith: The Middle Ground Nobody Talks About

What we landed on was a modular monolith architecture:

• Clear module boundaries enforced through internal interfaces
• Separate database schemas within the same database
• Could theoretically extract to services if needed—but we haven’t needed to
• Single deployment but organized codebase

This gives us the architectural discipline without the distributed systems tax.

When Microservices Actually Make Sense

I’m not saying microservices are never the answer. They make sense when:

• You have 50+ engineers who genuinely need independent deployment
• Different components have wildly different scaling requirements
• You have a dedicated platform/DevOps team to manage the complexity
• You’ve actually hit scaling limits with a monolith (not theoretical ones)

For everyone else? The modular monolith is probably your answer.

Questions for This Community

1. Has anyone else gone through a microservices → consolidation journey? What triggered it?
2. How do you have this conversation with leadership who bought into the microservices vision years ago?
3. For those still on microservices: Are you genuinely seeing the benefits, or managing complexity for complexity’s sake?

Would love to hear from both sides. This isn’t about declaring winners—it’s about making honest architectural decisions for our actual contexts.

[cto_michelle]

@eng_director_luis, this resonates deeply. From the CTO seat, I’ve been watching this trend unfold across our portfolio companies and in conversations with other technical executives.

The Cost Visibility Wake-Up Call

For us, the reckoning started with finance. When we finally got granular AWS cost attribution by service, leadership asked a simple question: “Why are we paying $47K/month for a service that handles 200 requests per day?”

The answer was: because it was architecturally “correct” to separate it. That conversation triggered a broader audit.

Werner Vogels Got It Right

I keep coming back to what Amazon’s CTO said: “Building evolvable software systems is a strategy, not a religion.”

The key word is evolvable. The goal was never microservices for their own sake—it was building systems that could adapt. For many of us, a well-structured modular monolith is more evolvable than a sprawling mesh of interdependent services.

Our Current Approach

At my current company, we’ve adopted what I call “proven extraction”:

1. Start with a modular monolith - clear boundaries, but single deployment
2. Monitor for extraction signals - genuine scaling bottlenecks, not theoretical ones
3. Extract only when proven necessary - which for most teams means never

We’ve done exactly two extractions in three years. Both were driven by specific, measurable scaling requirements. Everything else stayed in the modular core.

A Word of Caution

I do want to push back slightly on the pendulum swinging too far. Some organizations are hearing “monolith good” and abandoning all architectural discipline.

The modular monolith only works if you maintain the modular part. Spaghetti code in a single deployment is worse than well-designed microservices.

The point isn’t that microservices are bad—it’s that we need to make architectural decisions based on our actual context, not industry hype.

What I tell my engineering leaders: Choose the architecture that lets you ship fastest today, with clear paths to evolve if you need to tomorrow.

[alex_dev]

This thread is hitting close to home. I’ve been on both sides of this, and I have to share what we went through.

The “Modern” Trap

Two years ago, I joined a startup where a team of 8 engineers had built 15 microservices. When I asked why, the answer was essentially: “Because that’s what modern engineering looks like.”

No one could articulate a specific scaling requirement. No one had measured whether we needed independent deployments. We just… assumed it was the right thing to do.

Where Our Time Actually Went

Here’s the breakdown that made me realize we had a problem:

• 40% - Building features
• 30% - Managing infrastructure (Kubernetes, service mesh, secrets, networking)
• 20% - Debugging distributed traces across services
• 10% - Meetings about how services should communicate

We had built a system optimized for a 50+ person team, but we had 8 people. The overhead was crushing us.

The Migration That Changed Everything

We spent 3 months consolidating into a modular monolith. It wasn’t easy—we had to untangle a lot of service-to-service dependencies. But the results:

• Feature velocity: 2x improvement. We shipped more in Q1 after the migration than all of the previous year.
• On-call burden: Incidents became 10x easier to debug. One codebase, one log stream, one mental model.
• Developer happiness: Our team survey scores on “ability to do my job effectively” went up 35 points.

The Team Size Heuristic Is Real

Those guidelines @eng_director_luis mentioned—1-10 devs = monolith, 10-50 = modular monolith, 50+ = maybe microservices—I wish someone had told us this earlier.

We were a team of 8 building like we were Netflix. We weren’t Netflix. We were a startup trying to find product-market fit, and our architecture was actively working against that goal.

What I Tell Junior Engineers Now

When someone asks me whether to use microservices, I always ask: “What specific problem are you solving that requires a distributed architecture?”

If the answer is “it’s more scalable” without specific numbers, or “it’s more modern” without specific requirements—those aren’t good enough reasons.

Start simple. Add complexity only when you’ve earned it.

[vp_eng_keisha]

Really valuable thread. I want to add an organizational perspective that I think gets overlooked in these architecture conversations.

Conway’s Law Is Always Operating

The old adage is true: “Organizations design systems that mirror their communication structures.”

What I’ve observed scaling from 25 to 80+ engineers: microservices work when they map to real team boundaries. They fail when they’re imposed on teams that don’t have the organizational structure to support them.

Our Hybrid Reality

At my current company (EdTech, ~80 engineers), we have:

• 2 true microservices: Our authentication system and our payment processing. Both have dedicated 4-person teams, genuine regulatory requirements for isolation, and wildly different scaling profiles.

• Everything else: A modular monolith with clear domain boundaries.

This isn’t ideological—it’s pragmatic. We extracted those two services because we had specific, measurable reasons to do so. The rest stays consolidated because the overhead wasn’t worth it.

The Hiring Problem Nobody Talks About

Here’s something that frustrates me: “microservices experience” has become a checkbox on job descriptions. Candidates optimize their resumes for it. Hiring managers filter for it.

The result? We’re training an entire generation of engineers to believe that distributed systems are the default, when they should be the exception.

I’ve started asking candidates: “Tell me about a time you chose NOT to use microservices.” The thoughtful answers tell me more about their judgment than any distributed systems trivia.

When to Extract: My Decision Framework

When my teams propose extracting a service, I ask:

1. Is there a dedicated team? If not, you’re creating shared ownership nightmares.
2. Are there genuine scaling differences? “Maybe someday” doesn’t count.
3. Are there regulatory or security requirements? This is often the best reason.
4. Will this service need independent deployment cadence? Not “could” but “will.”

If the answers aren’t clearly yes, we keep it in the modular monolith.

The Bottom Line

Architecture should serve the organization, not the other way around. Match your technical complexity to your organizational complexity—and for most teams, that means far fewer services than you think.

[product_david]

Reading this as a non-technical executive—I appreciate the honest conversation. Let me add what this looks like from the product side.

What I Actually Care About: Velocity

I don’t have strong opinions about microservices vs. monoliths in the abstract. What I care about is: how fast can we ship features to customers?

At my previous company, our engineering team was proud of their microservices architecture. But every new feature required coordination across 3-4 teams. What should have been a 2-week project became a 6-week project because of cross-service dependencies.

From a product perspective, that’s a disaster. We were losing competitive battles because we couldn’t ship fast enough.

The Hidden Cost: Cross-Team Coordination

The DZone research mentioned earlier quantified debugging time, but there’s another cost nobody measures: coordination overhead.

When one feature touches multiple services owned by different teams:

• PRD review meetings multiply
• Sprint planning becomes a negotiation
• Dependencies create blocking relationships
• Release coordination becomes a project unto itself

I’ve seen features that were 2 weeks of coding require 4 weeks of coordination. That’s not a technical problem—it’s an organizational one that architecture created.

A Question for the Engineers Here

How do you have this conversation with engineering leadership who are invested in the microservices approach?

I’ve tried raising velocity concerns, but the response is often: “We need to invest more in our platform” or “We’re paying down technical debt.” Both might be true, but neither explains why we’re slower than competitors with simpler architectures.

Is there a way to quantify this that would resonate? The 42% stat from CNCF is compelling, but I’d love something more specific to tie to our roadmap delays.

Would genuinely appreciate any frameworks for making this case without undermining engineering leadership.