Your team has 12 engineers and 23 services. Every time you add a field to an order, you modify 3 repos, wait for 3 pipelines, deploy in a specific order, then open Jaeger to trace because staging returns a 500 error in a service that no one remembers owning. This month's AWS bill increased again, mostly not due to traffic — but due to the control plane, sidecars, and the cluster observability required just to see your own system.
If that scenario sounds familiar, you are not alone. The 2025 CNCF survey notes that 42% of organizations that previously used microservices are consolidating them into larger deployment units. Service mesh — the symbol of the distributed wave — dropped from 18% adoption to 8% in just two years (Q3/2023 → Q3/2025). This is not a "monolith is back" trend on Twitter. This is the result of CFOs looking at the bill.
The real cost: it is not in compute
The often-overlooked figure: a functionally equivalent microservices system is 3.75-6 times more expensive than a monolith — approximately $40-65k/month compared to ~$15k/month. That difference does not come from EC2. It comes from things rarely shown in architecture presentation slides:
| Expense item | Monolith | Microservices |
|---|---|---|
| Compute + network | Basic | Basic + inter-service traffic, NAT, load balancer scaled by N |
| Observability | 1 app, centralized logs | Distributed tracing, metrics per service, log aggregation |
| Platform team | Almost none | 2-4 people just to operate the platform |
| Coordination | In a single PR | Contract testing, API versioning, deploy orchestration |
There is a recorded case of reducing AWS costs from $18k to $2.4k/month — an 87% reduction — simply by merging. No code optimization, no cloud provider change. Just removing the "tax" of distribution.
With a team of 10-50 engineers in Vietnam, the math is even harsher: 2-4 people in a platform team is 15-30% of the headcount. That is 15-30% of capacity producing zero features, just to keep the system... alive.
The new reason for 2026: AI agents reading code
There is a variable that did not exist when we chose microservices in 2019: now most code is written by AI agents. And agents work much more efficiently on a modular monolith than on a distributed system, for one very blunt reason — context.
With a monolith, the entire business flow resides in one repo, one process. An Agent can grep, read, modify, and run tests — done. With 23 services, that same flow is scattered across N repos, N contracts, and N deploy configs. The Agent (and humans too) must reconstruct the picture from fragmented pieces, where no single piece contains the full truth. When Thoughtworks Radar vol.34 made "cognitive debt" its main theme, distributed architecture is the primary factory for that debt: every service boundary is a place where knowledge is lost.
In other words: microservices were once sold as a way to scale human teams. In 2026, the added question is which architecture allows a human-plus-agent team to scale. And the answer is leaning towards fewer processes and fewer network boundaries.
A true modular monolith — not a big ball of mud.
Merging doesn't mean returning to a 500,000-line codebase that everyone is afraid to touch. A modular monolith is a single deploy unit, but module boundaries must be explicit, and those boundaries must be enforced by machines, not by conventions in Confluence documentation that nobody reads.
Fitness functions in CI are the primary tool. For example, with ArchUnit:
@ArchTest
static final ArchRule modules_khong_duoc_xuyen_thau =
slices().matching("com.company.app.(*)..")
.should().notDependOnEachOtherExcept(
dependency("orders", "shared"),
dependency("billing", "shared"));
Boundary violation → red build. No meetings, no arguments. This is also the approach O'Reilly calls "governance by rule" instead of "governance by inspection" — and serves as a guardrail to prevent AI agents from arbitrarily pulling cross-module dependencies when generating code.
Key point: a good module boundary is the future service separation line. If the module payments If a component truly needs to scale independently, decoupling it takes weeks, not quarters. Modular monolith doesn't rule out microservices — it defers expensive decisions until there is evidence.
Decision checklist
Signals to merge:
- Number of services exceeds the number of engineers. This is the clearest red flag — each service is a child that needs nurturing.
- Most business logic changes affect ≥2 services simultaneously. This means the boundary is wrong; you have a distributed monolith, incurring all distributed costs without any benefits.
- The cost of mesh + observability + platform team exceeds the value it protects. If you pay $20k/month to avoid $5k/month worth of downtime, the math speaks for itself.
- Onboarding a new engineer (or an AI agent) takes weeks just to understand the topology.
Signals that microservices still win:
- Scale independently truly: one part of the system needs 50 instances while the rest needs 2, or they differ significantly in runtime (GPU inference vs CRUD).
- Real organizational boundaries: different teams, different release cadences, or even different compliance requirements (e.g., a payment module needing PCI-DSS).
- Fault isolation is a business requirement, not a technical preference.
Note the order: these are conditions that have already occurred and been measured, not "might be needed later." Distributed architecture is buying with real money today to guard against a future that may never arrive.
Conclusion
Microservices are never wrong. The mistake is defaulting to them at a scale where they haven't paid off yet — and for nearly a decade, the industry has treated distributed costs as the "cost of professionalism." In 2026, with more transparent cloud bills and AI agents working in the codebase every day, the price of every network boundary is revealed in numbers. Good architecture is not architecture that looks like Netflix. Good architecture is architecture that your team — 12 humans and a few dozen agents — understands, can afford, and can still evolve when evidence emerges.
