Comparing Containers and Virtual Machines
Containers and Virtual machines have similar resource isolation and allocation benefits but function differently; containers virtualize the operating system instead of the hardware and are more portable and efficient.
The goal of both containers and VMs is to isolate an application together with its dependencies into a self-contained unit that can be run anywhere.
Containers and VMs remove the need for physical hardware that allows for more efficient use of computing resources resulting in less energy consumption and is cost-effective.
The main difference between containers and VMs is in their architectural approach, where containers share the host system’s kernel with other containers.
The code and its dependencies are packaged together in a container, which is an abstraction at the application layer. Containers may be multiple in number and occupy less space than VMs, as they share the OS kernel with other containers running on the same machine, each one of them running as isolated processes in the userspace. The container images handle more applications and require a few VMs and operating systems as they are typically tens of MBs in size.
The VMs are an abstraction of physical hardware that turns one single server into many servers and the hypervisor allows a single machine to run multiple VMs were included in each VM is a full copy of an operating system together with the application, the necessary binaries, and libraries that occupy up to tens of GBs and this is why VMs can be slow to boot.
The operating-system package manager was used to install the applications on a host in the old way to deploy applications, having the disadvantage of entangling the application’s executables, configuration, libraries, and lifecycles with the host OS and with each other.
In order to achieve predictable rollouts and rollbacks, one could build immutable virtual machine images as the VMs are heavyweight and non-portable.
Operating-system-level virtualization is the new way to deploy containers rather than hardware virtualization, the containers being isolated from each other and from the host: having their own file systems, they cannot see each other’s processes, and their usage of computer resources can be bounded, and as they are decoupled from the underlying infrastructure and the host file system they are easier to build than VMs, and across clouds and OS distributions they are portable.
A container image can pack an application as containers are small and fast.
The full benefits of containers get unlocked with one application to one image
relationship. Because each of the applications is not married to the production
infrastructure environment, nor do they need to be composed with the rest of the application stack, containers immutable container images can be created at build/ release time rather than deployment time.
From development to production, the generation of container images at build/release time enables a consistent environment to be carried. Inside the container, when the container’s process lifecycles are managed by the infrastructure and are not hidden by a process supervisor, they are more transparent than VMs and facilitate monitoring and management.
With a single application per container, it becomes tantamount to managing the deployment of the application while managing the containers.
Hope this was helpful.
