If you are a techie, you’ve most probably come across the terms Containers and Virtual Machines (VMs). Both are prominent technologies in the industry and commonly used together on the cloud. Containers, in particular, has been getting a lot of technical press with heavy lifters like Google, Amazon, RedHat and IBM sculpting services around Container technology. However, there is a varying degree of familiarity in the industry about these two technologies, and quite often, Containers get framed in terms of VMs.
Containers are not VMs
Containers and VMs have similar goals. They encapsulate an application and its dependencies into a self-contained ecosystem that can run anywhere. They help get the most out of available computer hardware and software resources. Both run on a host and need physical hardware. They provide isolated environments to deploy and run applications and, in both cases, that environment can be ported between hosts via a binary artefact. The main commonalities end there.
While Containers and VMs share common characterises, there are fundamental differences in the architecture of the two technologies – Containers are not VMs!
What is VM?
A VM is an emulation of a real computer, and it consists of a “guest OS” that runs on top of a “host OS” providing hardware virtualization (for CPU, Memory and Disk) using a “hypervisor”. The “guest OS” host “Apps” that have their own “bins and libs”.
What is a Container?
In comparison to a VM which provides hardware virtualization, a Container provides operating-system-level virtualization using a “container engine” that runs on a “host OS”. The principle difference between Containers and VMs is that Containers share the host system’s kernel with other Containers and therefore do not need a “guest OS”. Each Container hosts “Apps” that have their own “bin and libs”.
Does all that sound like gobbledygook? Let’s unpack the jargon.
Unpacking the jargon
Imagine, you usually stay in a student flat but are on holiday and have rented a serviced apartment run by a hotel chain. Unlike when you are in a student flat, you get your very own kitchen in a service apartment where you can cook your bacon and eggs. Whether you are at home in your student flat or on holiday living in a serviced apartment, you will need gas, electricity and water for your cooking. Also, a student flat and a serviced apartment will usually have some house rules that administer how you, as a resident, consume the utilities (i.e. gas, electricity and water). When you are too tired to cook in your student flat, you might order a takeaway. When you are living in a serviced apartment, there is usually a hotel kitchen that serves up meals for residents who do not want to cook for themselves. Both the student flat and serviced apartments have multiple residents.
VM – Serviced Apartment analogy
Think of a VM as a serviced apartment block. The serviced apartment hosts multiple residents (VM = Apps), each resident bring their eggs and bacon (VM = bins and libs) and usually cook them in their kitchen (VM = guest OS). Access to gas, electricity and water (VM = CPU, memory and disk). Access to and how much of the resources a resident consumes is governed by rules (VM=Hypervisor). The serviced apartment also has a shared kitchen (VM = Host OS) that serves up treats to residents. All residents share the underlying utilities, i.e. gas, electricity and water (VM = CPU, memory and disk).
Container – Student Flat analogy
Think of Containers as rooms in a student flat. Each room in a student flat does not have its kitchen (Container = No Guest OS). Each student resident has his/her own (well usually they are polite enough to use their own) bacon and eggs (Containers = bins and libs). When a student wants to cook their bacon or eggs, they take it to the shared kitchen (Container = Host OS). Access to gas, electricity and water (Container = CPU, memory and disk) and how much of the resources a student resident consumes is governed by rules (Container =Container Engine). All student residents share the underlying utilities, i.e. gas, electricity and water (Container = CPU, memory and disk).
The technical detail
As we say in the section above, VMs run on top of a hypervisor. A hypervisor is nothing but a piece of software, firmware or hardware. The hypervisor, in turn, run on the underlying physical computer, usually referred to as the “host machine” which supplies the VM with the necessary resources such as CPU, memory and disk. The VM (also referred to as guest machine) runs applications and consists of all supporting binaries and libraries that the application needs. The VM also incorporates a dedicated virtualized hardware stack of drivers, network adapters, storage and CPU, all of which is provided and manages by its own virtual operating system, i.e. the Guest OS. The hypervisor provides the VM with a platform to manage and execute its guest OS and enable the underlying Host OS to share its resources between the VMs.
Containers enable the execution of several isolated systems on a single host OS. Containers do not need a Guest OS. They sit on top of a physical computer server and its host OS, which supplies the Container with the necessary resources such as CPU, memory and disk. Containers are exceptionally light, only a few megabytes in size and take seconds to start. In comparison, a VM is gigabytes in size and can take several minutes for fire up. By sharing an operating system (Host OS), Containers considerably reduce overheads in comparison to VMS.
There are significant differences in architecture between VMs and Containers, and the primary difference lies in what is being virtualized. VMs virtualize hardware so that multiple OS instances (Guest OS) can run on a single physical computer, on the other hand, Containers virtualize an OS so that multiple workloads can run on a single OS instance (Host OS).
