Containers vs. virtual machines: Why you don't always have to choose

As containers continue to gain ground, enterprise architects may find themselves asking (or being asked) which are better—containers or virtual machines (VMs)? In a nutshell, VMs isolate machines; containers isolate processes. But figuring out which technology works best for your system architecture is not so straightforward. Fortunately, it's not always an either/or situation—VMs and containers are increasingly part of the same discussion.

There are many similarities between Linux containers and VMs. Both are packaged computing environments that combine various components to perform specific tasks. Where they differ is in the scope of those tasks, as well as their scalability and portability.

Move away from legacy systems or leverage them?

Containers share the same operating system kernel and isolate application processes from the rest of the system. Containers often package single functions (in the form of microservices) that perform specific tasks. All of this makes containers lightweight and easy to move across multiple environments. VMs are more resource-rich. They typically contain their own operating system and can perform multiple functions at once. VMs are more robust than containers, but they are not as flexible, portable, or as scalable as containers.

Given that rationale, there are use cases that make sense for containers, and there are use cases that make sense for VMs.

VMs work well for monolithic workloads as they can run more operations than a single container. VMs also work well to run one operating system within another, investigate malware, and work well for provisioning infrastructure systems.

Containers work particularly well for—among other things—building cloud-native apps that deploy across public, private, and hybrid clouds—especially in DevOps and continuous integration/continuous development (CI/CD) environments.

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]

But if many companies today are trying to move away from monolithic applications and toward the agility, flexibility, and scalability that the cloud-native model provides, shouldn't we be all-in on containers?

Indeed, the COVID-19 pandemic has moved organizations to the cloud faster than most thought possible, but even in the "before times," companies recognized the importance of moving to a cloud-native model (if they hadn’t already started to move in that direction).

New research commissioned by Red Hat found that 30% of IT leaders expect to significantly increase container usage over the next 12 months, while 42% expect to increase container use slightly. Meanwhile, almost 90% of respondents said that the Kubernetes container orchestration platform is very important, extremely important, or important for cloud-native application strategies.

But the key term here is "moving to." Unless a company is starting from scratch, it has legacy systems—including VMs. Moving forward means leveraging the old while paving the way for the new.

Finding a healthy balance

"We see this with anything new," says Scott McCarty, technical product manager for Red Hat's container subsystem team and "fatherlinux" on the Red Hat Developer blog. "Even if a company has the resources and desire to start from scratch, it doesn't make sense to rewrite every application into containers."

"Some applications are working fine just as they are, and some just make more sense in virtual environments. It's therefore important to identify tools that support effective use of both models," McCarty adds. KubeVirt, for example, is designed for development teams that want to take advantage of Kubernetes but have VM-based workloads that don't fit a containerized model.

KubeVirt provides a unified development platform that developers can use to build, modify, and deploy applications in both containers and VMs. KubeVirt also enables developers to combine existing workloads with new container-based workloads on one platform and supports the development of microservices-based applications in containers that interact with virtualized applications.

Kata Containers, meanwhile, uses hardware virtualization to build a secure container runtime with lightweight VMs that perform like containers but offer more robust workload isolation.

More generally, enterprise architects can help companies protect their investment in VMs while strategizing for a cloud-native future by leveraging platforms such as Kubernetes to bring VMs into container workflows. This kind of purposeful alignment enables developers to run VMs and containers side-by-side and to exploit the strengths of each.

[ You might also be interested in reading An illustrated guide to GitOps. ]

Bottom line

VMs are not going away anytime soon, nor should they. Containers are also here to stay. There is no right or wrong way to manage your company's workloads, but one process can be more effective than the other depending upon your infrastructure. The two processes can even serve as perfect complements to each other or work just fine by themselves.

Enterprise architects must work across the organization to determine the best use cases for each and the tools they use to leverage the strengths of one model against the other.