Containers versus Virtual Machines: A general comparison

Whether you want to use Containers or Virtual Machines (VMs) depends on what you are trying to accomplish.  As to which is better  --- Container or VM, it's a complex question that needs a multifaceted answer.

Virtualization creates an environment where workloads run on a platform that is separated from its underlying, foundation hardware by a layer of abstraction.  The entity that renders this layer is the hypervisor, for example ESXi from VMware.  This abstraction allows servers to split resources into virtualized machines (VMs) that can run either the same operating system on multiple VMs or different operating systems across them, or more commonly a mix of the two.

Container technology offers an alternative to virtualization, in which one single operating system on a hardware machine will run many different applications from the cloud.  An ideal way of understanding containers versus VMs is that while VMs run various or multiple operating system instances on one compute node, container technique provides the platform to virtualize the operating system itself.

For those of you who might be thinking that container technology is a new phenomenon, the opposite is true.  Containers were introduced more than a decade ago but have been gaining traction only after technologies like Docker and Kubernetes appeared on the technology horizon.

With VMs, a software component layer called a hypervisor acts as the glue, the playground between the VM and the underlying hardware, thereby providing the requisite level of abstraction.  The hypervisor, VMware's ESXi for example, owns the responsibility of riding the several virtual machines created on it.  While VMware ESXi is the most well known hypervisor, there are others like Microsoft Hyper-V, Citrix Xen and KVM out there in the market.  Modern technology has evolved to a point where processors interact directly with hypervisors, providing them with paths for lining up instructions from the VMs completely invisible or transparent to the applications running inside these VMs.  Advanced network virtualization models like VMware NSX have made things even better from a functional perspective.

The scalability or scope of a VM server workload or workloads is achieved on lines similar to how it is done on bare metal servers.  With a Web server or a database application, the programs and processes responsible for delivering services are distributed amongst multiple machines or VMs.  Load balancers are configured on the front end for these VMs to direct and distribute traffic to ensure no specific server/VM is overloaded or underutilized.  Automated procedures within VM builds make such load balancing processes react to changes in traffic patterns every few moments.

The concept of virtualization was initially developed to segregate namespaces in a Linux operating system for security purposes.  The first Linux environments produced partitions (often referred to as "jails") within which applications of unproven security and authenticity could be run without risk or compromise to the kernel functionality.  The kernel was still in charge of the processing and running the show while a layer of abstraction was introduced between the kernel and the workloads.

Once improvements were made on these partitions to make them lightweight and more productive, the next great idea was to make them portable across containers and machines.

Workloads within a container such as Docker are virtualized.  However, in Docker there is no layer like a hypervisor.  On the contrary, the Linux kernel is associated with a daemon process continuously running that establishes and maintains the segregation or separation/isolation between containers while getting their workloads to communicate with the kernel.  Today's containers include minimalized operating systems such as the open source CoreOS as well as VMware's Photon OS which diligently perform the task of maintaining essential heartbeat functionality/services for the programs and applications they own and do not provide a full fledged processor landscape.

Scalability of workloads in containers works completely different when compared to VM workloads.  Current day containers include the most basic and essential services their operations require but one of them is a Web server, typically nginx, that doubles up as a load balancer.  Generally, sophisticated container systems like Google's Kubernetes and Mesosphere's Marathon are capable of orchestrating and discovering when the number of containers needs to expand, can create or replicate additional containers on the fly, and eliminate them if and when they are not needed.

The most important characteristic that differentiates a container from a VM is the container's transient, short lived nature.  Generally, multiple instances of a container coexist.  Containers that fail can be discarded and replaced without noticeable disruption or consequence on service availability.  In the most demanding environments, where everything is done to ensure business continuity and system uptime, staging and or new developmental instances of containers work in conjunction with proven, older versions.  Upon failure, the newer instances can be rolled back and withdrawn/replaced.  This shift in trend, and the drastic improvements in managing data centers, cloud and applications have evinced key interest in major players in the telecommunication field to explore and express interest in Docker and its related technologies, of late.

Docker

VM hypervisors like ESXi, Zen, Hyper-V and KVM are based on simulating virtual hardware which essentially would mean they are loaded (heavy) from the system requirement perspective.  Containers however are a different kettle of fish.  They virtualize the operating system, not the hardware beneath it.  That way they are more efficient than hypervisors in system resources terms.  Instead of virtualizing hardware, the containers reside on top of a single Linux instance.  Lightweight in nature, the containers are a bunch of small, neat tablets or tiny boxes running various applications.

If you could fine tune the container system, you can have as many as five times the number of server application instances as you can while implementing ESXi, Xen or KVM VMs on a hardware.

Docker is built on top of LXC.  The Docker container has its own file system, storage, processor, memory and other resources.  The central contrast between containers and VMs is that while the hypervisor abstracts the entire hardware device the containers just abstract the operating system sitting on top of the hardware device.

This brings to us something that the hypervisors can do that containers cannot.  Hypervisors can bring up instances of different operating systems and kernels while containers cannot do that.  Docker containers, for example, must use the same operating system and kernel.  On the other hand, if the bottomline you are trying to achieve is to make the most out of the server application instances running on the least amount of hardware, Docker containers, or containers in general fit the bill very well since you probably don't care about running multiple operating system VMs.  If you wish to have multiple copies of the same application, then containers will do just fine.

Look at the financial benefits.  Containers can save the Data Center or Cloud provider company millions of dollars per year in terms of hardware costs, footprint and electricity.  For this very reason we find many companies rushing to adopt Docker containers to run in their infrastructure.