The hypervisor market is in a state of flux. For over a decade, VMware has entrenched itself as the gold-standard virtualisation platform for enterprises. However, their relentless march for revenue, expected to deepen by announcements earlier this year, has led many users to reconsider their long-term strategy. In the service provider space, the weight of this decision is amplified by the need to maintain margins for public cloud services.
Over the past decade, alternative virtualisation platforms (such as KVM and XCP-ng) have started to demonstrate that they are serious contenders for enterprise use. At ShapeBlue, we have seen a slow but very steady trend of enterprises moving away from VMware to alternative hypervisor technologies.
At the same time, enterprises are aware that the complexity of changing virtualisation platforms presents a significant challenge. This is compounded by years of lock-in strategy by vendors such as VMware.
But what should enterprises do? VMware is so entrenched in many enterprises that a big-bang migration is unrealistic for most. That entrenchment is often made up of a number of factors:
- Application dependencies – Some apps are only supported or certified to run on specific hypervisors.
- Stack dependencies – Most modern enterprises have sought to automate their virtualisation layer over the last few years. If that automation relies directly on the APIs presented by the hypervisor, it creates yet further lock-in.
- Skills dependencies – Enterprises often take years to build up skills in order to be able to run a virtualisation platform successfully.
- Functional dependencies – VMware does have some excellent functionality and tooling, which isn’t always provided by alternative hypervisor platforms.
So, if an enterprise plans to move to a different virtualisation platform (or at least keep its options open), they have to overcome these entrenchment factors. But how?
Application dependencies can ultimately only be resolved by the application vendors. Yes, customers can apply pressure on those vendors to increase the number of platforms they support, but ultimately it is out of the direct control of the enterprise itself. Therefore, it becomes important that enterprises can operate a mixed hypervisor environment: being free to choose the platforms that suit them commercially and strategically whilst, at the same time, being able to maintain specific environments to support specific vendor apps.
Stack dependencies are a problem that has been created by many enterprises themselves: they have always worked on the assumption that their virtualisation building blocks were going to be a constant. To a certain extent, it is this situation that allows VMware to be so bullish with its customer base.
The answer to these stack dependencies is to bolt in an abstraction layer between the hypervisor tech (and its APIs) and the enterprise’s automation tooling. At ShapeBlue, we work overwhelmingly with Apache CloudStack and have seen recent and increasing demand from enterprises with exactly this use case.
Apache CloudStack is an IaaS Orchestration Platform supporting a huge list of hypervisors. CloudStack can orchestrate virtually the entire range of hypervisors on the market, enabling cloud capabilities for enterprise infrastructure, and completely decoupling the infrastructure from user operations. This means that users don’t need to know anything about what’s running on the IT infrastructure, such as the network, servers, hypervisors, firewall, load balancer, VLANs and VPN as these resources are virtualized by CloudStack.
CloudStack is designed to solve the problem of wanting to orchestrate large virtualised environments as an IaaS cloud, but it has a number of secondary benefits that help address these two types of dependencies.
- By definition, CloudStack is an abstraction layer. It presents its own API and then hides the specifics and complexities of talking to any specific hypervisor platform. Most importantly, as CloudStack is an open-source project, maintained by the Apache Software Foundation, vendor lock-in is not on the agenda.
- CloudStack supports a broad range of hypervisors (VMware, KVM, Xen, XCP-ng, etc.) and makes it very easy to run mixed hypervisor environments. Importantly, users of the environment access any resources (irrespective of hypervisor type) through one API or one UI
The skills dependency is more complicated. CloudStack abstracts away a lot of the complexity of running one or more hypervisor types. That single API and single control panel will mean most consumers of the virtualised platform do not need to directly interact with the specific vendor tooling, however, enterprises will still need to have to relevant skills in place to support the actual virtualised environments.
VMware has developed some excellent functionality over the last few years, and some of it simply isn’t offered by other virtualisation platforms. But that, again, is where CloudStack adds value. CloudStack aims to bring a common function set across all supported hypervisors and has the capability to effectively recreate some of the more advanced functionality offered by VMware. For example, clustering hosts is something that VMware has supported for a long time but has always been difficult with KVM – CloudStack takes care of that: if it’s orchestrating VMware, it lets VMware handle the clustering, if it’s orchestrating KVM, it handles it by itself.
CloudStack as a VMware Abstraction Layer
Apache CloudStack has the ability to easily onboard existing VMware assets, including instances, networks and storage, with no downtime – just point CloudStack at your VCenter and you can start using it as an abstraction layer within minutes. In this way, Apache CloudStack can connect natively to the VMWare API and register existing instances exporting their respective meta-data configurations, cataloguing the legacy, and handing over to users the management of these resources via the powerful CloudStack API or UI.
Adding a second hypervisor type to the environment can also be easily done in minutes.
Applicable Use Cases
- Reducing VMware licencing costs
When looking to reduce licensing costs, CloudStack is the most adherent alternative as it can manage multiple existing VMware data centres. CloudStack seamlessly integrates with VMware and embeds many cloud functionalities essential to day-to-day life, eliminating the licensing cost of proprietary control pane tools.
- Running mixed hypervisors at the same data centre
Once VMware is managed by Apache CloudStack, you can adopt a strategy to add more hosts running other hypervisors, mixing both, and sharing the same infrastructure (switches and storage). This strategy brings great flexibility and helps remove vendor lock-in dependence on a single hypervisor vendor. Other Orchestration Platforms do not support running multiple hypervisors on the same data centre infrastructure. Additionally, CloudStack is the only Orchestration Platform that supports such a wide range of hypervisors from different vendors at the same time.
Below are all supported Hypervisors:
- Ubuntu 18.04 LTS, 20.04 LTS, 22.04 LTS with KVM
- CentOS 7 with KVM
- Rocky Linux 8 with KVM
- Red Hat Enterprise Linux 7, 8 with KVM
- openSUSE Leap 15
- SUSE Linux Enterprise Server 15
- XenServer versions 7.1, 7.2, 7.4, 7.5, 8.0 with the latest hotfixes
- XCP-ng 7.4.0, 7.6.0, 8.0.0, 8.1.0, 8.2.0
- VMware versions 6.5, 6.7 and 7.0
- LXC Host Containers on RHEL 7
CloudStack can’t directly fix the commercial issues with VMware and their customers, but it can very easily be used to remove many of the dependencies that stop enterprises from exploring alternatives. CloudStack can be used as a basis for a “natural migration” away from VMware, reducing the impact when adopting another hypervisor vendor, and mixing the existing VMware estate until its EOL.
Apache CloudStack is an IaaS platform widely used in production, including some of the world’s largest companies. It is simple to implement and manage, also reducing operational costs.