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

Edward Kisller
2020-07-09 10:45


User-added image

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 20 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, adoption of containers also began to skyrocket.

This guide compares the technologies so you can make an informed choice of application deployment strategy 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 is able to 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) and instead work by sharing the kernel of the host OS with other containers.

What’s more, they package up only the resources, such as installations, dependencies and code, your application actually needs.

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 provides the best utilization of the resources. This is the default setup in all cloud-based services. The following sections will describe the relationships between vms and containers.


Because 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 fulfil their performance potential.

Read more 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.

But containers generally have a much lower infrastructure footprint. Not only can you fit more of them on a bare-metal server, but you can also typically fit several containers on a VM. So, in either case, containers help you get more from your hardware.

Containers also 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


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 the containerized application, such as the configuration it uses for persistent storage. It will also be subject to the specific container platform you’re using. For example, you may not be able to run Docker containers on another type of container system.


Because containers and VMs use different methods of isolating your applications, they bring different security advantages.

The below diagram displays the two levels of isolation that strengthen the overall security of your containerized application. The first level is the separation of VMs. The second is the isolated containers within your VMs.

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

On the other hand, a hypervisor layer ensures VMs offer a much higher level of isolation between your application and host environment. In a single vm, containers still share the same kernel, which has its risk. This is mitigated by security layers within the container engine. Learn more about container engine security levels here >

This highlights the reason 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.

User-added image

A hybrid deployment method offers the best of both worlds

Containers vs VMs



Type of abstraction

Application environment only

Full hardware emulation

Primary use case


Full-blown server

Boot time




Limited by host OS

Limited by guest OS


Robust protection between services

Robust protection from host


Learn More about Containers

User-added image What Are Containers? And Why Should You Use Them? Read more >
User-added image The Role of Containers in Your Microservice Architecture Read more >
User-added image What Is a Container Registry? And Why Do I Need One? Read more >