Product categories and labels can be useful for IT professionals who are involved in the process of identifying and evaluating potential solutions for a new project or infrastructure upgrade. Vendors and analysts are also interested in these product categories (in fact, they usually create them), for the same reasons, in order to facilitate comparison.
But sometimes vendors and analysts can get too restrictive on how they define these categories, excluding some products unnecessarily. This has happened with HCI recently with the advent of disaggregated architectures, where the storage and compute functions can be run on separate nodes. In this blog we’ll talk about why HCI as a product category should include disaggregated architectures.
To Be or Not to Be HCI
HCIs have some fundamental benefits that have helped to explain its significant success. These are the reasons users look at HCIs as a potential solution to begin with and are part of the process for evaluating individual products. They include:
HCIs also have some basic technology characteristics that drive these benefits, including the following:
The definitions that some in the industry use for what qualifies a product as an HCI are mostly based on these technical characteristics or features, not on benefits. Unfortunately, ignoring benefits in this definition ignores the value HCIs provide real customers in real-world use cases. Ignoring this real-world use of a product definition or category makes it largely an academic exercise.
Features also evolve as technologies mature. New products come out that provide the benefits of existing HCI solutions, but expand the technical definitions that have been set up, and provide additional benefits. The problem occurs when these HCI definitions don’t evolve as the technology evolves.
Disaggregated HCI Architectures
One of the historical shortcomings of HCI technology has been the relative inability to scale storage and compute resources independently. You couldn’t really add storage capacity to a given cluster without also adding compute power. While some vendors claimed to have “storage-only” nodes, they were really selling “storage-heavy” nodes. If you needed to increase storage capacity, the nodes you added still included the ability to run VMs.
The reason for this is that each node in a typical HCI runs as a VM (or as part of the hypervisor). This means they have to include compute and memory to run the hypervisor and a hypervisor license on each node.
However, there are some software-defined storage (SDS) architectures that disaggregate storage and compute functions at the node level, offering compute-only and storage-only nodes. This reduces the amount of CPU and memory resources required on storage nodes and eliminates the need for a hypervisor on each node. While these architectures are available in storage systems, this technology can also be a benefit for HCIs, an improvement to their SDS layer that provides more cost-effective scaling.
Should that capability disqualify a company from comparing that product to other HCIs?
Of course not. End users are including these products in their evaluations of HCIs because they provide the benefits listed above. But this disaggregated storage architecture seems to have kept some products from being called HCIs, by some vendors and analysts.
NetApp HCI, Dell EMC VxRack FLEX, VxFlex Ready Nodes and Datrium are products that provide the benefits of HCIs listed above, but also have disaggregated architectures. They’re easy to deploy and operate, they’re flexible, scalable and use industry standard server hardware and commodity storage devices. They’re also included in Evaluator Group’s HCI comparison research.
There’s an old marketing expression, “customers don’t buy features, they buy benefits”. While marketing should not drive thoughtful analysis, there is truth to this statement. Product categories and labels should be based on technical features and functionality, but should also include the utility, value and benefits that the user community derives from these features.
Labels need to be dynamic as well, like the technologies they represent. As products, such as HCIs, evolve and become more functional, useful and valuable, their labels need to evolve with them. Such is the case with hyperconverged infrastructures with disaggregated architectures.
