Composable Infrastructure vs Microservices: Two Different Problems
Confusing these layers wastes engineering budget on the wrong problems.
Composable infrastructure and microservices get treated as interchangeable terms in most platform engineering conversations, and that habit is wrong in a way that costs real engineering time. They solve different problems at different layers of the stack, and the confusion between them leads teams to apply the wrong fix to the wrong bottleneck.
Why composable infrastructure and microservices are so often conflated, and why the confusion is costly
Both ideas share a vocabulary: modularity, decoupling, reusability, independent deployment. The problems they actually solve sit at different altitudes, and the vocabulary overlap hides that difference.
This confusion costs engineering time in two directions, and both are common. Some teams over-engineer their service layer, decomposing an application down to a fine grain of services, when the real need was a swappable vendor capability at the business level. Other teams mistake infrastructure composability for a software architecture decision, and build out elaborate internal service boundaries when what they needed was a clean API contract for a third-party capability. Either mistake misallocates engineering budget, and either one stalls a modernization effort that depended on getting the layer right from the start.
What Microservices Decompose
Microservices are a technical decomposition pattern. A single application gets broken into small, independently deployable services, each one handling a narrow task, such as authentication, image processing, or queue management, so that one piece can be updated or can fail without taking the rest down with it.
The value this delivers is real but narrow. These are gains in infrastructure stability for a single application, not gains in how fast a business can change what it offers to customers. Microservices are built and run by the engineering teams responsible for them, and their reach stops at the boundary of the application they decompose. They do not touch how an entire business capability, like a payment system or a recommendation engine, gets selected, swapped out, or orchestrated across a company's whole technology estate. That is a different kind of decision, made by different people, at a different scope.
Microservices also introduced a failure mode of their own when teams pushed the pattern too far without clear domain boundaries. The industry came to call these distributed monoliths: many small services, wired together so tightly that changing one still meant touching all of them. That failure is part of why the industry needed a layer above the service boundary, one that could govern whole capabilities rather than individual services.
What composable architecture governs, a layer above technical implementation
Composable architecture operates one level up, at the level of what practitioners call Packaged Business Capabilities, or PBCs. A PBC is an autonomous, interchangeable business block, a payment system or a customer relationship management module, that exposes its functionality through an API and can be swapped out without rewriting everything around it.
The unit that matters here is a bounded capability, and what happens inside that boundary is nobody's business but the team that owns it. The composable layer doesn't care which. It cares about the contract the capability exposes to everything else in the system, and whether that contract lets the capability be unplugged and replaced without a systemic rewrite.
The MACH principles, standing for Microservices as a base, API-first, Cloud-native, and Headless, formalize this idea. MACH is a philosophy for assembling an entire technology ecosystem out of interchangeable parts, treating microservices as one ingredient among four rather than the whole recipe, not a pattern for structuring the internals of one application. Composable architecture, read this way, is a business-strategy decision as much as a technical one. It governs which vendors get selected, how a capability's lifecycle gets managed over years, and how quickly a company can pivot its stack without tearing the whole thing down and starting over.
The structural difference: two distinct layers, not two competing choices
Microservices and composable architecture are not two options on the same menu, and treating them that way is the root of the conflation this piece opened with. They sit at different altitudes in the stack. Microservices describe how a single capability gets built on the inside. Composable architecture describes how many capabilities get assembled, governed, and replaced at the level of the whole enterprise.
Picture it as two layers stacked on top of each other. An organization can and usually should run both layers at once. A single composable capability, a checkout flow, for example, might be built internally with several microservices handling payment validation, inventory checks, and fraud screening, while the composable layer above treats the whole checkout flow as one swappable unit.
This is what the idea of a composable microservice actually means, when the term gets used carefully. It isn't a third category sitting between the other two. It describes a microservice built with a clean domain boundary and a stable API contract, built well enough that it can serve as a building block for the composable layer sitting above it. Composable architecture becomes especially useful in software factories, where agents treat code delivery and deployment as single swappable capabilities rather than managing distributed technical implementation piece by piece. Choosing microservices to solve an enterprise agility problem burns engineering effort on fine-grained decomposition that doesn't move the strategic needle. Choosing composable architecture to solve an application fault-isolation problem leaves the actual reliability gap unaddressed. Getting the layer right determines which problem actually gets fixed.
The composable IDP as the dominant model for platform engineering in 2026
By 2026, the composable internal developer platform, or IDP, had become the standard way platform teams structure their work, and it's a direct, practical expression of the layer distinction just described. A composable IDP stack is built from discrete, replaceable layers: a developer portal, an infrastructure provisioning layer, a delivery layer, a runtime layer, an observability layer, and typically security and cost layers as well. Each layer gets chosen on its own merits, and each can be swapped out without forcing a rewrite of the platform around it.
A composable IDP is not, itself, a microservices architecture, even though the tools that sit inside it may well use microservices internally. The platform engineer's actual job is to pick, connect, and govern capabilities at the PBC level: deciding which developer portal to run, which provisioning tool handles infrastructure, which delivery pipeline ships code, and making sure each of those pieces can be swapped later without breaking the rest. That's orchestration and lifecycle management across whole capabilities, not service-level decomposition inside any one of them.
Composability carries its own risk if a platform team treats it as a shortcut rather than a discipline. Composability works best when a platform team pairs it with real technical debt reduction underneath it, using it as a complement to that work.
Agentic software development and the layer distinction
Agentic software development, where AI agents write code, open pull requests, and operate inside CI/CD pipelines across the full software development lifecycle, doesn't remove the need for well-structured infrastructure layers. It raises the cost of getting those layers wrong, because agents work at a volume and a speed that expose architectural debt almost immediately, far faster than a human engineering team would surface the same weaknesses.
Agents are starting to own entire tasks end to end, from a written specification through to deployment. That means the infrastructure surrounding them, merge queues, CI fleets, code storage, and the skill harnesses agents use to do their work, has to be built for agent-driven throughput from the start, not retrofitted from workflows designed around human pace. Many teams still prefer agent setups that stay predictable and supervised rather than fully autonomous, and that preference is a reasonable one given how much is riding on the infrastructure those agents run inside.
The layer distinction carries specific weight in this context. Deciding how to split up the code inside a single agent's working codebase is a microservices-style implementation decision. Deciding how agent capabilities themselves get packaged, swapped, and coordinated across the platform is a composable infrastructure decision. Mixing the two up leads a team to spend its effort refining code structure when the actual constraint sits one layer up, in how the platform assembles and replaces agent capabilities.
The merge queue as the clearest example of where composable infrastructure must be agent-native
AI coding agents made writing code the cheap part of shipping software. The bottleneck moved entirely to landing that code, and a merge queue sized for how fast a human types cannot absorb agent-driven pull request volume without wait times that grow nonlinearly as arrival rates climb toward the queue's capacity.
This is a composable infrastructure problem, not a microservices problem. The fix is to replace the merge queue capability itself with one purpose-built for agent-driven throughput, a swap made at the platform layer.
Atlassian's experience makes the case concretely. Adopting a dedicated merge queue capability brought those failures down to near zero and gave the team its first merge SLO. The gain came from swapping out a platform-layer capability, not from refactoring any internal service architecture. No amount of microservices decomposition touches that kind of queue-layer delay.
Adding more parallel CI runners is a common response, and it's the wrong layer to fix when the real constraint is a shared deployment target that every queue entry's test step depends on. When that's the bottleneck, the structural fix is composable: give every queue entry its own isolated test environment, so tests stop waiting on environment availability. Which skills an agent has access to for resolving conflicts or re-running failed checks is a platform infrastructure question, not a question about how any single piece of code is written.
Vex's Agentic Merge Queue is built around that exact problem. It puts an AI agent in charge of conflict resolution and CI failure handling, and hands control back to a human only for the decisions that call for real judgment. Reliability problems in systems where an agent uses many tools tend to come from the sequence of steps, side effects, and shared state across a session, not from how any single tool is built inside. That's a platform-layer concern, and it's part of why reviewing an agent's full transcript matters: a team can't tune what it never looks at, and a dashboard metric alone won't show where in a multi-step sequence an agent went off course.
Production signals and the composable infrastructure layer
Composable infrastructure for a software factory is only as useful as the signals moving through it. Exceptions, failed queries, deploy errors, and CI results are inputs the platform layer should route straight into an agent's workflow, so the agent can act on them without waiting on a person to notice and triage first.
GitOps gives this idea a concrete shape at the deployment layer. The full state of infrastructure and applications gets declared as code and stored in version control, and that version control becomes the single source of truth for the system. Changes move through as diffs, and an agent can take part in that flow as a first-class operator.
The VS Code team's own practice shows what a closed loop looks like in production. Offline benchmarks run before anything ships, live A/B tests and aggregate usage signals follow once a change is live, and weekly reporting tracks how the change actually behaves in real developer workflows. Signals from production feed directly into an agent's workflow at the infrastructure layer: the platform routes the signal, the agent acts on it, and a human reviews the outcome.
Cloud-native code storage as a composable infrastructure capability in its own right
Version control built around human workflows, tuned for branch management, pull request review, and diffs meant to be read by a person, fits poorly when the primary reader and writer of code is an automated system working at high frequency across a large codebase. That mismatch becomes a real constraint once agents, not developers, are generating most of the commits.
Meta's Sapling version control system points toward where the field is headed. Built originally to handle an enormous monorepo, it introduces a Stacked Commits workflow that makes it far easier to manage large numbers of small, incremental changes, with first-class commands for editing, restacking, and navigating a stack of commits. That workflow fits how agents tend to produce output, in many small increments, far better than the traditional cycle of branching and opening a single pull request.
Vex's Forge capability operates at this same layer: high-performance code storage with full GitHub Sync, built for cloud agents. It's a swap at the storage layer, one a team can make without touching the rest of its toolchain, and it belongs to the same argument running through this entire piece. The question was never whether to use microservices or composable infrastructure. It was always about knowing which layer a given problem actually lives in, and choosing the tool built for that layer.
