Containers & Docker

Containers are a lightweight virtualization mechanism that packages application code, runtime, libraries, and configuration into a single artifact called a container image. Unlike virtual machines, containers share the host operating system kernel, eliminating the overhead of running a full guest OS. This shared-kernel model gives containers near-native performance, sub-second startup times, and a memory footprint measured in megabytes rather than gigabytes.

The technology rests on two Linux kernel primitives: namespaces and cgroups. Namespaces provide isolation -- each container gets its own view of the PID tree, network stack, mount points, and user IDs, so processes inside a container cannot see or interfere with processes in other containers or on the host. Cgroups (control groups) enforce resource limits -- CPU shares, memory caps, I/O bandwidth -- preventing a single container from monopolizing host resources. Together, these primitives create the illusion of an isolated machine without the cost of hardware virtualization.

Docker, released in 2013, made containers accessible to mainstream developers by providing a simple CLI, a declarative Dockerfile for building images, and a registry (Docker Hub) for distributing them. The container image format was later standardized as the Open Container Initiative (OCI) specification, ensuring portability across runtimes (Docker, containerd, CRI-O, Podman). A container image is a layered filesystem: each Dockerfile instruction creates a read-only layer, and layers are shared across images, dramatically reducing storage and pull times.

In modern architectures, containers are the deployment unit for microservices. Each service is built into its own image, versioned independently, and deployed without affecting other services. This enables polyglot stacks (Python ML models alongside Go APIs alongside Node.js frontends), independent scaling, and rolling deployments. However, containers introduce operational complexity: networking between containers, service discovery, secret management, log aggregation, and orchestration of thousands of ephemeral instances require tooling that did not exist in the VM era.

Before standardized shipping containers, cargo was loaded loose onto ships -- different shapes, sizes, and handling requirements made loading slow and error-prone. The invention of the standard 20-foot steel container in the 1950s revolutionized global trade: any cargo that fits in the container can be loaded onto any ship, train, or truck without repacking. Software containers work the same way. A Dockerfile defines the 'box' (base OS, dependencies, application code), and the resulting image runs identically on a developer's laptop, a CI server, a staging cluster, and production -- eliminating 'works on my machine' problems. The container runtime (Docker, containerd) is the 'crane' that loads, starts, and stops containers on any host.