Virtualization fundamentally changed the way the data center operates, and it wasn’t all that long ago. VMware released the ESX Server 1.5, its first hypervisor and arguably launched mainstream adoption of VMs in the enterprise, in 2002. To this elder millennial, it feels like just yesterday(ish).
The technology revolutionized infrastructure utilization—you could run multiple operating systems on the same hardware, maximizing your hardware resources. Then, containers—VMs’ younger, sleeker Gen Z cousin—came on the scene in a big way with Docker’s release in 2013, arguably the product that spurred mainstream adoption of containers. Containers allow multiple, isolated applications to share the same operating system kernel.
While they work differently, the two technologies share enough similarities that it begs the question—will containers replace virtual machines?
Today, we’re weighing in on the debate.
VMs vs. Containers: A Recap
VMs are software-defined computers. They run atop hypervisor software that allows multiple operating systems to share the same underlying physical hardware and operate in isolation from each other. The hypervisor virtualizes the underlying hardware, and each VM runs its own operating system (OS).
Before VMs, a single server could only support a single OS. If you wanted to run business applications with different OS requirements on the same server, or you wanted to run those applications without them interfering with each other, well, you couldn’t. Each business application you wanted to run—say, email or your CRM—had to have its own (usually over-provisioned, underutilized) set of hardware. After VMs, a single server could host multiple operating systems and run multiple applications. They drastically reduced the amount companies had to spend on hardware and hardware management.
Containers are also software-defined computing instances, but they run atop a shared, host OS. They package software into portable, executable units with all of the necessary dependencies to run anywhere—on a laptop, on a server, in the cloud, etc. The table below outlines the differences between VMs and containers.
| VMs | Containers |
|---|---|
| Heavyweight. | Lightweight. |
| Limited performance. | Native performance. |
| Each VM runs in its own OS. | All containers share the host OS. |
| Hardware-level virtualization. | OS virtualization. |
| Startup time in minutes. | Startup time in milliseconds. |
| Allocates required memory. | Requires less memory space. |
| Fully isolated and hence more secure. | Process-level isolation, possibly less secure. |
Without having to lug around all that OS code, containers are lighter weight (megabytes vs. VMs’ gigabytes) and start up faster than VMs. You can run two to three times as many applications on a single server with containers than you can with VMs.
Based on that alone, one could make the case that containers are the future and VMs are old news.
So, Will Containers Replace VMs?
The case seemed too easy, and we weren’t satisfied with basing a prediction on that alone. It’s just not that simple. To present a structured debate, we’ll look at the arguments for and against. In one corner: the case for VMs. In the other corner: the case for containers.
The Case for VMs
Even though containers are smaller and faster, it still might be a bridge too far to predict they’ll kill VMs forever. Here’s why:
- Familiarity and Maturity: While the tech industry is often fast to adopt the next, new thing, VMs are well-established in many organizations. Most businesses have entrenched processes, procedures, and teams in place to manage VM deployments, including backups and monitoring. “The way we’ve always done it” isn’t always the best reason to keep doing something, but there’s the “if it ain’t broke, don’t fix it” argument to contend with as well. If a monolithic application works well in a VM environment, there has to be a good reason to go through the effort of refactoring it to work in a container environment and sometimes, the effort isn’t worth the reward.
- Need for Full OS Capabilities: Using a VM with all OS services working together as one machine is sometimes preferable to a more orchestrated “Docker compose” or Kubernetes cluster with unnecessary complexity, especially for some complex applications.
- Heterogenous Environments: Need to run more than one OS? That’s what VMs are made for. Containers share the same OS kernel, and thus require a homogenous environment. There’s an argument to be made that enterprise data centers are moving toward more homogenous environments to standardize for more operational efficiency, but it hasn’t happened yet, broadly speaking. Many organizations still need to run more than one OS and will for the foreseeable future.
- Security: Container security is a flag that VM loyalists like to fly. The argument is that containers are more vulnerable because they share host OS resources whereas VMs include the OS within their virtual walls. If a container is attacked, it could infect other containers that share the host OS. If a VM is attacked, there’s an additional barrier between the VM, the host server, and other VMs on it.
- It’s Not an Either/or, But a Both/and: You can run containers on VMs, thus allowing companies with established VM procedures to adopt containers. They can take advantage of containers’ speed and agility without abandoning VMs wholesale.
The Case for Containers
But, containers have a lot of advantages in their favor. What makes them contenders to replace VMs? Here are a few counterpoints:
- Speed and Portability: Containers start up in just seconds compared to minutes for VMs, but the speed advantages containers bring go beyond start-up time. Because they solve the problem of environment consistency, developers spend far less time configuring environments and dealing with bugs. Container engines like Docker also have libraries of container images developers can use to speed up their work. And projects like the Open Container Initiative have been established to standards for containers, streamlining deployment.
- Scalability: With container orchestrators like Kubernetes or Cycle.io, containers scale automatically based on traffic demands. They can replicate container images when needed and spin them down when not. Containers’ small size and startup speed means they can scale faster than VMs.
- Modularity: Containers revolutionized application development such that applications could be developed as individual microservices loosely coupled together. This development approach enabled DevOps and Ci/CD practices, substantially speeding up application delivery. As one of our senior software engineers put it, the ability to lego-stack an entire environment is really powerful. Containers’ small size and portability mean applications can be built in small component parts and those parts can be stacked together to build a complete application.
- Ease of Updates: Updating and redeploying one small part of your application built as a microservice in a container is much easier to manage than a full-featured OS with update and downtime needs.
- OS Abstraction: Because containers abstract the operating system, they solve some virtualization problems more easily than VMs. Virtualization can be tricky in MacOS and M1 operating systems, and containers get virtual environments running easily on those operating systems.
The Last Word
Will containers replace VMs in development environments? They already have. But will containers replace VMs wholesale? We’d argue no.
Developers aren’t going back to building monolithic applications any time soon. Containers enable them to leave environment inconsistencies in the past and focus more on building code, creating better software, and creating it faster. With more pressure than ever to do just that, containers are firmly cemented as the dominant virtualization technology for developers.
But, it’s important to differentiate between containers as an application delivery mechanism versus an infrastructure mechanism. VMs are slower, less portable, and heavy, but they are still the go-to technology when it comes to provisioning infrastructure in an enterprise and running legacy, monolithic applications. For example, while containers have become the technology of choice in app development, it’s less likely that IT teams in other industries, say education, will be as interested in spending the time to refactor their custom-made student information system into a microservices architecture. Nor could they feasibly substitute containers for the thousands of VMs they assign to students.
Final answer? Both containers and VMs have a place in the modern data center.
Do you disagree? Have at it in the comments.
System Maintenance Update: Log4j Vulnerability