The CNCF 2025 Annual Survey just confirmed what many of you already suspected: 42% of organisations are consolidating microservices into larger deployable units. This isn’t a couple of teams admitting they made a mistake—it’s an industry-wide course correction.
And the numbers get more interesting. Kubernetes adoption is sitting at 80% in production. Container usage is at 91%. But service mesh adoption? It’s dropped from 18% to 8%—more than halved in two years.
These numbers aren’t contradicting each other. They’re telling you how the industry is growing up. This article breaks down what the CNCF data actually shows, why the consolidation is happening, and what it means for how you should build systems. For broader context on the architectural landscape and consolidation trends, these numbers represent a fundamental shift in how teams approach distributed systems.
What Does the CNCF 2025 Survey Actually Show About Microservices?
The CNCF polled 689 respondents in fall 2024. The margin of error is ±3.8% at 95% confidence. And the headline finding: 42% of organisations that adopted microservices are consolidating services back to larger deployable units.
This covers the full range. Some teams are doing partial consolidation—merging a subset of services. Others are making complete architectural shifts back to monoliths or modular monoliths. This is selective correction, not wholesale abandonment.
The survey respondents are technical decision-makers at organisations using cloud native tech. The sample spans industries—tech, finance, healthcare, retail. It includes startups through to enterprises.
Here’s what makes the 42% figure meaningful. Cloud native adoption overall is at 89%. Kubernetes production use sits at 80%, with another 13% running pilots—a total of 93%. Container production use is at 91%.
The industry hasn’t abandoned distributed systems or containerisation. Teams are just being selective about where distribution makes sense.
The service mesh data is particularly telling. Adoption declined from 18% in Q3 2023 to 8% in Q3 2025. When the tooling required to make microservices work loses more than half its adoption, that’s architectural fatigue showing up in the numbers.
What this confirms: consolidation is an industry-wide correction backed by statistical data, not isolated failures or anecdotal evidence.
Why Are 42% of Organisations Consolidating Their Microservices?
Operational complexity is the primary driver. Managing distributed systems turned out to be harder than teams expected when they split services apart.
The numbers prove it out. Debugging time increased by 35% with microservices, thanks to distributed tracing challenges. Every service boundary adds context-switching overhead. Reproducing issues locally becomes a nightmare when problems only show up from interactions between services.
Network latency makes it worse. In-memory function calls in a monolith take nanoseconds. Network calls between services take milliseconds—a 1,000,000x difference. When a request spans five services, you’re burning 50-100ms on network overhead before you’ve done any actual work.
Small teams don’t have the bandwidth to manage per-service infrastructure. Each microservice needs its own CI/CD pipeline, monitoring configuration, deployment process, and operational playbooks. For teams under 10 developers, this overhead eats up time better spent building features. For a detailed breakdown of the true costs of microservices, including team sizing impacts and infrastructure overhead, that analysis provides quantified frameworks for understanding these expenses.
The cost pressures are real. A January 2026 case study shows consolidation from microservices to monolith delivered response times from 1.2s to 89ms—93% faster, a 13x improvement. AWS costs dropped from $18,000/month to $2,400/month—an 87% reduction. Deployment time went from 45 minutes to 6 minutes.
Another case study from Grape Up shows consolidation from 25 services to 5, achieving 82% overall cloud infrastructure cost reduction.
There’s also a cultural admission happening. Resume-driven architecture—choosing tech for LinkedIn appeal rather than technical fit—is being acknowledged openly. The industry prioritised complexity for the wrong reasons. Microservices became a resume checkbox, a signal of “modern” engineering regardless of whether you actually needed it.
The guidance coming out of the data: teams with 1-10 developers should build monoliths. Teams with 10-50 developers suit modular monoliths. Only at 50+ developers with clear organisational boundaries and independent deployment needs do microservices justify their cost.
Most teams never reach that threshold. But they rushed into distributed architectures anyway. The 42% consolidating now are correcting that premature adoption.
What Explains the Service Mesh Adoption Decline from 18% to 8%?
Service mesh adoption declined primarily because of operational complexity. Service mesh promised to solve the hardest problems in microservices: east-west traffic management, encryption, observability, consistent policy enforcement.
But running a mesh was hard. Sidecars added resource overhead to every pod. Platform teams had to operate yet another distributed system, with sidecars injected into every pod across the cluster.
Here’s the paradox: Istio achieved CNCF graduation status—validation of production-readiness—during the same period adoption declined. Even mature, production-ready service meshes add overhead that teams found hard to justify.
Istio’s response was Ambient Mesh, a sidecar-less architecture. Analysis from Solo.io shows 90% reduction in allocated resources between L4 ambient and sidecar deployments. But the admission built into Ambient Mesh’s architecture is that the sidecar model created resistance.
Alternative solutions are gaining ground. API gateways are moving into east-west territory. eBPF-based approaches offer lightweight observability and networking without sidecars. Simpler ingress controllers like NGINX and Traefik are handling use cases that might have needed a full mesh before.
The correlation with microservices consolidation is direct. Fewer services means less need for service mesh. When teams consolidate from 25 services to 5, they eliminate most of the east-west traffic complexity that service mesh was supposed to manage.
Why Is Kubernetes at 80% Adoption When Microservices Are Being Consolidated?
Kubernetes achieved 80% production adoption because it solves container orchestration, not microservices architecture. This distinction matters.
Containers work equally well for monolithic applications, modular monoliths, and microservices. Container production use at 91% shows containerisation works regardless of your architectural pattern choice.
Many teams think Kubernetes requires microservices. It doesn’t. Kubernetes orchestrates containers regardless of your architecture. You can run containerised monoliths, modular monoliths, or microservices on Kubernetes. The platform doesn’t care—it manages containers.
Organisations are consolidating microservices while keeping containerised deployments on Kubernetes. They’re merging 50 microservices into 5 modular services and still running everything on K8s clusters.
Kubernetes provides value beyond microservices. Autoscaling with Horizontal Pod Autoscaler and tools like Karpenter means efficient resource use. Declarative infrastructure supports GitOps workflows. CI/CD integration enables automated deployments. Self-healing features restart crashed containers without anyone having to get involved.
Kubernetes automates deployment, scaling and operations for containerised applications regardless of how many services you’re running.
The consolidation trend shows teams are discovering they can keep the operational benefits of Kubernetes while simplifying their application architecture.
How Does Serverless Fit Into This Architectural Shift?
Serverless is an alternative path to managing complexity, not a replacement for the microservices decision. AWS Lambda adoption sits at 65% of AWS customers. Google Cloud Run at 70% of GCP customers. Azure App Service at 56% of Azure customers.
These numbers show broad adoption without a single dominant use case. Fast and transparent scaling, per-invocation pricing, operational simplicity—these advantages are driving uptake.
It addresses operational complexity through a different trade-off than monoliths. Serverless outsources complexity to the cloud provider. Monoliths eliminate complexity through consolidation. Different approaches with different cost structures: per-invocation versus per-instance, vendor lock-in versus self-management.
The adoption pattern is selective. 44% use serverless for “a few applications” in production, not wholesale migration. Hybrid approaches are common: monolith core with serverless periphery for specific workloads like event processing or batch jobs.
When serverless makes sense: variable traffic patterns with long idle periods, event-driven workloads, teams wanting to avoid infrastructure management, acceptable latency for cold starts.
Both serverless and modular monoliths represent pragmatic corrections from microservices complexity. They’re different points on the spectrum of how teams are reassessing operational overhead and making contextual choices.
What Do Industry Leaders Mean by “Architecture Wars”?
The CNCF survey data sits at the centre of what industry observers are calling “Architecture Wars.” The term refers to the debate between microservices advocates and monolith proponents, but the framing is misleading. The industry is shifting from dogma to pragmatism.
For much of the last decade, microservices architecture dominated software engineering conversation. It was touted as the solution to scaling both software and teams. Many organisations rushed to adopt it, breaking down monoliths into dozens or hundreds of small services.
Martin Fowler warned about the “microservice premium” years ago: the substantial cost and risk that microservices add. That warning is now validated by the data.
The “war” framing suggests a binary battle. Teams are actually making contextual decisions based on team size, scale, and organisational maturity. The pendulum isn’t swinging from one extreme to another—it’s settling into pragmatic middle ground.
Resume-driven architecture is being acknowledged openly now. Technologies were chosen for LinkedIn visibility. “Modern” tech as career signalling. Premature adoption without understanding trade-offs.
Both patterns remain valid. Microservices aren’t “dead.” They’re appropriate for large-scale, complex domains. Netflix, Amazon, and Uber still use microservices successfully. But they represent a minority of organisations—80%+ don’t have that scale.
The industry is moving from hype cycle to practical application. Recognising architectural pluralism. Treating technology choices as trade-offs rather than right versus wrong.
Are Microservices Dying or Just Correcting?
Microservices are correcting, not dying. The 42% consolidation represents maturation and selective adoption, not wholesale abandonment.
The industry is learning that “modern” architecture means choosing what’s effective for your context, not automatically choosing distributed systems.
The evidence that microservices aren’t dying: major tech companies like Netflix, Amazon, Uber, and Spotify still use them. Kubernetes adoption at 80% production use. Cloud native adoption at 89%. Service mesh still at 8%—down but not eliminated.
Even Amazon consolidated specific services back to monoliths when microservices didn’t fit. Their Prime Video case used distributed components orchestrated by AWS Step Functions. Their distributed architecture hit scaling limits and cost issues, leading them to consolidate into a single process. The result: 90% cost savings and breakthrough performance improvements.
Who should still use microservices: large organisations with 50+ person engineering teams, complex multi-domain systems, genuine need for independent deployment cycles, teams with distributed systems expertise.
The 80% who don’t need microservices: startups with 1-10 person teams, mid-market companies without scale requirements, organisations lacking operational maturity, systems without genuine domain boundaries.
Modular monoliths are emerging as the pragmatic middle ground. Single deployed applications with well-separated modules, clear boundaries, in-memory communication. Unlike traditional “big ball of mud” monoliths, modular architectures enforce boundaries through domain-driven design and automated tests. To understand what modular monoliths actually are and how they combine the best of both architectural worlds, that detailed explanation covers the conceptual foundation.
Benefits: single deployment, fast debugging, ACID transactions, zero network overhead, minimal infrastructure costs. Modular monoliths strike a balance between simplicity and flexibility.
They give you a path to extraction if scaling demands it. Modules can become microservices when proven necessary. But here’s the key insight: most teams never need to extract.
The future is architectural pluralism. No one-size-fits-all architecture. Choosing based on team, scale, and domain. Hybrid approaches are common.
Key learnings from the consolidation trend: premature optimisation applies to architecture, operational capacity is a real constraint, simplicity has value, business outcomes matter more than technical fashion.
Start with a modular monolith. Enforce clear module boundaries from day one. Extract to microservices only when proven necessary. Unless you have specific scalability requirements only addressable through microservices, a well-designed modular monolith is often the most efficient path.
For a comprehensive look at the entire modern software architecture landscape, including detailed examination of these trade-offs and decision frameworks, that resource provides the broader context CTOs need to make informed architectural choices based on their specific constraints and team capabilities.
FAQ
Is the CNCF survey data reliable?
Yes. The CNCF 2025 Annual Survey polled 689 respondents in fall 2024 with a ±3.8% margin of error at 95% confidence. Respondents are technical decision-makers at organisations using cloud native technologies, representing diverse industries and company sizes.
What percentage of organisations are consolidating microservices?
42% of organisations are actively consolidating microservices according to the CNCF 2025 survey. This includes both partial consolidation—merging some services—and complete architectural shifts back to monoliths or modular monoliths.
Does service mesh decline mean microservices are failing?
Not necessarily. Service mesh adoption dropped from 18% to 8% primarily due to operational complexity, but 80% Kubernetes adoption shows containerisation remains strong. The decline tells you organisations are simplifying architectures by consolidating services.
Can you run a monolith on Kubernetes?
Yes. Kubernetes is container orchestration, not microservices architecture. Containerised monoliths and modular monoliths run successfully on Kubernetes, benefiting from autoscaling, CI/CD integration, and declarative infrastructure.
What is resume-driven architecture?
Resume-driven architecture is choosing technologies based on career advancement appeal rather than technical fit. It refers to adopting “modern” technologies like microservices to improve LinkedIn profiles rather than solving actual business problems.
How much can consolidation reduce costs?
Cost savings vary widely. Amazon Prime Video achieved 90% cost reduction by consolidating their Video Quality Analysis service. Startup case studies show 87% AWS cost reduction and 13x response time improvements. For detailed examples, see how Shopify, InfluxDB, and Amazon Prime Video successfully moved to modular monoliths.
What team size needs microservices?
Teams with 50+ developers might need microservices if they have complex domains, operational maturity, and genuine need for independent deployment. Teams with 1-10 developers benefit from monoliths, while 10-50 developers suit modular monoliths.
Is serverless better than microservices?
Neither is universally better—they’re different approaches to managing complexity. Serverless outsources infrastructure management to cloud providers, while microservices give more control but require you to manage it yourself.
What is a modular monolith?
A modular monolith is a single deployable application with well-separated internal modules, clear boundaries, and enforced architectural discipline. It provides microservices-like structure without distribution complexity.
Are we going back to legacy monoliths?
No. The consolidation trend favours modular monoliths—structured, disciplined architectures with clear module boundaries—not legacy “big ball of mud” monoliths. Organisations are applying domain-driven design principles within single deployable units.
Why did service mesh adoption decline during Istio’s graduation?
The paradox happened because Istio graduation validated maturity while adoption declined due to operational complexity. Even mature, production-ready service meshes add overhead with sidecar proxies, control planes, and configuration management.
Will Kubernetes adoption decline next?
Unlikely. Kubernetes adoption is at 80% production use—93% including pilots—and growing because it solves container orchestration regardless of architecture. Microservices consolidation happens within Kubernetes, not away from it.
