One of the main benefits of hyper-converged infrastructure is that organizations can buy compute, storage and virtualization resources from a single vendor. This leads to faster implementation times and should reduce operational costs. But it also opens the door to vendor lock-in, since, in theory, all future purchases need to come from that same vendor. Is vendor lock-in something IT professionals should be concerned with and even try to avoid as they move down the hyper-converged technology path?
What's really locked?
Most hyper-converged products are turnkey, meaning the vendor preselects hardware -- servers and storage -- and software for the customer and preloads the software onto the hardware. In almost every case, the hardware selected is the same off-the-shelf hardware the customer would get when ordering it separately. The software, in most cases, is also off-the-shelf. Most hyper-converged architectures use an industry standard hypervisor like Hyper-V or VMware. A few use a Linux variant and may customize it.
Pragmatically speaking, most of these components should not be "locked-in." The reason to force a customer to buy these components from the original hyper-converged technology vendor is superficial, and most vendors will claim they do it to improve their ability to support the customer. They also do it to increase their profits.
Where most of the differentiation occurs is in the storage software, which is responsible for aggregating storage across the servers making up the hyper-converged cluster. The software may also provide data management and data services. Vendors may use the storage software to justify the forced buy of some of the other components. But given a list of these components, there is no reason customers can't buy them on their own.
What the vendor legitimately locks in is the storage software. It is reasonable to expect that the organization will have to continue purchasing software from the hyper-converged vendor for the foreseeable future. This requirement is nothing out of the ordinary and is common throughout IT.
Is hyper-converged lock-in bad?
Getting all your products from a single vendor is not necessarily a bad thing. A turnkey system provides rapid implementation times and allows an organization to derive value from the purchase almost immediately. There is even value in forcing upgrades to the hyper-converged technology infrastructure after the initial purchase because it speeds expansion and simplifies operations. There is no denying that having a common hardware and software platform and interface is simply easier to maintain and expand.
A downside to lock-in is flexibility. If the hyper-converged vendor is slow to add support for a certain type of server or storage, the lock-in can be frustrating. This is especially true in systems design. For example, some hyper-converged architectures are all-flash, while others are hybrid-only, which can't be bought in an all-flash configuration. If a customer wants the value of hard drives for archival data or the ease of an all-flash configuration, this lack of flexibility can be problematic.
The other downside to vendor lock-in comes up if the vendor has financial issues, falls out of favor with your organization or is purchased by another vendor that allows development to languish. These are concerns no matter the technology, but since the customer is all-in with this particular vendor, the ramifications are greater.
Avoiding certain aspects of hyper-converged technology lock-in are more difficult than others. For example, it should be fairly easy to find a vendor that will negotiate with you and allow you to provide your own hardware if that is important to your organization. However, when it comes to software, negotiating to buy on your own can be difficult or impossible.
While the hypervisor used by a hyper-converged architecture is typically a prepackaged offering, most architectures can only run one hypervisor. Running multiple hypervisors requires multiple independent clusters. With an increasing number of data centers actively running more than one hypervisor in production, this limitation can be a legitimate issue.
The storage software is, most of the time, proprietary. In short, if you're going down the hyper-converged technology route, make sure you like the storage software, how it incorporates new technology and the interface used to manage it. And confirm the company seems stable enough for long-term survival.
Open hyper-converged platforms
A potential solution is selecting an open hyper-converged architecture. These platforms are identical to typical hyper-converged products except the hypervisor and the storage software are based on open standards. Providers of these platforms install them on off-the-shelf hardware and deliver them as a package to their customers, eliminating one of the primary frustrations of open software: the amount of time it takes to implement. At the same time, these architectures are indeed open, so it is possible to implement alternative hardware if desired and as the cluster grows.
Most importantly, open software provides some level of flexibility in switching between various storage software products. While not 100% portable, a customer should be able to move between vendors that leverage the same open source core.
Open hyper-converged architecture has its challenges. While the software is potentially better tested than commercial alternatives, packaged products are usually delivered by smaller companies or local resellers. And as the platform expands, it is still open source by nature, which is often Linux-based. A hyper-converged technology vendor can hide many of the Linux complexities, but not all of them.
Organizations choosing the hyper-converged path usually do so because of the perceived benefit of faster time to value and simplicity of operations. Much of the hyper-converged simplicity and speed comes from the tight control the vendor maintains over the delivery experience. But that tight control comes with some degree of vendor lock-in. Organizations can take steps to limit lock-in, but each step may complicate implementation and increase the complexity of operations.
Completely hyper-converged platform could be a compelling choice
Case study: How a college uses Dell EMC hyper-convergence