Virtual Machines vs Containers

Virtual machines (VM) and containers are similar in concept, but very different in their implementation and use. Conceptually, both allow the running of multiple services on a single platform. Both are quicker and less expensive to deploy than physical servers. And, horizontal scaling is easier since there is no need to spin up and configure new physical infrastructure. That’s where the similarities end.

Virtual Machine Implementation Overview

Virtual machines are akin to software implementations of physical servers, thus virtualizing hardware servers. Many virtual machine instances can run on one physical machine. This is accomplished by a hypervisor.

A hypervisor application creates and maintains the virtual machines. Each VM is allocated CPU, memory, and storage. Each VM also has its own operating system, the Guest OS. VMs with different operating systems can run side by side. Applications that run on a virtual machine don’t see a difference between a VM and a physical server.

Here is a logical view of a virtual machine implementation:

Container Implementation Overview

Containers are run in native OS processes that share the same kernel. These containerized applications package all the required components together, which allows them to be deployed quickly in different environments. My recent Containers blog post goes into more detail on what these are.

Here is a logical view of containers on a server:

Notice that the container instances all share the underlying Host OS.

Here is a quick comparison of containers and virtual machines:

	Containers	Virtual Machines
Startup Time	Seconds	Minutes
OS	Shares OS	Has its own OS
Virtualization	OS-Level	Hardware
Memory	Less is required	More is required
Cost	Less	More

Let’s examine the above comparison traits.

Startup Time is much quicker with containers, mostly due to the virtual machine having its own operating system.

The OS is virtualized for containers. Virtual machines have their own allocated OS and virtualize their underlying hardware. Thus, VMs can run on a server that has different Guest OS types.

Virtualization for a container is a type of operating-system-level virtualization. This is because a program running inside a container does not have access to the underlying operating system. It only has access to what has been allocated to the container. VM is considered hardware virtualization since, looking in from the outside, a VM appears to be a physical server with it’s own CPU, memory and disk.

The memory footprint is smaller for containers. This means a physical server can run more containers than virtual machines.

Cost would normally be less when using containers. One reason is that a container does not require its own Guest OS, and thus, many more containers can run on a host server than on VMs. 

In the end, there are good reasons to use containers and VMs. Both can be supported on-premise or through a cloud-hosting option, such as Amazon, Google, Microsoft, IBM, and others. Both have their uses and related costs. And architects can help inform the appropriate choice.