Containers vs. Virtual Machines

In the post about virtualization types, I described the server virtualization as one of the most important types of virtualization nowadays, and within this type the two complementary subtypes: full virtualization and operating system virtualization. The full virtualization is based on virtual machines and the OS virtualization is based on containers. What are the main differences between them and when to use one or the other?

In the full virtualization approach the capabilities of the underlying physical hardware are fully replicated by the hypervisor running above it. The hypervisor can run directly on bare metal (hardware virtualization) or can run on the host’s operating system (hosted full virtualization), as shown on the following picture.

Hosted full virtualization

Since the virtual machine is a complete replica of the physical machine, the operating systems and the applications do not need to be modified to run on these VMs, which is the main advantage of using full virtualization techniques: by requiring no changes, full virtualization enhances operating system and application portability. It is specially suitable to migrate legacy applications. This portability comes with a cost, it puts more work on the hypervisor, for instance, it is not always possible to efficiently virtualize the underlying hardware completely, which results in sub-optimal performance in some cases when compared with other virtualization technologies.

Since every VM installs and runs its own operating system, we can run multiple operating systems on the same hardware, for example, Windows or MacOS running on a Linux host operating system, but again, this flexibility has some drawbacks:

• VMs are big: every VM has to package its own:
  • boot loader
  • operating system
  • file system structure
  • applications and services
  • customizations
• VMs start slowly: since they have to start all the layers listed above, it takes some time to start a VM (90 s. for a Google’s VM), specially comparing with other virtualization alternatives.

The VM’s drawbacks fostered the rise of a more lightweight virtualization based on OS virtualization [1] to remove the need of having a whole operating system on every virtual machine, which led to the rapid adoption of containerization as the defacto standard for operating system virtualization.

Virtualization based on containers

By looking at the architectural picture above, we can see this approach removes the need of the operating system installed in every virtual machine reducing the size of the image and the time to start an instance. At the same time, this architecture avoid the need of an hypervisor since that role can be perform directly by the host operating system’s kernel. The kernel allows the existence of multiple isolated user space instances called containers. Similarly to VMs, every container has its supporting files and runtime (libraries, binaries, etc.). The last piece of the puzzle are the applications installed.

As you can imagine, since all containers shares the same operating system, there are some restrictions that do not apply to the VM approach, i.e. you can not run containers based on Linux and Windows on the same machine. On the other hand, since all containers share the kernel of the host operating system, it is usually possible to launch a much larger number of containers than virtual machines on the same hardware, which improves resource optimization.

Virtual machines are very good at isolating system resources and entire working environments. For example, if you owned a web hosting company you would likely use virtual machines to separate each customer.

Containers’s approach is to isolate individual applications, not entire systems. A perfect example of this would be breaking up a bunch of web application services into their own containers, as we do with the micro-services pattern. That’s really the main advantage of containers, besides a virtualization technology, they have become the new format to package applications in a very portable and efficient way. As a developer you can pack your whole application with all its dependencies, configurations, data, etc. and that package can be deployed anywhere.