Transitioning from virtual machines to containers is not a piece of cake. It’s a similar journey as transferring workloads to the cloud. As containers are transient, they make a perfect fit for stateless apps. What’s more challenging is deciding on the proper strategy for shifting workloads. This article explains how to move VMs to containers effectively and the tools and technologies necessary. Let’s get started!
It wasn’t that long ago that enterprises began the great virtual migration to abandon over-provisioning practices and attain greater resiliency and agility for their server workloads. Today it is about transitioning from virtual machines to containers to take advantage of the new cloud paradigm. However, comparing VMs to containers is like apples to oranges, so the migration between them can be challenging, and it’s not a venture to accomplish overnight.Â
Benefits of Containers
We first need to answer why to move to containers in the first place. After all, there must be some stream of benefits to substantiate the effort involved.Â
First off, there is the obvious benefit of greater resource utilization. A VM infrastructure requires an OS for the host server and an additional OS for each hosted application. Because containers all share the underlying OS, a single OS can support more than one container. The elimination of extra operating systems means less memory, less drive space and faster processing so that applications run more efficiently.
Then there is portability. Each VM has its operating system, making it difficult to relocate or migrate its hosted applications. However, once an application has been containerized, it is easy to move it to other containers. That could mean a new container housed within the same cluster or a new public cloud platform. Because a container is a holding cell for the application’s executable, it provides greater agility and faster deployment time.Â
Containerized applications are more suited for DevOps environments today and agile development. The increased agility that containers provide makes it easy to set up separate production and testing environments, leading to better coding.
Quick Five-step Guide to Migrate from VM to Containers
When not to containerize applications
Of course, not every application can reside in a container. Like the cloud, container architecture is relatively new. Just as many legacy applications do not natively support the cloud, applications that rely on VM server structure may need to be modified to run in containers. There are several reasons why an application may not be a good candidate for container migration.
For starters, some legacy applications are platform-dependent. The mainframe application is not going to operate within a container. We may have a complex problem with outdated applications that are dependent on EOL Windows versions as well. Some applications are hardware-dependent, as some may need to integrate with a hardware component. Other applications may be client dependent and must integrate with another application, such as a graphics application. Finally, there is the issue of security. Containers are not yet quite as secure as servers that have been in existence for longer. Suppose an application requires extensive security measures due to the sensitive nature of the application or the involved data. In that case, hold off on container migration until security catches up a bit.Â Â
Make sure to have a dual workforce
While migrating applications between two very different technology platforms, make sure to have a team with the knowledge base and experience to manage both ecospheres. It can be difficult to find someone specializing in each technology, so enterprises new to containers may need to bring in outside consultants.Â Â
Break the migration into smaller steps
Before migrating anything in a production environment, outline a plan. The plan should involve breaking up the migration into smaller steps. There will be an involved learning curve, so start with the lesser involved applications first, saving the more complex scenarios until later when familiarity with the process increases, and the container stack has had a chance to mature. We can also decide to break up applications into smaller microservices in which each microservice resides within its container. Naturally, one should conduct adequate testing before putting a containerized application into production.
Decide on a migration strategy
Once an application order is created, it’s time to decide how to move each software instance. As is common in life, migration methods requiring the least amount of work often require greater efforts. There are three primary methods available.Â Â
The simplest method is lift-and-shift, which moves the entire application from its VM host to a single container. There are some key advantages of this approach besides the fact that it is the least costly. A big plus is that it doesn’t require application-level changes to accommodate its new environment. Workloads that require specialized hardware can be easily directed to specialized VMs within the same cloud environment using this approach. We can migrate identified services in step with the application. The major downside is that applications may not be able to take full advantage of the native cloud environments that containers offer. Applications hoisted to a single container often garner higher maintenance and operational costs than the other methods, thus negating the early cost benefits to this fast and straightforward approach.
The next approach is refactoring. Refactoring entails customizing an application to suit its new container environment to take advantage of native cloud platforms. This involves making coding and structural changes while retaining the same features and functionality throughout. One can choose a partial refactor or a complete refactor. Like lift-and-shift, a partial refactor is less costly upfront and can be implemented faster but will often have shortcomings in the long run.
The final option is to rearchitect the application from the ground up. This basically involves rewriting the code and breaking down the app into a more complex structure of microservices that work in cohesion. While this approach certainly involves more work and expense, the potential payoff is far greater in cost, agility, resiliency, and performance.Â Â
Once we have a plan and a course of action, it’s time to pick the tools. The container platform we choose will determine the tool selection. For instance, Kubernetes is the most recognized open-source container platform. Some of the more popular tools that can aid in migrating VMs to Kubernetes include KubeVirt, Virtlet and RanchverVM. KubeVirt is an open-source tool that works well for VM workloads that can’t easily be containerized. Virtlet is a Kubernetes Container Runtime Interface that allows running VM-based pods on Kubernetes clusters, while RancherVM lets manage VM containers using native Docker commands. Those who want to migrate to Google Kubernetes or Google Anthos Clusters can use Google Anthos Migrate to automatically migrate VMs to containers without rearchitecting apps.Â Â
Any migration is a process, a learning experience and often an elongated endeavor. Make sure to allow for the usual hurdles and challenges that we can expect along the way. With a little luck, we can have all of the container migration projects completed just in time for the next technology paradigm that will require yet another type of migration.