Container
A lightweight, isolated package bundling an app and its dependencies that runs consistently across environments. Docker popularized it. Containers share the host kernel, so they're far lighter than VMs but less isolated.
- Almost all modern deployments for portability and density.
- Microservices and reproducible builds.
- Strong isolation for untrusted multi-tenancy (use VMs/sandbox).
- Legacy apps needing a full OS.
Definition
A container is a runnable software unit using OS-level virtualization (namespaces for isolation, cgroups for limits) to share the host kernel while isolating processes, filesystem, and network. Images are layered and immutable.
Why it exists
Apps depend on specific libraries, runtimes, and configs that vary across environments ('works on my machine'). Containers bundle all of it, giving reproducible, portable deployments without a full VM per app.
How it works
Build an image (Dockerfile layers). Run it as a container with namespace isolation (pid, net, mnt) and cgroup limits (CPU, memory). Images are layered and cached. Registries store and distribute images.
Scaling limits
Shared kernel = weaker isolation than VMs (kernel exploits affect all). Not a security boundary for untrusted code. State must live outside the container (volumes) since containers are ephemeral.
Cost shape
Far cheaper than VMs (no guest OS). Blow-ups: image bloat (huge layers), too many tiny containers, and unbounded resource limits causing noisy-neighbor issues.
Alternatives
- VM — Strong isolation with a full kernel, but heavier.
- Serverless — No container management, but less control.
Failure modes
- Image bloat slowing pulls.
- Unbounded containers starving neighbors.
- Ephemeral state lost on restart.