Containerization has become a major trend in software development as an alternative or companion to virtualization. It involves encapsulating or packaging up software code and all its dependencies so that it can run uniformly and consistently on any infrastructure.
Containerization allows developers to create and deploy applications faster and more securely. With traditional methods, code is developed in a specific computing environment which, when transferred to a new location, often results in bugs and errors. Containerization eliminates this problem by bundling the application code together with the related configuration files, libraries, and dependencies required for it to run. This single package of software or “container” is abstracted away from the host operating system, and hence, it stands alone and becomes portable—able to run across any platform or cloud, free of issues.
The concept of containerization and process isolation is decades old, but the emergence of the open source Docker Engine in 2013, an industry standard for containers with simple developer tools and a universal packaging approach, accelerated the adoption of this technology.
Containers are often referred to as “lightweight,” meaning they share the machine’s operating system kernel and do not require the overhead of associating an operating system within each application. Containers are inherently smaller in capacity than a VM and require less start-up time, allowing far more containers to run on the same compute capacity as a single VM. This drives higher server efficiencies and, in turn, reduces server and licensing costs.
Put simply, containerization allows applications to be “written once and run anywhere.” This portability is important in terms of the development process and vendor compatibility. It also offers other notable benefits, like fault isolation, ease of management and security, to name a few.
The most distinctive feature of containerization is that it happens at the OS level, with all containers sharing one kernel. That is not the case with virtualization via virtual machines (VMs):
- A VM runs on top of a hypervisor, which is specialized hardware, software or firmware for operating VMs on a host machine, like a server or laptop.
- Via the hypervisor, every VM is assigned not only the essential bins/libs, but also a virtualized hardware stack including CPUs, storage and network adapters.
- To run all of that, each VM relies on a full-fledged guest OS. The hypervisor itself may be run from the host’s machine OS or as a bare-metal application.
Like containerization, traditional virtualization allows for full isolation of applications so that they run independently of each other using actual resources from the underlying infrastructure. But the differences are more important:
- There is significant overhead involved, due to all VMs requiring their own guest OSes and virtualized kernels, plus the need for a heavy extra layer (the hypervisor) between them and the host.
- The hypervisor can also introduce additional performance issues, especially when it is running on a host OS, for example on Ubuntu.
- Because of the high overall resource overhead, a host machine that might be able to comfortably run 10 or more containers could struggle to support a single VM.
Still, running multiple VMs from relatively powerful hardware is still a common paradigm in application development and deployment. Digital workspaces commonly feature both virtualization and containerization, toward the common goal of making applications as readily available and scalable as possible to employees.
