DataCenterVirtualization

Hyperwashing: What Makes a Solution Hyperconverged?

DataCenterVirtualization

Whenever an innovation or buzzword gets popular, it is natural for marketing to pile on and apply the word to products. We are starting to see “hyperconverged” achieve this sort of recognition. Early hyperconverged vendors built their solutions from the beginning to be hyperconverged and deliver a set of values. These vendors continue to work at educating the market on the nature and value of hyperconvergence. Now, the customer appetite for hyperconverged solutions is proven and lucrative. Other vendors are calling their products “hyperconverged” because they have some of the characteristics, but giving something a name doesn’t change its nature. At the same time, giving something the wrong name doesn’t mean that thing isn’t valuable. So, what does make a solution hyperconverged? What is it about these solutions that makes them deserve a different name?

Disclosure: I work with a lot of hyperconverged vendors. SimpliVity is a current client, and Nutanix is a past client.

Some common, core hyperconverged characteristics:

  • Scale-out appliance architecture
  • Hypervisor, compute, and storage in the same appliance
  • VM as the unit of workload
  • Backup and replication integrated into appliance
  • Simple, unified management

In my view, these are the core characteristics of hyperconverged platforms. Some of these characteristics can be achieved by combining non-hyperconverged products. However, the particularly hard thing to add to existing products is simple, unified management with VMs and policies as the core focus. All of the hyperconverged vendors I’ve spoken with are clear in stating that simplifying management is crucial. They also focus on VM-centric management that is policy based. This drives the transformation away from spending a lot of time managing the underlying storage and compute and toward managing applications and their data. These vendors have generally spent a lot of effort to hide complexity from users of their products. Many of the other characteristics of hyperconverged result from this focus. In order to deliver simple VM-centric management, you find that you need a scale-out model with storage and compute converged. To manage backup and DR from the same console, you find that you need to build it into your product.

The point here is to make managing a virtualized datacentre infrastructure as simple as possible. This is also the feedback from hyperconverged customers. They love that they spend less time thinking about infrastructure and have more time for the applications that are inside the VMs. In a way, this is delivering some of the value of IaaS cloud services without moving your VMs out of your datacentre. Every element of the hyperconverged product needs to be measured against the requirement for simplified management. If you are not making datacentre management simpler, you are not making hyperconverged.

Some of the products being sold as hyperconverged are really a bundle of existing products. They have some of the characteristics of hyperconverged. Such a product might be a software-defined storage product running on commodity hardware and bundled with a backup product, for instance. The danger is that the vendor may not really understand that these parts are the result, not the objective, of hyperconverged. Unless these products also have a unifying management tool that focuses on VMs, they aren’t hyperconverged. That isn’t necessarily a bad thing. A collection of existing technologies bundled together to make a solution is really converged, not hyperconverged. These bundles help customers by simplifying ordering, deployment, and support.

Building a “Best of Breed” datacentre involves selecting from an infinite choice of parts. Once you have selected the parts, you must also work out how to make them all work together. This could be as simple as getting the right type of connectors, or as complex as working out how to guarantee VM performance when you replicate between dissimilar storage arrays. Then comes the ongoing maintenance. Making sure version updates to one component are compatible with every other component can take days of research and testing. After that comes managing support calls across multiple vendors. Who will take responsibility for a compatibility issue? A preselected collection of parts that have been thoroughly tested is much simpler and involves far less risk. Just like a Vblock or a reference architecture, these new bundles can simplify buying, building, and operating a virtualized datacentre.

Having a scale-out storage and compute product with some backup and DR software doesn’t mean you have a hyperconverged product. You still have something valuable to customers, but without unified VM-centric management, you don’t have hyperconverged. Using a popular term to describe a product is nothing new in marketing. As always, customers need to exercise due technical diligence in selecting products and choose what suits their requirements. Hyperconverged isn’t the only way to build an infrastructure; converged systems still have a place.

Share this Article:

The following two tabs change content below.
Alastair Cooke
Alastair Cooke is an independent analyst and consultant working with virtualization and datacenter technologies. Alastair spent eight years delivering training for HP and VMware as well as providing implementation services for their technologies. Alastair is able to create a storied communication that helps partners and customers understand complex technologies. Alastair is known in the VMware community for contributions to the vBrownBag podcast and for the AutoLab, which automates the deployment of a nested vSphere training lab.

Related Posts:

Leave a Reply

Be the First to Comment!

wpDiscuz