Containers vs Virtual Machines (VMs): A Detailed Comparison

What Is Virtualization?

Both containers and virtual machines (VMs) use virtualization. Before we talk about the differences between the two technologies, let's talk about what they have in common. 

When you want a single computer to act like multiple computers, you need virtualization. It’s a technology that allows a single system to host one or more subsystems. A system is often a computer, but not always. 

A system can be a virtual machine, too. Yes, it is possible to run a virtual machine or container on another virtual machine. As a matter of fact, running Docker containers on virtual machines is a common pattern. Many popular web applications do exactly that in hosting environments like AWS, Google Cloud, or Microsoft Azure. 

A subsystem is a dedicated resource or a simulated environment. If you've ever used a game emulator like the popular MAME, you've run a simulated environment. It's a subsystem that provides just enough of the original machine for the game to run. Many game consoles use virtualization for backward compatibility with older games. 

Usually, when we hear about virtualization, we think of virtual machines. But containers are a form of virtualization, too. In both cases, software sits between the host and the subsystem. 

Let's talk about how VMs do this. 

What's a VM?

A virtual machine runs a guest operating system on a host computer. VMs behave like a distinct computer. They have their own dedicated resources, or at least they think they do. 

A common example of a virtual machine is VMWare running a guest operating system on a computer. This is how you run Windows on a Mac or Linux laptop. The operating system "sees" its own disk(s), memory, and video card. As far as Windows is concerned, it's like any other PC. 

Virtual machines use a software program called a hypervisor. A hypervisor manages how virtual machines use the host. It gives them a slice of the hosts' system resources. The VMs can behave as if they have their own dedicated resources, so they aren’t aware of any other VMs. Depending on the hypervisor, most operating systems can run in a virtual machine without special modifications. 

VMWare and its rival Parallels are examples of software that help you take full advantage of powerful desktop or laptop computers. Rather than owning a separate computer for each operating system, you can use VMWare or Parallels to run Windows or Linux on a Mac. Or Linux on Windows. Instead of having to go "dual boot" and only run one at a time, you can run them together. 

VMs Mean Cost Savings and Convenience

Having multiple different operating systems on one machine helps a small number of power users at home—but it's huge for businesses in the data center. They can use virtualization to run a large number of systems on a small number of powerful servers. For example, Virtual Desktop Infrastructure (VDI) has saved many businesses millions of dollars. It provides employees with virtual machines that run on a server in the cloud or the organization’s on-premises data center. Each server can run tens or even hundreds of virtual desktops. 

There's no hardware for employees to break or lose. Virtualization locks the systems into the company network and keeps them behind the company firewall. And adding or removing an employee means adding or removing a virtual machine. 

This economy of scale isn't limited to VDIs. The ability to divide a powerful server into many VMs provides businesses with significant cost savings. One common example is web hosting. Smaller businesses can rent a virtual web server instead of dedicated hardware or a less-powerful shared web server. 

VMs limit the impact of vulnerabilities in the guest operating systems. If an attack breaches the guest, the hypervisor still protects the hosts and other guests. 

What's a Container?

Containers run on the host server and its operating system. But there’s no hypervisor sitting between the container and the host. Instead, a runtime system supports the containers. Each container shares the host's system kernel and its shared libraries. Containers are protected from conflicts because the runtime shares components as read-only (or copy-on-write). If containers need to talk to each other, they use the network. 

How does this work? Well, containers are for running individual applications, not entire operating systems. Instead of installing an application on the host, you run a container that contains everything the application needs. So, the container doesn't need a slice of host resources as a VM does. 

A container isn't a VM. So, even though you have a Docker container that "runs NGINX on CentOS 8," it’s not a CentOS operating system running a web server. It's a web server run in a protected environment with a CentOS 8 runtime. 

Containers Mean Speed and Agility

Containers are lightweight compared to a virtual machine. While both can be saved to a file and transported to a new host, VMs are measured in gigabytes. They're usually a binary image of the guest operating boot disk. They often also contain secondary disk images and a snapshot of memory. 

Container files, called images in Docker, only hold what's needed to run the application. So, containers are very lightweight—especially when compared to VMs. They're easily transported to new systems and start up much more quickly than a complete operating system. 

Containers have less overhead when compared to servers or VMs. They share a common operating system, so you only need to maintain the host with patches and bug fixes. Even though your containers use a wide variety of different operating systems for their apps, they're self-contained and require less maintenance. 

Container vs VM? Which One?

Since only VMs can act like complete systems, they are the only choice in some situations. 

We already talked about VDIs. When you need a system with a screen so you can run applications like web browsers or email, you need a VM. Remember, containers run one and only one application. 

But we talked about VMs in the data center, too. They're a great way to take advantage of powerful hardware. You can run multiple systems on an expensive server. Similar to the virtual web server example, many applications lend themselves to virtual machines.

Probably the most common use of containers is in the cloud. Many systems put microservices in containers with just enough operating system libraries to support them. Then, they manage them with a system like Kubernetes. The orchestrator starts and stops them on-demand, saving a significant amount of money and resources. These containers are often run on virtual machines in cloud systems like AWS, GCP, or Azure. 

Containers for Your CI/CD Environment

Containers are powerful tools for your CI/CD pipeline. The most critical part of that pipeline is building and testing your applications in environments that look like where they're run. Containers do that, and at a fraction of the cost of dedicated systems or even VMs. 

For example, if you need to build your code against a variety of environments, use containers. Each container corresponds to a different OS, or even a different set of dependencies on the same OS. Then, have your automated build system run the build in a different container for each target environment. 

Similar to the microservices example above, the containers exit when builds are done. So you're no longer paying for those compute resources. But since they're containers, they can be fired up quickly when you need to run the next build. 

Of course, if you can build the code in different environments, you can test in them, too. Your builds can run their unit tests in each container, and you can run manual integration tests with them, too. 

Plutora and Your CI/CD Pipeline

Like containers, Plutora is a valuable tool for your CI/CD pipeline. It's an integrated platform for managing releases, orchestrating software delivery and deployment, and overseeing your test environments. 

You want to keep your pipeline moving, but you can't afford to lose track of your value stream. Plutora's configuration management tools allow you to track configurations and change history so you can monitor changes and reproduce them when you need to repeat a process. For example, Plutora can help you track which containers you use for specific builds or tests. 

Your pipeline has many moving parts. Plutora helps you get them working together with its orchestration support. It's easy to use Jenkin's build version in your release history, track build status throughout every phase of your CI/CD pipeline, and even start and stop builds from inside Plutora. You can also verify the condition of your test and build environments before starting a new build. 

Virtualization Is Here To Stay

VMs and containers have a lot to offer. Both types of virtualization are ways of avoiding system dependencies, so you spend your time focusing on your application. Don't forget, Plutora has a lot to offer, too. It’s a value stream management platform that tunes software development and delivery processes and makes your organization more efficient. Check it out today!