What are containers?

The term “container” refers to image files in a format defined by the Open Container Initiative (OCI) which was formed under the auspices of the Linux Foundation in 2015.

Containers package a single application and all required library dependencies in a single, standardized, and operating system-specific way for either Linux or Windows. The name container comes from the idea that the application itself, and all that is needed for it to run, is packaged in one isolated “storage unit” (box, suitcase, or if you will: container), which enables it to run independently from its environment reliably and robustly. A significant benefit of containerized applications is that they will run the same regardless of where they are deployed across development, testing, and production environments. They also use far fewer resources (disk, memory) than e.g. virtual machines, start and stop more quickly, and can therefore be much more densely packaged on the host hardware.

Container images are technically archive files that in its turn contain a set of files that can be unpacked on demand. Each container image archive contains all files required to start an application including the application itself, any required system libraries, tools, configuration, and meta-data.

Container images are then executed on a container runtime which is a low-level component that knows how to unpack the container image and start the application inside it. Each container image runs in isolation from others running on the same host.

When applications are packaged as container images they are usually published to container registries e.g. Amazon ECR, Azure ACR, or DockerHub. Container registries allow users to find and download versioned container images for execution on a local container runtime.

A history of operating systems, virtual machines, and containers

Application teams have a history of struggling with how to package software applications in a way that allows them to run the same application across development environments (e.g. laptops), testing environments (e.g. lab servers), and production environments (e.g. in the cloud).

Various operating systems (e.g. Windows and Linux) have different and incompatible packaging formats, and there are even incompatibilities between packages across Linux distributions. This means that application teams have been forced to re-package and test the same application in a variety of ways to support all the necessary runtime environments. All package formats have also had different and incompatible ways to update already deployed applications and clean up after applications are removed from production.

The introduction of Virtual Machines (VMs) alleviated some aspects of that challenge by packaging an entire operating system and all applications in a single image file that could be spun up or down, copied, and migrated across machines on demand. The downside of VMs is that the image files tend to be large (several Gigabytes) which means that they can be slow to provision and consumes a lot of expensive overhead resources.

Containers made provisioning applications even faster and significantly reduced the amount of overhead resources.

On top of the improved resource and starting and stopping-angle, the container technology stack also describes how to version, find, remotely fetch, and unpack container images in a standardized way. This solves a larger part of the operational challenge of managing the lifecycle of operations than traditional packages and VMs. It also means that developers can run tests under the exact circumstances as in the system-test, and production environments.

The containerization of applications marks a new era of developer-first processes and tooling. The universality of the container format removes much of the infrastructure details that used to leak through to developers. And the standardization of lifecycle operations and monitoring removed the need for manual steps, allowing for full automation of all aspects of application management across development, testing and production.

If you are curious about what a really (and verifiably so) cool solution for edge container application management looks like I would suggest you take our system for a spin with a free trial.