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.

Containers vs. Virtual Machines

The key architectural difference from virtual machines is that containers share the host operating system’s kernel rather than each running a complete guest operating system, which is what makes them dramatically lighter weight — a container typically starts in seconds and adds only megabytes of overhead, compared to a VM’s minutes-long boot time and gigabytes of overhead for a full guest OS. This shared-kernel design does mean containers provide weaker isolation than VMs (a kernel-level vulnerability could theoretically affect multiple containers on the same host), which is why highly sensitive multi-tenant workloads sometimes still choose VM-based isolation, or a hybrid approach like AWS Firecracker’s lightweight “microVMs” that aim to combine container-like speed with VM-like isolation guarantees.