Hyperconverged Infrastructure Won the Battle — Then Created the Next Problem

Hyperconverged infrastructure won the architecture argument it set out to win, and the way it won is exactly why the next problem is harder than the last one. The companion piece on Kubernetes and virtual machines argued that the enterprise stack is a set of layers stacked on top of each other, not layers replacing each other in sequence. HCI is the exception worth studying: the one place in the modern stack where a layer genuinely collapsed. Storage stopped being a tier and became a property of the node.

That collapse was the right call for most of the last decade. It also turned the node into the unit of architecture — the single object that carries capacity, performance, failure, lifecycle, licensing, and operations at the same time. As workloads diverged, the vendors that built HCI began separating storage again. The storage boundary is returning. In many organizations, nobody is assigned to own it.

What Hyperconverged Infrastructure Actually Won

Hyperconverged infrastructure won two things, and both were real.

The first was physical. In a traditional three-tier design, storage I/O normally crosses a network or storage fabric to reach a separate storage system before the host receives its completion, and the array controller becomes a shared resource for the workloads behind it. HCI moved storage processing into software running across the nodes and made local cluster resources part of the primary storage path. The external storage round trip stopped being the default architecture.

The second was organizational, and it mattered more. Three-tier storage ran on a ticket loop: request capacity, wait for a LUN to be carved, masked, and zoned, rescan, format, repeat. Every step was a handoff between teams. HCI replaced the handoff with a policy — which is the argument the storage handshake is dead made in detail. Within virtualization architecture, that is the most consequential simplification since the hypervisor itself.

None of that is being revised here. For general-purpose VM estates, convergence was the right answer and mostly still is. The problem this post is about sits downstream of the win, not inside it.

The Node Became the Unit of Everything

When storage lives in the node, the node stops being a server and becomes the atomic unit of the architecture. Every concern that three-tier distributed across separate boundaries — and usually separate teams — now lands on one object.

That coupling is what made HCI simple: one object to buy, size, patch, and support. It is also why the costs of hyperconverged infrastructure show up per node rather than per tier. The controller tax is a reservation paid on every host before a single guest runs. And because a node in maintenance takes its share of the storage fabric with it, every rolling upgrade is a controlled failure event — the change-control row in the table above, expressed as operational physics. The Virtualization Storage and Network Architecture stage covers how convergence reshapes storage and network design at the platform level.

It’s worth being precise about what this post is not. Sizing a converged cluster to survive its own degradation is the Failure-State Envelope (Framework #88), and it lives in the HCI Failure-State Architecture track — that’s about keeping the node-as-unit deterministic under rebuilds and upgrades. The same track’s Platform Gravity cluster covers the cost of leaving an HCI platform. This post is about the third case: you stay, and the architecture starts separating underneath you.

The Uniform-Node Assumption Breaks

The economics of hyperconverged infrastructure rested on an assumption rarely stated out loud: that workloads are roughly uniform. General-purpose VMs grow compute, storage, lifecycle, and failure requirements together, closely enough that one node shape fits. For most virtualization estates, that held. It does not hold for the workloads now arriving on the same platforms — and they break it along four different axes, not one.

Each of these is already visible in the field. Persistent-volume contention against VM datastores on shared HCI is a constraint that has to be modeled whenever Kubernetes becomes part of the VMware exit path. At the edge, the capacity arithmetic is the same one worked through in two nodes can preserve availability without preserving N+1 capacity — applied to nodes that carry storage as well.

The disaggregated HCI discussion focused primarily on economics — the SQL cluster at 90% CPU sitting on empty disk. The broader pattern is that modern workloads increasingly diverge on lifecycle, authority, and failure assumptions as well. Economics is the divergence that shows up on a quote. The other three show up later, in change windows, restore decisions, and incident bridges.

The Vendors Are Restoring the Boundary

This is not a prediction that traditional three-tier architecture returns. It is an observation that storage boundaries are reappearing inside platforms that originally succeeded by removing them.

When Rack2Cloud first covered Nutanix compute-only nodes running on external arrays, Breaking the HCI Silo framed disaggregation as a pragmatic compromise for VMware exits — a way to keep a working SAN that was still under contract — with full convergence as the destination to build toward. That was a fair reading of the evidence at the time. The evidence since says the separation has outlived the migration rationale that introduced it.

Nutanix’s fiscal 2026 Form 10-K describes integrating the Nutanix Cloud Platform with qualified external storage so customers can deploy NCI with external storage. Current offerings are Dell PowerFlex, Dell PowerStore, and Everpure, Inc. FlashArray; NetApp ONTAP-based and Lenovo ThinkSystem integrations are announced, with the NetApp solution in limited availability. On the VMware side, vSAN storage clusters — previously vSAN Max — are a documented deployment option that provides disaggregated storage to vSphere clusters or augments traditional vSAN HCI clusters. VCF 9.0 went further and added a dedicated VMkernel traffic type to separate storage-cluster client traffic from vSAN traffic. The storage network is a design object again.

Both platform vendors kept the control plane converged — Prism and vCenter still front the external tier — while the data plane separates underneath. That is not a retreat from hyperconverged infrastructure. It is a correction to its assumption.

The market is not abandoning convergence. It is selectively restoring separation where uniform nodes no longer fit the workload.

The Handshake Comes Back. The Other Side of It Doesn’t.

As hyperconverged infrastructure adoption expanded, many organizations consolidated storage responsibilities into virtualization and platform teams. Specialized practices such as array compatibility management, storage-fabric design, multipathing, and array-side data services often became less visible operational concerns. That consolidation was rational. When storage is a property of the node, a separate storage function is overhead.

Restoring the boundary brings those practices back as live responsibilities:

• Storage-fabric design — protocol paths such as NVMe/TCP where used, MTU consistency, switch capacity and buffer behavior, and traffic separation between client and replication traffic.
• Compatibility management — an array firmware matrix that may now have to stay aligned with the virtualization platform’s release train.
• Data-service authority — platform and array layers may each expose snapshots, replication, or restore controls, creating a decision about which layer is authoritative for each operation.
• Support boundaries — a latency problem that lives between two vendors, and a first call that has to go to one of them.

None of these went away during the HCI era. They were absorbed into the node, where the platform handled them. Once they sit on a seam again, someone has to own them — and the boundary is returning faster than the expertise that used to govern it.

This is the same misdiagnosis that shows up in VMware exits, where the hypervisor is not the migration target — the operating model is. The architecture decision gets made; the ownership model doesn’t move with it. And it cuts against what HCI actually sold. If the next virtualization battle is operational simplicity, then restoring the seam means simplicity has to be re-earned by design. It can no longer be inherited from the node.

Deciding Where the Seam Goes

The right response to the uniform-node assumption breaking is not to abandon hyperconverged infrastructure or disaggregate everything. It is to separate storage only where a workload actually diverges — and not before someone owns the seam that separation creates.

The fourth column is the one most separation projects skip. Posture and seam are architecture decisions, and vendors make them easy to buy. The seam-owner column is an organizational decision, and nobody is selling it. It answers one question: who is accountable when the seam fails?

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →