Product progression is always interesting to see. In particular, I like to see products that grew up around one platform developing into adjacent platforms. Early hyperconverged infrastructure (HCI) products usually only supported one hypervisor—most commonly, vSphere, as VMware dominated data center virtualization. But vSphere isn’t the only hypervisor in town, and recently, we have seen more HCI products that support multiple hypervisors. Supporting multiple hypervisors opens up more of a market for HCI vendors and provides options for customers. Multi-hypervisor support is not created equal in all HCI products.
At first, a lot of lip service was paid to multiple hypervisors: “Yes, we support Hyper-V or KVM, but 99% of customers use vSphere.” This level of support doesn’t really help customers—it just fills a tick box on the buyer’s checklist: “Does the product support multiple hypervisors (Y/N)?” Neither the buyer nor the HCI company really expects the alternative hypervisors to be used. Of course, one or two customers don’t get that message and end up getting burnt with the incomplete support for the alternatives. The issues with early Hyper-V on Nutanix problems, where the boot SSD wore out prematurely because Windows writes a lot to the boot volume, are examples. Such issues are easily resolved with engineering that is a bit better; however, that engineering doesn’t happen until there is strong market desire to use the alternative hypervisor.
There is an excellent argument for HCI vendors using an open-source hypervisor, usually KVM. It centers on the visibility of the product roadmap. The HCI vendor has more clarity and even control of the open-source hypervisor than it has with vSphere or Hyper-V. The process to validate new versions of the HCI platform or the hypervisor are all under the HCI vendor’s control. Even better, the development process for the hypervisor is open, so the HCI vendor sees far more of the roadmap and progress as new features are developed. This way, there are no surprises, such as when VMware changes the way ESXi accesses storage between versions.
There is a commercial reason for HCI vendors to want options beyond vSphere. VMware has been very focused on its own HCI solution, vSAN. Now, VMware is competing with the HCI vendors, as are server vendors who have vSAN-ready hardware. The HCI vendors need a more differentiated offering; they need capabilities that vSAN does not. Multi-hypervisor support is one obvious direction. There is an economic reason, too. If HCI customers don’t need to buy vSphere licenses, then HCI vendors can offer a cheaper solution without cutting their profit on each sale. The vSphere license can be as much as a third of the acquisition cost of an HCI platform. Without the hypervisor cost, it is economical to use smaller physical server configurations and so to keep the total solution cost lower and attractive to more customer requirements.
There is still a significant challenge migrating existing environments to a new hypervisor. Usually, it takes considerable effort to migrate VMs from one hypervisor to another. The result is that often, an alternative hypervisor is used for a new workload, rather than to replace the hypervisor under an existing application workload. Tools that simplify the migration from one hypervisor to another will help with sales of multi-hypervisor HCI. The second impediment is the change of operational tools and processes. VMware’s vCenter does not manage KVM or Hyper-V VMs. Customers moving to a new hypervisor will be wary of the changes to management tools, as well as to VMs.
With that stage set: Maxta recently announced that it has a partnership with Red Hat for a KVM-based HCI platform. Maxta has a software-only HCI product that allows customers to pick their own collection of hardware to suit their workload. Now, Maxta customers can also select their choice of hypervisor (VMware or Red Hat) to satisfy their requirements. Software-only HCI is very attractive to markets where budgets are tight and skilled people are cheap. The cost saving of separating hardware and software comes with a requirement for more expertise at making them work together. In markets like the US and EMEA, where these skills are expensive, we see appliance-based approaches win. The vendor does the integration and charges a premium for the integrated product. Maxta has had a lot of success in China, where price reigns and skilled staff aren’t paid US salaries. Maxta has a partnership with Lenovo, which is probably helping it in China. With the right partnerships, Maxta could have similar success in the other BRICs economies (Brazil, Russia, India, China). Maxta should also embrace more of Red Hat’s products, such as CloudForms (a cloud management platform) and OpenShift (a container platform) to deliver more value.
Putting Red Hat virtualization on the Maxta platform is just a part of the engineering, a crucial part of the “VMware escape pod” that makes moving VMs from vSphere to Red Hat virtualization simple. The escape pod is a clear poke at Maxta’s long-time partner VMware. Poking at bigger companies is one of Maxta’s traits. At VMworld, Maxta ran a campaign targeting Nutanix, which seemed to irritate some Nutants. Someone later raided the Maxta stand and removed marketing materials.
Maxta is having success in non-US markets and is likely to see more progress with Red Hat virtualization in more non-US markets. There may come a day when Maxta is widely used in small cloud platforms in the US, where price reigns.