Rob Pankow 
Hyperconverged infrastructure (HCI) has become a standard architectural pattern for running OpenShift in private-cloud and on-premises environments. The appeal is operational simplicity: compute, storage, and networking collapse into a single shared node pool, and the platform manages resource allocation without requiring separate storage clusters or dedicated SAN infrastructure.
What platform teams often discover later is that “HCI” describes a deployment topology, not a single product category. There are two meaningfully different paths to HCI for OpenShift — appliance-based systems that bundle hardware and software into a vendor-controlled stack, and software-defined HCI that runs on commodity or customer-selected servers. The choice between them affects procurement, operational flexibility, hardware refresh economics, and the ability to evolve the platform as workloads change.
What Appliance-Based HCI for OpenShift Looks Like
Appliance vendors sell integrated systems where compute nodes, NVMe or SSD storage, networking, and platform software arrive pre-configured and pre-validated. The vendor owns the hardware reference design and the support boundary. OpenShift typically runs on top of the vendor’s hypervisor or bare-metal layer, and the storage component is managed through vendor-specific tooling rather than standard Kubernetes storage primitives.
The operational advantage is a shorter path from procurement to a running cluster. The hardware arrives tested, the software stack is pre-integrated, and the vendor provides a single support contract that covers the full stack. For organizations that want to minimize internal integration work and can accept a vendor-defined architecture, this is a legitimate tradeoff.
The constraints become visible over time. Capacity expansion means purchasing additional appliance nodes from the same vendor at vendor-controlled pricing. Hardware refresh cycles are tied to the vendor’s product roadmap rather than commodity component availability. Running OpenShift workloads on non-vendor hardware — whether to accommodate existing servers, to reduce cost, or to integrate with other infrastructure — is typically outside the supported configuration.
What Software-Defined HCI for OpenShift Looks Like
Software-defined HCI achieves the same converged topology — compute and storage on shared nodes — using a storage software layer that runs on standard x86 servers with NVMe or SSD drives. The platform team selects the server hardware independently, installs OpenShift and the storage platform, and manages the storage layer through Kubernetes-native CSI interfaces rather than vendor-specific management planes.
The key difference is where the architectural boundary sits. In appliance HCI, the hardware and software are a single product. In software-defined HCI, the hardware is a commodity input and the software defines the storage behavior. This separation gives platform teams control over hardware sourcing, refresh timing, and capacity scaling without a mandatory vendor relationship at the infrastructure layer.
simplyblock takes this approach for Kubernetes and OpenShift storage. It runs as a software-defined block storage layer on top of standard NVMe servers, supports both hyper-converged and disaggregated deployment topologies, and integrates with OpenShift through a CSI driver that exposes storage as standard StorageClasses and PersistentVolumeClaims. simplyblock is a certified Red Hat OpenShift partner, which means it fits standard enterprise OpenShift procurement and support workflows.
HCI Topology Options with Software-Defined Storage
One advantage of software-defined HCI is that the deployment topology is not fixed at procurement time. Platform teams can start with a hyper-converged model — running storage software co-located on the same nodes as OpenShift workloads — and evolve toward disaggregated storage as scale or performance requirements change. Neither transition requires replacing hardware or migrating to a different storage platform.
simplyblock supports both topologies from a single software deployment. In hyper-converged mode, storage daemons run alongside application pods on shared nodes, and NVMe/TCP provides low-latency access to local and remote NVMe drives within the cluster. In disaggregated mode, dedicated storage nodes serve storage over NVMe/TCP to separate compute nodes. Both topologies use the same CSI interface, the same management API, and the same operational tooling — which means a cluster can shift between models as the workload mix evolves without retraining or replumbing the storage layer.
This flexibility matters for enterprise environments that grow or change over time. An initial hyper-converged deployment for a migration project can scale to disaggregated storage as stateful workload density increases, without replacing the storage platform or renegotiating a hardware contract.
Performance Characteristics That Favor Software-Defined HCI
Appliance-based HCI systems are designed for broad workload compatibility, which typically means their storage engines are tuned for steady-state throughput rather than low-latency random I/O. Enterprise databases, analytics engines, and AI inference workloads are particularly sensitive to random read/write latency and I/O queue depth behavior — characteristics that are harder to optimize in a general-purpose appliance.
Software-defined NVMe storage eliminates several layers of overhead that exist in appliance and traditional storage stacks. simplyblock uses an SPDK-based user-space datapath that bypasses the kernel I/O stack, which reduces per-I/O CPU overhead and compresses latency to the sub-millisecond range for block workloads. On commodity NVMe servers — hardware that is widely available and competitively priced — this architecture delivers performance that appliance systems at similar price points typically cannot match.
For workloads like PostgreSQL running on OpenShift, this performance difference translates to query latency, checkpoint behavior, and write-ahead log throughput — the storage characteristics that directly affect database SLAs. Teams running these workloads in hyper-converged OpenShift environments should benchmark actual workload latency rather than relying on appliance vendor throughput claims.
Total Cost Comparison
Appliance HCI pricing reflects the vendor’s integration work, hardware margin, software licensing, and support model. These costs are bundled and non-negotiable: the price per node includes hardware you cannot substitute and software you cannot separate from the hardware purchase.
Software-defined HCI pricing separates hardware and software. Platform teams purchase commodity NVMe servers at market rates — competitive pricing from multiple suppliers — and license the storage software independently. Over a multi-year lifecycle, this separation typically reduces total infrastructure cost, because hardware commodity pricing improves faster than appliance vendor pricing adjusts, and capacity can be added incrementally without full-node appliance increments.
simplyblock’s pricing model reflects this structure. Storage capacity economics improve with thin provisioning, erasure coding, and intelligent tiering that maximize usable capacity from physical hardware — reducing the total storage footprint needed to serve a given workload.
Comparison: Appliance HCI vs. Software-Defined HCI for OpenShift
| Criterion | Appliance HCI | Software-Defined HCI (simplyblock) |
|---|---|---|
| Hardware flexibility | Vendor-selected hardware only | Any commodity NVMe server |
| Deployment topology | Fixed at purchase (typically hyper-converged) | Hyper-converged, disaggregated, or mixed |
| OpenShift integration | Vendor-specific management layer | CSI-native, OpenShift certified partner |
| Storage transport | Vendor-defined (often iSCSI or NFS internally) | NVMe/TCP, NVMe/RoCEv2 |
| Latency profile | Moderate, appliance-tuned | Sub-millisecond, SPDK user-space datapath |
| Capacity expansion | Additional appliance nodes at vendor pricing | Incremental node addition, commodity pricing |
| Hardware refresh | Vendor roadmap dependent | Independent of storage software lifecycle |
| Support model | Single-vendor full-stack support | OpenShift support from Red Hat, storage from simplyblock |
| Multi-tenancy and QoS | Varies by vendor | Built-in, per-workload isolation |
When Each Approach Makes Sense
Appliance HCI makes sense when the organization prioritizes a single vendor relationship across hardware and software, when the team wants a fully pre-validated stack with minimal internal integration work, and when the workload profile does not require extreme storage latency optimization. It is a defensible choice in environments where operational simplicity matters more than hardware cost flexibility.
Software-defined HCI is the stronger fit when platform teams want to control hardware sourcing and refresh independently of the storage platform, when stateful workloads require predictable low-latency block storage, when the cluster topology may evolve between hyper-converged and disaggregated over time, or when total infrastructure cost over a multi-year horizon is a primary evaluation criterion. For enterprise OpenShift programs where storage is a first-class requirement rather than a bundled afterthought, software-defined HCI gives platform teams the flexibility to build the right storage layer for their specific workloads.
Where to continue if this is really a VMware-exit or vSAN-replacement evaluation
If the real buying motion is VMware exit rather than generic HCI education, continue into Hyper-Converged Storage for OpenShift, vSAN Alternative for OpenShift and Kubernetes, and VMware Migration to OpenShift and Kubernetes.
Questions and Answers
What is the difference between appliance HCI and software-defined HCI?
Appliance HCI bundles compute, storage, and sometimes networking into a vendor-controlled integrated system. Software-defined HCI achieves the same converged topology — compute and storage on shared nodes — using software that runs on standard commodity servers. The key difference is that hardware and software are separable in the software-defined model, which gives platform teams more control over hardware sourcing, pricing, and refresh timing.
Can simplyblock run in a hyper-converged configuration on OpenShift?
Yes. simplyblock supports hyper-converged deployments where the storage software runs co-located with OpenShift workloads on the same nodes. It also supports disaggregated deployments with dedicated storage nodes, and mixed topologies. All use the same CSI interface and management tooling.
Is NVMe/TCP suitable for hyper-converged OpenShift environments?
Yes. NVMe/TCP runs over standard Ethernet without requiring specialized networking hardware. In hyper-converged environments, NVMe/TCP provides low-latency access to locally attached NVMe drives as well as drives on other nodes in the cluster, making it well suited to HCI topologies where storage traffic stays within the cluster network.
How does software-defined HCI affect OpenShift storage performance compared to appliance systems?
Software-defined NVMe storage with an SPDK-based user-space datapath typically delivers lower latency than appliance HCI at comparable price points, because it eliminates kernel I/O overhead and is purpose-built for NVMe characteristics. Appliance systems optimize for broad workload compatibility rather than NVMe-specific performance, which creates a performance gap for latency-sensitive workloads like production databases.
Does simplyblock require specialized hardware for OpenShift HCI deployments?
No. simplyblock runs on standard x86 servers with NVMe or SSD drives. It does not require proprietary controllers, specialized networking beyond standard Ethernet, or vendor-specific hardware. This hardware independence is a core part of its software-defined design.
