Getty Images
Containers vs. VMs: Is the VM all that bad?
Containers and VMs are needed to build and maintain software. Containers can deploy and scale apps, while VMs are more resource-intensive and can support separate environments.
While many think VMs possess superior flexibility, security and support for specific software, containers are often seen as the go-to for development and cloud deployments with rapid scaling requirements.
With these respective opinions in mind, let's dive into the specific benefits of containers vs. VMs that can help guide the decision regarding which virtualization approach to adopt.
Where VMs still stand out
A VM enables one software system to run many underlying OSes. With VMs, users can run programs on their computers that the OS wouldn't normally support. Imagine a computer is running macOS, but a user wants to run a program only available on Windows. Instead of having to install a new OS on that same computer, the user could run a VM with a virtualized Windows OS to run the program. This is the kind of advancement in cloud computing that enabled companies like AWS to support a variety of OSes via cloud servers.
Despite their age, it's arguable that VMs still hold a distinct advantage in a few areas over newer containers:
- Flexibility. VMs are sometimes seen as more flexible than containers. For instance, it's readily possible to run a Windows VM on Linux -- and vice versa. However, it may not be possible to do this via a container -- at least, not without the support of some underlying VM.
- Security. Other advantages often credited to VMs over containers are security and isolation. A VM is fully installed as its own OS, which is much more isolated from the host's system. Meanwhile, a container shares many parts of the host's system, making it potentially more vulnerable to security exploits.
- Supporting specific software. For organizations relying on programs that only run on a specific OS, VMs can open up the opportunity to run vital programs on almost any host system. On the other hand, containers require additional setup to run programs with a GUI, whereas VMs handle this natively.
The VM's lingering shortfalls
The place where containers often have VMs beat is in resource consumption. While a VM gives each OS its own dedicated system resources, a container shares system resources with the host. A single container's footprint is much smaller, requiring only the libraries the container uses on top of the host's OS.
For cloud computing, this differentiation is important. Because each VM installs an entire OS, it's not always efficient to run many VMs on a single host. It's efficient to run many containers on one host, as the host OS is shared across containers. For modern applications that frequently scale horizontally -- like many servers running the same application -- a single server could run a limited number of VMs. However, the same server could likely run 10 times as many containers using the same amount of resources.
Essentially, containers greatly simplify the way applications run. You don't need to provision a server with a certain OS and specific libraries. Developers can then create containers for deployment, which themselves contain all the necessities for the application to run. Once deployed as a running container, it's trivial to scale up and down the number of running containers. This is why orchestrators like Kubernetes often scale quickly: There is little overhead to run another container, other than the system resources the containers already share.
