Michael Schmidt 
Almost every infrastructure refresh since 2010 has been a version of the same question: how much of the stack should arrive as a single unit? Converged infrastructure answered “the rack.” Hyperconverged answered “the node.” Both answers are still on the table, and most of the comparison pages that rank for this question still present them as the only two.
That framing is roughly a decade old. It was written when the licensing model was stable, when the hypervisor was a given, and before anyone was pricing an exit. The choice a buyer faces in 2026 has a third leg, and the differences between the three are not really about hardware layout. They are about what your scaling unit is, what fails together, and what the vendor counts when it prices you.
Converged infrastructure: one purchase order, three separate layers
Converged infrastructure (CI) is a pre-validated stack of servers, network switches, and a shared storage array, sold and supported as one SKU with a reference architecture behind it. The layers underneath stay exactly what they were. The array is still an array, with its own controllers, its own firmware cycle, and its own license.
What CI genuinely solved was procurement and blame. One order, one support number, one tested combination of firmware versions, and no argument about whether the fault lies with the switch vendor or the array vendor. For large enterprises standardizing dozens of sites, that was worth real money.
What it did not solve is the shape of the growth curve. Capacity growth means an array upgrade, and the controller pair in front of that array is a hard ceiling that arrives whether or not your capacity forecast was right. Refreshes are lumpy: you replace a validated block, not a component, because stepping outside the validated combination is what you paid to avoid. The array’s licensing usually counts controllers or raw capacity, so the array’s economics and the server tier’s economics never quite line up.
Hyperconverged infrastructure: the array dissolves into the servers
Hyperconverged infrastructure (HCI) removes the array. Storage software runs on the compute nodes themselves, pools the local drives across the cluster, and presents that pool back to the hypervisor or to Kubernetes. One management plane covers compute and storage, and the cluster grows by adding a node.
That was a real improvement on the CI growth curve. Expansion is incremental instead of lumpy, there is no controller ceiling to plan around, and a single team can operate the whole thing.
The cost is that the node becomes the unit of everything. When you need capacity and nothing else, you buy a node, which means you buy CPU sockets and memory you did not need, rack them, power them, and then license them. Most commercial HCI platforms count cores or nodes, so the very density that should have made storage cheaper (bigger, faster drives per chassis) does nothing for the bill or actively raises it. The failure domain fuses too: losing a node takes out compute capacity and a copy of data at the same moment, so rebuild traffic lands on the same cluster that is already down a node and still serving production.
None of that makes hyperconvergence wrong. It makes it a trade, and the trade is only visible once the growth is uneven, which is exactly the condition most platforms reach after a few years.
Is your storage capacity growing faster than your compute needs? If the next capacity increment means buying cores you will never schedule, the scaling unit underneath is worth a conversation. Talk to a storage architect
The third option: disaggregation over a storage fabric
There is a third arrangement, and it is missing from nearly every page that ranks for this comparison. Storage runs as its own software-defined pool on its own nodes, and compute reaches it over a network fabric using NVMe over TCP or NVMe/RoCE, presented to Kubernetes through a single CSI driver.
This looks superficially like a return to the array, and it is not the same thing. A CI array is a fixed appliance with a controller pair in front of it and a proprietary management path. A disaggregated pool is software on standard servers, scaled by adding capacity nodes, with no controller pair as the ceiling and no separate operational model from the platform it serves. What returns from the CI era is the useful part, meaning storage that scales on its own axis. What does not return is the appliance.
The practical differences line up cleanly once you compare them on the four properties that actually drive cost and risk.
| Property | Converged (CI) | Hyperconverged (HCI) | Disaggregated |
|---|---|---|---|
| Scaling unit | Validated block, array upgrade for capacity | The node, compute and capacity together | A drive or capacity node, independent of compute |
| Failure domain | Array and servers fail separately | Node loss removes compute and a data copy at once | Storage node loss does not remove compute |
| Typical licensing metric | Controllers plus raw capacity | Per core or per node | Per usable capacity |
| What a refresh replaces | The validated block | Whole nodes, including healthy drives | Compute and storage on separate cycles |
Table 1: The three arrangements compared on the properties that determine cost and blast radius.
The licensing row is the one that has changed most since these comparison pages were written. When the metric is cores, every capacity decision is also a licensing decision, and hardware density stops working in your favor. When the metric is usable capacity, denser servers make the platform cheaper per terabyte rather than more expensive.
Choosing after a VMware® exit
Most people reading this are not designing a greenfield data center. They are standing in front of an aging CI stack whose array is out of support, or an HCI renewal that just repriced, and the question is which of the three to move toward while also moving off a hypervisor.
That context changes the weighting. A migration is the one moment when the scaling unit is genuinely up for renegotiation, because you are already re-platforming the workloads. It is also the moment when committing to a new appliance vendor reproduces the situation you are leaving: a single supplier controlling the platform, the storage, and the price of both.
| Your situation | The pressure you are feeling | Where to look |
|---|---|---|
| CI stack, array end of support | A large, lumpy capacity purchase with a controller ceiling | Disaggregated, so capacity stops arriving in validated blocks |
| Small cluster, uniform workloads | Operational simplicity matters more than scaling precision | Hyperconverged is a reasonable fit and stays one |
| Capacity growing faster than compute | Buying cores to get terabytes | Disaggregated, so the two scale on their own axes |
| Moving VMs to KubeVirt or Red Hat® OpenShift® Virtualization | Live migration needs shared write access to the same volume | Either model, provided the storage layer offers RWX block |
Table 2: Which arrangement fits which starting position, for teams re-platforming off VMware.
Simplyblock is deliberately not a single point on this table. The same software runs hyperconverged, with storage co-located on the compute nodes, or disaggregated, with storage on its own nodes reached over the fabric, and the two can coexist in one cluster. Both are driven by one control plane and one StorageClass model, so the decision above does not become a procurement commitment you cannot revisit. Licensing follows the platform rather than the deployment shape, by worker-node CPU capacity the way the subscription counts it, with data volume not changing the price, and RWX block comes from the same StorageClass as RWO, which is the requirement VM live migration actually imposes.
For the storage-architecture depth on the hyperconverged-versus-disaggregated leg specifically, including replication behaviour and the I/O path, our post on disaggregated or hyper-converged Kubernetes storage covers that argument in full. This page is the category-level decision that sits above it. If the destination is OpenShift specifically, the software-defined versus appliance comparison for HCI storage is the next step, and the cost math behind a vSAN exit covers the licensing side in detail.
Questions and Answers
What is the difference between converged and hyperconverged infrastructure?
Converged infrastructure is a pre-validated bundle of servers, switches, and a shared storage array sold as one SKU, where the array remains a separate system with its own controllers and licensing. Hyperconverged infrastructure removes the array and runs storage software on the compute nodes themselves, pooling their local drives. The practical difference is the scaling unit: CI grows by validated blocks and array upgrades, HCI grows one node at a time, which also means capacity and compute always grow together.
Is hyperconverged infrastructure always better than converged?
No. Hyperconvergence fixed the lumpy growth curve and the split management plane, which is a genuine improvement for small to mid-size clusters with uniform workloads. It introduced a different constraint: the node is the only increment, so buying capacity means buying and licensing compute you may not need, and a node failure removes compute and a copy of data simultaneously. Whether that trade is worth it depends on whether your capacity and compute needs grow at the same rate.
What is disaggregated infrastructure, and how is it different from a storage array?
Disaggregated infrastructure runs storage as its own software-defined pool on standard servers, reached by compute over a network fabric using NVMe/TCP or NVMe/RoCE. Unlike a converged array, there is no fixed controller pair acting as a ceiling and no proprietary appliance management path: capacity scales by adding nodes or drives, and the storage is presented to Kubernetes through a standard CSI driver. It restores independent storage scaling without restoring the appliance.
Which model should we choose when migrating off VMware?
A migration is the right moment to reconsider the scaling unit, because the workloads are being re-platformed anyway. If capacity is growing faster than compute, or the current array is at end of support, disaggregation removes the coupling that causes both problems. If the cluster is small and the workloads are uniform, hyperconverged remains a sound choice. The requirement worth checking before committing either way is ReadWriteMany block support, since VM live migration on KubeVirt and OpenShift Virtualization depends on it.
Does simplyblock require choosing between hyperconverged and disaggregated?
No, and that is the point of listing it as a peer in both categories. The same storage software can be deployed hyperconverged on the compute nodes or disaggregated on dedicated storage nodes over NVMe/TCP or NVMe/RoCE, with both modes managed by one control plane and consumed through the same CSI driver and StorageClass model. Licensing follows the platform rather than the deployment shape, by worker-node CPU capacity the way the subscription counts it, and the deployment model can change later without a migration to a different product.
