Containers vs. VMs: What’s the Best Choice for Your Workloads?

Containers and virtual machines (VMs) are nothing new. The concepts of resource partitioning and multi-tasking date back as far as the 1960s—from which VMs and containers evolved over the following twenty years. But the two technologies have only relatively recently started to take off. VMs were the first to go mainstream in the early 2000s. Then, following the launch of Docker in 2013, the adoption of containers also began to skyrocket.

This guide compares the technologies so you can make an informed choice regarding application deployment strategies for your workloads. But first, let’s briefly refresh our understanding of the two resource isolation approaches.

What Are VMs?

A VM is a simulated operating environment, which serves as a virtual computer within a host computer and behaves just like physical hardware in its own right. The host computer uses a hypervisor to emulate VMs, which are autonomous systems isolated from each other and the underlying host.

A hypervisor can run multiple VMs on a single physical machine. This helps to make more efficient use of infrastructure. In addition, hypervisors support a range of guest operating systems, so you can run different versions of Windows Server and distributions of Linux on the same hardware.

User-added image

What Are Containers?

Containers also provide isolated operating environments for your workloads, but use a different method of abstracting resources. They use neither a hypervisor nor a full-blown guest operating system (OS). Instead, they work by sharing the kernel of the host OS with other containers.

What’s more, they package up only those resources (e.g., installations, dependencies and code) that your applications actually need. As a result, containers are far more compact than their VM counterparts.

User-added image

How VMs and Containers Work Together

A typical setup would be multiple VMs running on a bare-metal server, where each VM runs multiple containers. This eventually allows for the best utilization of resources. This is the default setup in all cloud-based services. The following sections will describe the relationships between VMs and containers.

Performance

As containers avoid the resource overhead of hardware emulation, and are more streamlined application environments, they tend to offer better overall performance than VMs. They can also stop and start more quickly, making them more responsive than VMs to fluctuating scaling requirements. However, as most containerized workloads are currently hosted on VM-based infrastructure, relatively few deployments fulfill their performance potential.

See more information about container use cases.

Cost Efficiency

VMs help to reduce the number of physical machines you need to host your workloads and keep costs down. However, containers generally have a much lower infrastructure footprint. Not only can you fit more of them on a bare-metal server, you can typically fit several containers on a VM. So, either way you look at it, containers help you to get more from your hardware.

Additionally, containers lend themselves particularly well to cloud-native applications based on clusters of loosely coupled services. Although you can also use VMs to host your microservices, containers give you finer-grained control over resource allocation. So, with good cluster management, you can make more efficient use of your cloud resources and reduce your monthly pay-as-you-go bills.

User-added image

Portability

Applications packaged to containers tend to be more portable, as they’re far less cumbersome than the full server environments of VM deployments. You can run them on different Linux machines with different configurations, provided the kernel of each host OS is compatible with the container environment.

However, a Linux container cannot run on a Windows host without an additional virtualization layer. Likewise, a Windows-based container cannot run on a Linux host. By contrast, with a VM, you can run a Linux-based application on Windows and vice versa. Nevertheless, your application will still be tied to the same guest operating system.

New types of containers, such as Windows Hyper-V Containers, carry their own kernel and are analogous to lightweight versions of VMs. These are designed to increase the level of isolation between container environments and their host. However, the technology may ultimately lead to full container portability between Linux and Windows systems.

Finally, portability will also depend on the nature of a containerized application, such as the configuration it uses for persistent storage. It will also be subject to the specific container platform being used. For example, it may not be possible to run Docker containers on another type of container system.

Security

Containers and VMs use different methods to isolate your applications. Accordingly, they offer different security advantages. The illustration below displays the two levels of isolation that can strengthen the overall security of a containerized application. The first level is the separation of VMs, the second is the isolated containers within VMs.

Containerized applications are typically compartmentalized, where container boundaries make it harder for a security breach to spread throughout your infrastructure. As they are more streamlined environments, which provide only the resources an application needs, containers also have a smaller attack surface.

On the other hand, a hypervisor layer ensures VMs can offer a much higher level of isolation between an application and the host environment. In a single VM, containers still share the same kernel, which presents an element of risk. However, this is mitigated by security layers within the container engine. This highlights the reason why so many containerized workloads run on VMs rather than directly on host infrastructure, as this is a deployment method that provides both forms of isolation and enhanced security benefits.

See more information about container engine security levels.

User-added image
A hybrid deployment method offers the best of both worlds

Containers vs VMs

Containers

VMs

Type of abstraction

Application environment only

Full hardware emulation

Primary use case

Microservices

Full-blown server

Boot time

Fast

Moderate

Portability

Limited by host OS

Limited by guest OS

Security

Robust protection between services

Robust protection from host

Learn More about Containers

What Are Containers?

The Role of Containers in Your Microservice Architecture

What Are Container Registries (and Why You Should Use Them)?