The '42% Are Abandoning Microservices' Statistic Is Not in the Survey. The Retreat Is Real Anyway.

Where Does the 42% Actually Come From?

If you have sat in an architecture review in the last nine months, you have probably heard some version of this sentence: 42% of organisations that adopted microservices are now consolidating services back into larger deployable units. It appears in conference talks, in consultancy decks, in Reddit threads about whether the monolith is back, and in a long tail of blog posts that attribute it to the Cloud Native Computing Foundation's annual survey. It is a satisfying number, because it puts a percentage on something a lot of engineers have felt for years.

I went looking for the primary source, and it is not there. The CNCF annual survey report, a web survey conducted by Linux Foundation Research during November and December 2024 with a sample of 689, contains no finding about consolidating services into larger deployable units. It does contain a 42%, and that is almost certainly the origin of the confusion: service mesh is 'currently in production for a few or most applications in roughly 42% of respondent organizations, down from 50% in 2023', with the report attributing the decline to concerns over complexity, cost and performance.

The figure is not in the other obvious candidate either. When CNCF and SlashData sized the cloud native developer population in November 2025, they reported microservices adoption at 46% among backend developers and API gateways at 50%, describing both as dominant foundational technologies. That is not a portrait of an architecture in retreat.

Follow the citation chain and it dissolves into itself. A representative post asserts that 'according to 2025 CNCF survey data, 42% of organizations that adopted microservices are consolidating services back to larger deployable units', then supports it by linking to a second commentary piece rather than to any survey. Each link in the chain inherits the confidence of the last and adds none of its own.

This matters for a practical reason rather than a pedantic one. Architecture decisions have five-to-ten-year consequences and are unusually vulnerable to social proof, because nobody can A/B test their own platform. If the argument for collapsing eleven services into three rests on a statistic that cannot be traced, the decision is being made on vibes wearing a lab coat. The awkward part is that the direction of travel it describes is real, which is exactly why the number was so easy to believe and so rarely checked.

What the Cloud Native Data Actually Shows

Strip out the unsourced headline and a more interesting picture survives, assembled from figures you can check. The service mesh decline is the clearest signal in the CNCF data, and it is a signal about operational appetite rather than about technology quality. A mesh is the tax you pay to make a large fleet of services observable, secure and traffic-managed in a consistent way. Organisations reducing that investment are telling you something about how much distribution they intend to operate.

The same survey shows where the pain moved. In 2023, respondents named security and complexity as their biggest container challenges. In 2024, the top answer was cultural challenges with the development team at 46%, followed by CI/CD at 40%. Meanwhile CI/CD use in production for most or all applications rose from 46% to 60% in a single year. Read those together and the constraint is not whether the platform works. It is whether the humans and pipelines around it can keep up with the coordination the architecture demands.

Distribution also has a directly measurable cost in provisioned headroom, because every service carries its own safety margin. Cast AI's benchmark across more than 2,100 organisations on AWS, GCP and Azure for the 2024 calendar year found average CPU utilisation at just 10%, down from 13% the year before, with memory utilisation at 23%. Split one workload into twelve and you buy twelve sets of unused headroom, twelve autoscaling configurations to get wrong, and twelve chances to overprovision defensively because nobody wants to be the service that fell over.

The consolidation cases themselves are specific, documented and older than the current discourse. IEEE Software published a case study on why Istio migrated from microservices back to a monolithic control plane, which is a notable data point given that Istio exists to manage microservices. Segment's much-cited reversal came after hundreds of destination repositories made shared-library maintenance untenable; after consolidating, the team went from 32 shared-library improvements in 2016 to 46 by mid-2017 and stopped being paged for destinations processing trivial load. And the Prime Video video quality analysis team's 90% infrastructure cost reduction came from collapsing a distributed orchestration into a single process so that video frames moved through memory instead of through object storage.

None of that adds up to a repudiation of microservices, and anyone selling it that way is overreaching in the opposite direction. Kubernetes remains near-universal, with the same report noting that 93% of companies use it in production, are piloting it or are actively evaluating it. What the evidence supports is narrower and more useful: teams are becoming selective about which boundaries are worth paying for, and the thing they are retreating from is coordination overhead, not containers.

Why the Agent Changed the Architecture Calculus

Here is the part that is genuinely new in 2026, and it is not in any of the surveys yet. The economics of a service boundary now include a cost that did not exist in 2019: how well an AI coding agent can work across it.

An agent works in a checkout. It reads the repository it was pointed at, greps for call sites, runs the test suite it can find, and proposes a diff. Inside one codebase, that loop is remarkably effective. Across sixteen repositories with their own build systems, their own CI, their own deployment cadence and a contract negotiated in a shared schema registry, the same loop degrades into guesswork, because the call path the agent needs to reason about terminates at an HTTP client and resumes in a codebase it never opened.

The research bears this out precisely. A study accepted at the LLM4Code workshop at ICSE 2026 tackled bug localisation in a real microservice estate and found it hard enough to need a purpose-built approach: on an industrial system of 46 repositories and 1.1 million lines of code, hierarchical natural-language summarisation reached Pass@10 of 0.82 and MRR of 0.50, outperforming retrieval baselines and agentic RAG systems such as GitHub Copilot and Cursor. Read that result from the practitioner's side rather than the researcher's: the off-the-shelf agents your team already pays for performed worse at finding which of 46 repositories contains the bug, and closing the gap required building a summarised index of your own architecture first.

The obvious rebuttal is to point at context windows and say the problem is solved by scale. It is not. Chroma's evaluation of 18 models, including frontier models from every major lab, starts from the observation that LLMs are presumed to process context uniformly, so that the ten-thousandth token is handled as reliably as the hundredth, and demonstrates that this assumption does not hold: performance varies significantly with input length even on simple tasks and grows increasingly unreliable as input grows. Stuffing sixteen repositories into a prompt is not a substitute for a legible boundary, which is the same argument StepTo made about context engineering as a discipline rather than a prompt trick.

This is also where DORA's framing of AI as an amplifier earns its keep. The research finds that AI magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones, that higher AI adoption is associated with an increase in both delivery throughput and delivery instability, and that teams with fragmented tooling and fragile infrastructure mostly get help generating technical debt faster. An architecture that was merely annoying to change by hand becomes expensive to change at agent volume, because you are now amplifying the coordination cost, not just paying it.

One honest caveat, because the pro-monolith version of this argument routinely overstates itself: a monolith is not automatically agent-friendly. Two million lines with no module structure, no enforced boundaries and a test suite that takes fifty minutes is exactly as opaque to an agent as a service fleet, and it removes the one thing the fleet gave you, which was a hard limit on how far a bad change could reach. What agents reward is not the absence of boundaries. It is co-located code with boundaries an agent can see, which is the same property we described as repository readiness being the real bottleneck.

The Bill Arrives at the Merge Point

Whatever distribution costs you in reasoning, it charges again at integration, and this is where the 2026 delivery data is unambiguous. CircleCI's 2026 State of Software Delivery, drawn from 28,738,317 workflows run during September 2025, reports average daily workflow runs up 59% year over year while main branch success rates fell to 70.8%, the lowest in over five years, and recovery to green stretched to 72 minutes for the typical team, up 13%. The report's own summary of where the time goes is blunt: review, validation, integration and recovery are where AI-generated code piles up.

Now apply that to a distributed estate. A single user-visible behaviour change that spans four services is four pull requests, four pipelines, four review queues and an ordering constraint, plus a window during which version skew is live in production and both sides of a contract must tolerate each other. Each of those merges draws independently from that 70.8%. The probability that the whole change lands cleanly on the first attempt is the product of four numbers below one, and the recovery path is not one rollback but a negotiated sequence of them.

This is the same wall teams hit when they scale up agent usage, which we covered in detail in what a fleet of coding agents actually costs to run: generation got cheap, landing did not. Architecture is one of the few levers that changes the shape of that cost rather than just adding capacity to absorb it. Collapsing a boundary that no change ever respects converts four coordinated merges into one ordinary one.

There is a verification dimension too. When a change spans services, the only place its correctness is fully expressed is an integration environment, and integration environments are slow, shared and expensive to keep honest. Inside a module boundary, the same guarantee is a fast unit or component test that runs on every commit. Teams carrying comprehension debt from AI-authored code cannot afford a verification story that only works in a staging environment nobody trusts.

And every boundary you keep is telemetry you pay for. Each hop is a span, each service is a set of dashboards, alerts and error budgets, and at agent-era volumes that becomes its own line item, which is the problem we examined in paying more to watch the system than to run it. Distribution is not free at any layer. It is a purchase, and it should be made deliberately, per boundary, with a stated benefit.

What Still Belongs Behind a Network Boundary

The useful question is never monolith or microservices. It is which specific boundaries earn their operational cost, and that question has answers you can defend in a review.

A separate service is usually justified when the workload has a genuinely different scaling profile, such as GPU-backed inference next to ordinary CRUD, so that the two can be sized and scheduled independently. It is justified when you want a hard failure domain, because the point of the boundary is that the blast radius stops there, which is the resilience argument StepTo set out in what 2026's outage year should change about how you build. It is justified when a regulatory or residency line runs through your system, and code or data has to sit in a specific jurisdiction under specific controls, as the European sovereignty rules increasingly demand. It is justified by a genuinely different runtime, where a Python model server and a Go API cannot share a process. And it is justified when a component has a real external consumer with its own SLA and release cadence you do not control.

The anti-patterns are equally recognisable. 'We might need to scale it someday' is not a scaling profile, it is a guess, and it is the single most common reason teams own infrastructure they cannot justify. The org chart is not an architecture: Conway's law describes a pressure, not a licence to mint a service per squad. And 'it is the modern way to build' is precisely the reasoning that produced the estate people are now paying consultants to simplify.

The worst outcome of all is the one that looks like microservices and behaves like a monolith. If your services always deploy together, share a database schema, cannot be tested independently and cannot fail independently, you have bought the network tax and kept the coupling. That configuration is strictly worse than either alternative, and it is far more common than architecture diagrams admit. A quick diagnostic: if the release checklist has an ordering section, you have one.

Note what this framework is not. It is not a case for rewriting a working system. Most estates contain a handful of boundaries that are load-bearing and a handful that exist because of a decision nobody remembers making. The work is telling those apart, and it is done with evidence from your own repository rather than from a survey.

A Modular Monolith Is a Discipline, Not a Deployment Artefact

The strongest version of the consolidation argument was made years before the current wave, and by a company operating at a scale that supposedly requires microservices. In explaining why it modularised its Rails monolith instead of extracting services, Shopify's engineering team argued that distributing code across machines is 'a topology change, not an architectural change', and that a poorly designed API inside a monolith is still a poorly designed API inside a service, only now with a stateless network boundary, serialisation and the reliability problems of networked communication attached. They built Packwerk to enforce boundaries in the codebase, reporting 48 packages with 30 boundary enforcements in the core application.

That is the crux. A modular monolith is not a monolith with good intentions. It is a codebase where boundaries are mechanically enforced, and the enforcement lives in CI rather than in a wiki page. Every ecosystem now has the tooling: ArchUnit and Spring Modulith in Java, Packwerk in Rails, import-linter in Python, dependency-cruiser or Nx boundary rules in TypeScript, workspace crates in Rust, ArchUnitNET in .NET. The mechanism matters less than the property: a cross-boundary import fails the build.

The rules that make it hold are few and unforgiving. Each module exposes a published API and nothing else. No module reads another module's tables, and schema ownership is explicit even inside one database. Cross-module communication is a call to that published API or an internal domain event, never a shared mutable object graph. Cycles are build failures. And every one of those rules is a test, not a norm, because norms lose to deadlines every single time.

This is where the agent era makes the discipline pay twice. An agent respects the constraints you can enforce and ignores the ones you merely documented, because a failing build is feedback it can act on inside its loop and a convention in Confluence is not. Enforced module boundaries turn architectural intent into something an agent can be held to automatically, which is the same insight behind the harness around the model mattering more than the model and behind writing architectural rules into the markdown files your agents actually read.

The bonus is optionality. A module with an enforced boundary and no shared state is a service you can extract in a week when a real reason appears. You get the extraction option without paying the operational premium upfront, which is the opposite of how most estates were built.

How to Run a Consolidation Without Betting the Quarter

If you suspect you are carrying boundaries you cannot justify, the work has a sequence, and it starts with evidence rather than with a diagram.

Begin with change coupling from your own version control history. For the last twelve months, compute which services appear together in the same pull request, the same ticket, or the same day's deploys. Services that co-change constantly are not independent, whatever the diagram says, and they are your consolidation candidates. This analysis takes a couple of days, uses data you already have, and is the single most persuasive artefact you can bring to an architecture review because it describes your system rather than the industry's.

Pair it with a cost and pain inventory per service: provisioned versus used CPU and memory, pipeline minutes, alert volume, pages per quarter, and how many people can safely change it. Boundaries that co-change constantly, cost real money in idle headroom and have exactly one person who understands them are the strongest candidates. Boundaries that are quiet, cheap and independently deployable should be left alone regardless of fashion.

Then collapse in increments that preserve the external contract. Move the second service's logic into the first as a module with an enforced boundary, keep the original HTTP endpoint as a thin facade so callers are untouched, run both paths until traffic and error rates agree, and only then delete the transport. The hazardous part is almost never the code; it is the data. Shared schemas, dual writes, migration ordering and the rollback plan are where these projects fail, and they need a senior engineer who has done it before rather than an ambitious one who has read about it.

Keep a measurement pair open throughout: delivery metrics on one side, cost and reliability on the other. Lead time and change failure rate should improve, or you have merely rearranged the problem. Infrastructure spend, p95 latency and incident count should not degrade. If they do, stop, because a consolidation that trades a coordination problem for a reliability problem is not a win. Timebox each increment to six to twelve weeks with a named owner, and treat any increment that cannot be described in one paragraph as not yet ready to start.

One thing to reject outright: the big-bang rewrite. Nothing in the data above argues for rebuilding a working system, and the modernisation track record is not kind to programmes justified by architectural fashion rather than by a measured constraint.

Who Actually Does This Work, and Why It Never Gets Staffed

Consolidation work has the same funding problem as resilience work. It is unambiguously senior, it produces no demo, and it competes for exactly the engineers who are already fully committed to the roadmap. The person who can read a change-coupling analysis, design an enforced module boundary, plan a data migration and keep the rollback credible is the person three feature teams are currently arguing over. So the analysis gets promised each quarter and delivered in none of them, while the estate accumulates two more services.

It is also poorly suited to a permanent requisition. You do not need a new headcount forever; you need a small amount of high-grade architectural capacity for two or three quarters, alongside the team that will own the result afterwards. Hiring for that shape takes longer than the work itself.

This is the engagement model StepTo is built around. We are a senior-led nearshore partner based in Serbia, working with European and US clients in overlapping hours, and for architecture work that overlap is not a comfort feature. Deciding which boundaries to collapse means arguing with your architects in real time, watching a canary together, and being on the call when the dual-write window opens. That is a working session across a two-hour gap and a fortnight of misunderstanding across a twelve-hour one, which is the practical case we set out in the hidden cost of timezone overlap in outsourcing quotes.

The capability split is clean enough to scope separately. Change-coupling analysis, module extraction, boundary enforcement in CI and data migration are senior backend work; the pipeline, telemetry and cost side is DevOps and platform work, and where the gap is a specific skill rather than a whole workstream, adding platform engineers or DevOps engineers through staff augmentation puts the capability inside your existing team rather than beside it. Larger consolidations that touch the data layer belong in a modernisation engagement scoped and estimated as one.

For ongoing ownership we default to a dedicated development team rather than fixed-scope delivery, because module boundaries decay the moment nobody is enforcing them and the next twelve months of features will test every one of them. How we run engagements is on the process page, rates are on the pricing page, and the broader case for nearshore development is set out in our Serbia overview. If you would rather start with the diagnosis than the delivery, a scoped architecture review is a two to three week engagement that produces the change-coupling map, the per-service cost and pain inventory, and a ranked list of boundaries worth keeping.