The Problem With VM to Container Lift and Shift
When designing or modernizing IT systems, it’s easy to fall into the trap of using a new concept or technology in a familiar way, instead of using it to its true benefit. For those pursuing containerization, lifting and shifting from VM to containers marks a prime example of that trap.
In this blog, we discuss why the VM to container lift and shift approach is problematic, why it’s such a common mistake, and how teams can avoid containerizing against the grain.
Where We’re At: The Progression From Virtualization to Containerization
Virtualization has a long and complex past in the world of computing, almost as old as computing itself. From IBM’s CP-40 platform developed in the late 60s to today’s modern hypervisors, the goal of virtualized computing has been to provide consistency and efficiency of computing resources. It aims to provide a consistent environment on a platform abstracted from physical hardware, while maximizing the use of that hardware as well.
In much the same fashion, containerization has served these end goals as well, so it is of no surprise they appear so similar to the untrained eye. This is why we see so many organizations approach the shift to containers in the exact same manner they did when moving to virtualized hardware 20 years ago.
From a logical perspective, the evolution of virtual machines to containers is an easy line to draw. However, from a technical perspective, this can be quite detrimental to an organization’s containerization strategy.
The Problem With Lift and Shift
With the goal of virtual machines and containers being so similar, using the same migration strategy between the two is an easy trap to fall into. Organizations already know how to migrate from P2V, and we as human beings like to do what we know. If all we have is a hammer, then the potential for everything to become a nail is quite high, even if what we are looking at is nothing like a nail.
A straight lift and shift of a virtualized machine into containers is probably the biggest reason a containerization strategy fails. Often times these projects languish for years or the organization sours on the project and abandons it all together. Too often these efforts never make it past development environments, or if they do the organization realizes very little benefit from it. Their VM footprint is still the same size or larger. Their AWS or GCE bill is just as high as it was at the beginning of the project, or higher. All the storied benefits and capabilities just don’t seem to be there, and the technology seems to be more hype than substance.
Fortunately, this trap can be avoided if we change the way we think about our application environments and how we build and deploy them.
Why Containers Should Not Be Used Like Virtual Machines
When infrastructure teams around the world started moving from physical to virtual hardware 20+ years ago, the general conversation centered around how many physical servers they had, versus how many virtual servers they would need to replicate a physical environment. Very little attention was paid to what those virtual servers were actually going to be doing. That was something for application teams to worry about, not the infrastructure team.
Today, as we’ve seen in the move to the cloud and infrastructure as code, more of the focus is shifting onto the application itself, rather than what physical or even virtual hardware is needed. With the commodification of hardware, the number of compute cycles is talked about more than number of CPUs or even vCPU. Containerization takes this conversation even further.
If the conversation instead focuses on the virtual machines, and we treat our containers the same as our virtual machines, we will undoubtedly have fat bloated container images, resulting in containers that are rigid and immotile, providing none of the benefits that containers should provide. You should be thinking in megabytes, not gigabytes when it comes to containers.
📕 Related Resource: Learn more about What is Infrastructure as Code?
The Ideal Path From VM to Container
In the ideal path from VMs to containers, the focus has to be on the application, not the virtual machine it runs on. What does the application do? What resources does it need to perform its purpose? How does it access those resources? How closely does the application conform to 12-Factor app principles? Answering these and many more, will take you a long way in determining if your application is suitable for containerization.
Not all applications will be suitable in their current form. Moving apps that are suitable first and then taking the time to refactor those that aren’t is a key aspect of a successful migration strategy. It is very tempting to take any given monolithic application and shove its VM environment into a container, but you will receive very little benefit from doing this. Ultimately, this will result in containers that are inflexible, slow, and stationary, much in the same way your current virtual machines are now. In other words, if you build your containers to replicate VMs you will end up with containers that behave just like VMs, not realizing any of the true benefits that containers have to offer.
Final Thoughts
The primary focus of any containerization strategy should be “how does my application fit into a container” rather than, “how do my virtual machines fit into a container”. It’s quite possible you will want to do away with your hypervisor all together. With scheduling and orchestration being performed at the cluster level, running containers on virtual machines is somewhat like wearing a hat, on a hat.
That’s not to say you can’t, or even shouldn’t run your containers on virtual machines, but a well-developed container environment would be very much at home running on bare metal, and getting to that point takes time and planning. Focusing that time and planning on the application rather than the VM, will lead any organization to a successful and fruitful containerization project.
Get Support for Your Open Source Container Packages
Whether you’re planning your move to containers, or need help optimizing and orchestrating your containers, OpenLogic can help. Talk to an expert today to learn more.
