Which Vendors Are Actually Building Composable Infrastructure

"Composable infrastructure" now describes two markets that have almost nothing in common except the word itself. One is disaggregated data-center hardware: compute, storage, and networking pulled apart into fluid pools and reassembled in software, so workloads get served in real time as demand shifts. The other is modular software-factory tooling: merge queues, CI pipelines, code storage, and agent harnesses built as independently replaceable layers that platform teams assemble and swap without rebuilding the whole stack. Mirantis frames composable architecture as building platforms from reusable components instead of locking into one vendor's stack, and that definition happens to fit both the physical rack and the Kubernetes control plane equally well. The overlap in vocabulary has given vendors on both sides room to claim the label cheaply: a monolithic platform adds an API layer and calls itself composable, a hardware OEM slaps "software-defined" on a pre-integrated rack and calls it disaggregated. Sorting the real claims from the cosmetic ones requires criteria that hold regardless of which layer a vendor operates in.

What genuine composability requires, across both definitions

Composability, properly defined, has four testable properties, and they apply whether the subject is a storage array or a merge queue. A component has to be independently replaceable. Configuration has to be declarative: the desired state of a component is expressed on its own, separate from the procedural steps that would otherwise bury it. The API surface between modules has to be clean enough that one piece can be swapped without touching its neighbors. Adjacent capabilities cannot be force-bundled, so that choosing one module never quietly requires choosing another.

On the hardware side, Lightbits lays out what these properties look like in physical form: composable hardware pools, composable software that decouples storage hardware from its management layer, and a high-speed, low-latency interconnect standard, each piece substitutable without the others. Mirantis specifies the equivalent requirements for the software layer: declarative templates, a component catalog with validation, multi-cloud abstraction, and unified control and observability. All four have to be present together; a platform that has three out of four is modular in appearance but not composable in practice.

The disqualifying condition is forced bundling. If replacing one component requires replacing another, or if a vendor's control plane is the only orchestration layer the system will accept, the product is a monolith wearing a composable label. That single test, applied consistently, does most of the work of separating genuine architecture from marketing.

The hardware-layer vendors: who disaggregated the data center and who just repackaged it

The hardware market for composable infrastructure is concentrated in a handful of OEMs, and genuine disaggregation turns out to be rarer than their combined market share would suggest. HPE and Dell Technologies hold the largest share of this market through pre-integrated racks that embed their own fabric managers. That is a form of composability, but the fabric manager itself is locked to the vendor, which fails the independent-replaceability test on its own terms.

HPE Synergy illustrates the pattern well. Practitioners rate it highly for doing what it promises: composing compute and storage on demand. Its orchestration layer, HPE OneView and Synergy Composer, is proprietary, though it exposes open REST APIs and supports third-party integrations through SDKs for tools like Ansible, Terraform, Chef, and Puppet. Composability here is vendor-controlled rather than vendor-exclusive, open enough at the edges to integrate but not open enough at the core to replace.

Western Digital's OpenFlex takes a different approach, using an open interconnect standard to decouple storage from compute across vendors, outside the confines of any one vendor's rack. Because that interconnect standard is one no single company owns, OpenFlex passes the independent-replaceability test in a way that fabric-manager-based systems don't. The trade-off between the two approaches is practical rather than philosophical: pre-integrated OEM racks are operationally simpler to run but constrain which components a buyer can later swap, while open-fabric architectures offer real disaggregation at the cost of more integration work up front. The hardware vendors closest to genuine composability are the ones betting on open interconnect standards rather than proprietary fabric managers, and that same distinction, standard versus proprietary control point, is about to reappear at the software layer.

The software-factory tooling layer: where the composability argument is moving fastest

The software factory faces a forcing function the hardware market doesn't: AI coding agents now write code, open pull requests, and operate inside pipelines without a human initiating each step, and every tooling layer built before that shift faces throughput and replaceability demands it wasn't designed to handle, so the composability argument is advancing fastest here, where the tooling needed to keep up is being built or rebuilt in real time.

Backstage is the clearest example of a component meeting the bar. It's the most widely adopted open-source developer portal and a CNCF incubating project, mapping services to their owners, documentation, and dependencies. Its Scaffolder module turns templates into self-service provisioning actions, which satisfies both the declarative-configuration and clean-API-surface criteria directly. Crossplane does the equivalent work one layer down, turning Kubernetes itself into a universal control plane: cloud resources become Kubernetes custom resources, provisioned and continuously reconciled by provider plugins. Its composability holds up because any one provider plugin can be swapped out without disturbing the others. Kratix adds a third piece, introducing "Promises," declarative definitions of a platform capability that package the API description, the provisioning workflows, and the dependencies together, so that each capability is independently deployable and replaceable. Of the three, Kratix comes closest to the hardware-side ideal of a substitutable pool.

Backstage, Crossplane, and Kratix can be assembled together, portal, provisioner, and orchestration glue, without any one of them requiring the presence of the others, the hallmark of composability actually working. It also raises the harder question: once a team moves past the portal and provisioning layers and into the pipeline itself, where pull requests get merged and CI runs, does the same discipline hold, or does the noise start?

Where composability claims get noisy

Integration breadth gets mistaken for composability more often at the CI/CD layer than anywhere else in the software factory. A tool that connects to fifty other tools through its own proprietary webhooks can still be a monolith in practice, because replacing it means reconfiguring every one of those fifty downstream dependencies. Breadth of connection says nothing about ease of removal, and removal is the actual test.

The merge queue is where this distinction matters most right now, because the volume problem is structural. Bunnyshell found that 80% of developers already use AI coding agents in their workflows, and the resulting pull request volume creates bottlenecks that human-paced merge queues were never built to absorb, even though the code itself gets generated faster. Automated merge queues exist to solve exactly that validation and merging crunch. Graphite's merge queue is notable here because it's stack-aware: it treats a set of stacked pull requests as a dependency graph rather than a list of independent units, a structural property built into the tool itself. That structural property is what makes a merge queue genuinely substitutable into a pipeline, since surrounding tooling doesn't need to change to accommodate it. A merge queue that is stack-aware and exposes a clean API for CI systems to call passes the composability test cleanly; one that insists on its own CI runner or its own notification layer does not, regardless of how many integrations it advertises.

The same question applies to agentic coding tools themselves: does the agent expose its skill inventory and transcript outputs as machine-readable signals other tools can consume, or does it keep that information inside its own dashboard? An agent that operates as a black box fails the composability test no matter how well it scores on coding benchmarks, because the rest of the pipeline can't act on what it can't see. Across all three of these categories, merge queues, CI pipelines, and agentic tools, the hardest and most honest test is whether a given piece can be pulled out of the stack without pulling the rest of the stack down with it.

The hidden cost composable stacks impose: selection burden and operational overhead

Composability doesn't eliminate complexity. It moves complexity from vendor lock-in risk toward integration and operational overhead, a trade a team makes deliberately. Backstage demonstrates the cost concretely: it takes three to five dedicated engineers, often more, to customize and operate, and meaningful value takes months to show up. A commercial alternative like Port avoids much of that operational cost by trading away unlimited code-level customization for a faster setup, which is a legitimate trade in the other direction.

The selection burden compounds once a team is assembling a full composable stack. Kratix is Kubernetes-native but needs a portal front end to be usable by most teams. Crossplane is the most precise tool available for provisioning but is deliberately scoped to that one layer and nothing else. A team building the equivalent of a monolithic platform's functionality out of composable parts is making four or five independent tooling decisions where a single vendor would have made one for them.

That overhead isn't worth absorbing at every scale. Below roughly a hundred developers, with no dedicated platform team to own the integration work, the cost of operating three or four independently composable layers is likely to exceed whatever lock-in cost it was meant to avoid. Above that threshold, the arithmetic reverses, and it reverses faster for teams running agentic workflows, where AI agent throughput turns every bottleneck in a monolithic stack into a compounding problem. Mirantis frames the case for composable architecture around exactly these pressures: legacy monoliths, vendor lock-in, slow delivery, and multi-cloud complexity, each of which gets worse, not better, as agent throughput scales. The honest accounting is this: composability's overhead is a cost paid once, during integration. Lock-in's overhead recurs with every release cycle and grows as the organization grows around it.

Testing whether a vendor is composable

A vendor that genuinely builds composable infrastructure should answer four questions without hedging, and hesitation on any one of them is itself informative.

Can each component be replaced independently, without modifying whatever sits next to it? A vendor with a real architecture will name the specific seam, the API contract or the open standard, that makes that replacement possible. Vague answers here usually mean there isn't a seam.

Is the configuration declarative, with the desired state of each component expressed separately from the logic that orchestrates it? Declarative templates paired with a validated component catalog are the foundation this depends on. If the answer amounts to "we use a wizard" or "our GUI handles that," the system underneath is almost certainly imperative and tightly coupled.

Does the vendor's control plane demand exclusive ownership of an adjacent layer? A merge queue that insists on its own CI runner, or a developer portal that insists on its own provisioning engine, is composable only within the walls of its own garden.

Does the tool expose its internal signals, agent transcripts, queue state, CI failure patterns, as machine-readable output other tools can consume, or only through its own dashboard? This is where most software-factory vendors fall short: they generate rich internal telemetry and then lock it behind a proprietary UI, leaving that data unreachable to the agents and downstream tools that would otherwise act on it. A tool that streams that signal out through a clean API clears the bar; a tool that only visualizes it for a human does not.

The software-factory layer needs purpose-built composable tooling, not adapted general-purpose platforms

The software factory, the automated, agent-driven pipeline through which modern engineering teams now ship code, has throughput and signal requirements that general-purpose platforms were never built to satisfy. A merge queue designed for a human cadence of pull requests does not become composable into an agentic pipeline by bolting on a webhook. Its underlying data model has to treat agent-generated commits, CI failure patterns, and queue state as first-class objects from the start, not as exceptions handled after the fact.

Code storage built around human-first workflows carries the same mismatch. Branching UX, blame views, and notification surfaces built for people impose latency and structural assumptions that a cloud-native agent neither needs nor can efficiently route around. Tools like Backstage, Crossplane, and Kratix show that composability can be built correctly when the architecture is designed for substitutability from the outset. Graphite's stack-aware merge queue shows the same discipline applied to pipeline throughput. The vendors worth taking seriously on this claim are the ones building for agent-scale throughput and signal exposure as a starting requirement, not the ones retrofitting an API onto a platform that was never meant to come apart.