Moving past VMware: Migration vs. Lift & Upgrade

Executive Summary

• Viable migration paths depend on type and amount of virtualization workload and willingness to move into the cloud
• Regardless of the migration path any enterprise stack will require extensive effort to move from VMware to any other hypervisor
• Lift & upgrade from VMs to container based solutions can be a real alternative 

Many VMware customers are looking for alternatives

VMware was acquired by Broadcom last year and has since announced to deprecate 56 of its products including many of their perpetual license products. To put this in perspective the entirety of Google’s application software “graveyard” only contains 59 products - VMware and its new owner Broadcom are about to sunset almost the same amount of products in a single run. The motivation for doing so is to push more of their customers into the cloud offerings and increase subscription based revenue. For some customers this can lead to price increases of multiple hundred percent. Switching from perpetual VMware licenses (a fixed asset which can be depreciated) to a SaaS, subscription based offering introduces additional ongoing costs that can affect balance sheets long term.

Companies starting to look for alternative solutions now have a difficult choice to make. There are numerous software vendors also providing virtualization stacks, some are open-source and therefore license free whereas other offerings i.e. from Microsoft are, like VMware proprietary and come with new license fees. Some alternatives will be closer in terms of features and usability to VMware and others will be quite a departure in terms of user experience and workflows. Also there may be alternatives to virtualization all together and we will explore a potential migration to container based solutions later in this paper.

The best choice will directly depend on a few things: How many VMs need to be migrated, where does the team have expertise and how good are they at learning new technologies. Also the level of required support and SLAs from the new vendor might rule out some alternatives be it for compliance or other reasons. 

No matter which provider comes out on top a migration is going to be challenging. The virtualization stack is a deeply embedded technology and operating teams have to learn a completely new environment. Managing this task in a secure way without jeopardizing the current production landscapes alongside the day to day will be hard for any IT organization.

Migration Paths and Challenges

VMware has a massive ecosystem and some have argued that the main reason that adoption of alternatives (prior to the broadcom acquisition) stagnated was mainly the absence of ecosystems elsewhere. Why are ecosystems relevant and have alternatives managed to catch up? 

Let’s take a look at some migration paths to explore the different options to see how they compare to VMware and its ecosystem. Firstly the relevant question is what types of virtualization workloads are you looking to migrate. For single servers and virtual desktop workloads the path is pretty straightforward. Any alternative will cover this base case and tools like virt-v2v and other migration scripts are widely available and connect to most open source and closed source virtualization stacks. They copy the VM, boot the target system and then apply your configuration. If you only have a handful of VMs to migrate this is not too much effort. 

You will still need to figure out some things like backup tooling and while available options and features do differ from alternative to alternative all of them will have some viable options.

However if you are looking to migrate a full multi-server or private / public cloud workload from VMware to another provider things start to look more complicated. Unfortunately this will be the case for most larger companies. In these scenarios you will need tooling to manage clusters, storage solutions, monitoring & observability, network utilities and more. Here none of the alternatives is going to offer a one-click migration and feature sets and workflows differ a lot. Which alternatives may be viable also depends on your willingness to move workloads and data to the cloud or vice versa whether you have to follow a more traditional on-premise strategy. 

For those following a more cloud centric approach Red Hat Openshift has emerged as one alternative with both a big ecosystem and support for a wide variety of container and virtualization options. It does come with a hefty price tag and will require a specialized skill set from your admins and will be quite demanding compared to VMware. Their existing certifications and VMware training are obsolete and they have to familiarize themselves with a completely new and different operating system and workflows. Established processes need to be redesigned and re-learned. This transformation will be challenging for IT departments, especially alongside the day to day business. The main difference is that Openshift is built on top of KVM (an open source virtualization hypervisor stack) and Kubernetes (an open source container orchestration stack) which both are very Linux specific frameworks, whereas VMware admins typically are used to a more Windows based way of working. Openshift also combines the management of virtual machines, containers and serverless workloads into a single management platform and also allows combining container and virtualization technologies to run VMs inside of containers and more.  This offers exciting new possibilities for modernizing enterprise landscapes but it also introduces potentially overwhelming complexities. This parallel and interchangeable usage of containers and virtual machines is nothing short of a paradigm shift and will require your teams and culture to adjust. 

For on-premise focused enterprises, other alternatives may be more suitable. Open source options like XCP-ng by Zen Orchestra (open source community lead hypervisor) or Proxmox might have better support in these scenarios and offer more of VMware’s on-premise functionality while also being cheaper or free on the license side. Both options however have a rather intense learning curve with significant training barriers coming from VMware and unlike OpenShift they are not a one-stop shop. In order to fully cover enterprise use cases you will be plugging together multiple tools before getting anything off the ground. Even though open-source comes without the expensive license fee it does usually require more internal resources to set up and operate in the long run, this should be taken into account. IT departments might simply struggle to keep your application landscape operational with the added workload.  Also it is worthwhile to point out that support for Windows VMs is still very limited and spotty in these platforms. 

All of these platforms can be easy to get wrong without prior experience. You might end up with unmaintainable, unstable or inefficient infrastructure orchestration which can cripple your IT organization for years to come. 

Opportunity for Lift & Upgrade 

Now that we have established that a migration from hypervisor stack A to B already comes with considerable effort we want to throw in another alternative that might be considered to be more of a lift & upgrade rather than just a migration. Virtualization as a technology has been around for a long time and since then new technologies have arrived and reached maturity. For example containerization can be a more lightweight and flexible technology with many advantages in cloud native scenarios. It has been gaining traction over virtualization in recent years while also introducing new complexities for developers working with these tools. Migrating an enterprise business application stack from VMs to containers used to be a year(s) long transformation project that typically came with a complete application redesign. Applications, especially legacy monoliths are not easily ported to containers and the so-called containerization (or also sometimes called “dockerization”) made this move rather unattractive. 

The reason why this redesign is necessary is that containers, unlike VMs, do not have a full operating system with system level dependencies that applications can rely on. In a Docker environment applications need to know exactly what they will need during runtime and you need to define how every dependency is to be installed container by container for all services so that the container engine knows how to work with it. These so-called docker images can become quite heavy quickly, and especially when applications contain multiple images the orchestration can become challenging. Luckily recent innovations may offer a way out that eliminates this need for application redesigns.

Enter a new category of deployment: Codesphere workspaces. Container based, dockerless environments where applications can be installed just like if they were running in their own VM. This is achieved by combining a super lightweight read-only Linux operating system, network file storage and a patented deployment algorithm. This combines the flexibility and suitability for larger complex applications of containers with the ease of use of serverless applications. They can be deployed in milliseconds and offer unique advantages when it comes to scaling up or down quickly, or when starting an application on an ad-hoc basis when usage occurs (i.e. for preview deployments). The platform seamlessly integrates with the rest of your software application lifecycle stack (like git providers, local IDEs or managed services) and can be installed in various scenarios from full service PaaS to air gapped on-premise & bare metal installation scenarios. It is also much easier to work with and operate than Openshift. 

Codesphere’s solution covers the entire software lifecycle, similar to VMware’s solutions, and solves many problems that used to be associated when trying to run Kubernetes at enterprise scale i.e. via Openshift. Codesphere’s deployments offer all advantages of containers (i.e. they are scalable and lightweight) plus additional advantages from our patented cold-start technology that allows containers to be turned off when unused and reactivate within seconds when needed. This gets embedded in an end-to-end frontend that simplifies working with the system to a point where DevOps becomes obsolete. Developers can perform and maintain all their hardware requirements from an intuitive UI in a self service manner. 

Finding alternatives to VMware is a complex challenge, but it also offers the opportunity for a significant transformation of your IT infrastructure. Rather than simply migrating without gaining anything except to avoid paying too much money to a previous vendor of choice, organizations should take the opportunity to reach this goal AND to modernize and future-proof their architecture. Codesphere offers a robust solution that allows you to take advantage of container technologies without sacrificing the proven principles of virtualization. The platform combines the efficiency of containers with the familiarity of VMs and can be seamlessly integrated into existing CI/CD pipelines. With flexible installation options - from PaaS to on-premise and air-gapped scenarios - Codesphere offers the necessary adaptability for different business requirements. Now is the best time to act, since you have already decided to leave the cost spiral.