Container

What is a container?

A container bundles an application with its runtime dependencies (libraries, config) so it runs consistently across laptops, CI servers, and cloud VMs. Containers share the host OS kernel but have isolated filesystems, process spaces, and network interfaces.

Containers vs virtual machines

Aspect	Container	Virtual Machine
Isolation	Process-level	Full hardware virtualization
Startup time	Seconds or less	Minutes
Size	Megabytes	Gigabytes
OS	Shares host kernel	Full guest OS

Why cloud teams adopt containers

• Portability — same image from dev to production
• Density — run many services on one host
• CI/CD — build once, deploy everywhere
• Microservices — each service in its own container

Common tooling

Docker is the most widely used tool for building and running containers; images follow the OCI (Open Container Initiative) standard, so they run on any compliant runtime. containerd and CRI-O run containers in production Kubernetes clusters. Images are stored in registries like Docker Hub, ECR, GCR, and GitHub Container Registry.

Not the same as serverless

Containers give you control over the runtime and long-running processes. Serverless functions hide the container layer and bill per invocation — though many serverless platforms run your code inside containers under the hood.

What people get wrong

• Gigantic images. Building on a full OS base ships gigabytes for a 20 MB app — slow deploys, bigger attack surface. Multi-stage builds and slim bases fix it.
• Running as root. Container isolation is process-level, not a security boundary like a VM; a root process in a container is one kernel bug from being root on the host.
• Baking secrets into images. Anything in a layer is extractable forever; inject configuration at runtime.
• The “latest” tag in production. Deploys become unreproducible; pin digests or version tags.