iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Why Containers

By · Reviewed & last updated · Part of Docker Tutorial

Why Docker exists: reproducible runtimes, isolated processes, and the artifact contract between dev and prod. The shape of the problem it solves.

Docker — why

EXAMPLE
# ===== The problem before containers =====
# - 'Works on my machine' — different OS / lib versions across dev / staging / prod
# - VM provisioning is heavy; one VM per service wastes resources
# - Dependency drift between environments
# - Onboarding a new dev means writing setup docs that go stale

# ===== What Docker provides =====
# Image:     immutable layered filesystem + metadata. Identical bits everywhere.
# Container: a process running from that image, with OS-level isolation.
# Registry:  shareable, versioned image storage.

# Build once, run anywhere your container runtime exists.

# ===== Reproducibility =====
# A Dockerfile is a recipe. Same Dockerfile + same base image = same result.
# Pin digests for true determinism:
FROM node:20-alpine@sha256:9c8b5f...

# ===== Isolation (lightweight) =====
# Containers share the host kernel (unlike VMs).
# Namespaces isolate pid / network / mount / uts / user.
# cgroups limit CPU + memory.
# Result: VM-like isolation at ~milliseconds startup.

# ===== Density =====
# Run dozens of containers on a server where a few VMs would have fit.
# Schedulers (Kubernetes, ECS) pack workloads efficiently.

# ===== Dev parity =====
# docker compose brings the whole stack up locally:
#   - app
#   - postgres
#   - redis
#   - any worker / queue
# Tests run against real backing services; not mocks.

# ===== Where Docker fits =====
# - Microservices that ship many times a day
# - CI: clean ephemeral builds
# - Local dev with multiple services
# - Edge / serverless platforms that accept OCI images

# ===== Where Docker is overkill =====
# - Single binary with no runtime deps (use it directly)
# - Tiny scripts where 'cargo run' is fine

# ===== Common misconceptions =====
# - 'Containers are VMs' — no, they share the kernel
# - 'Containers are secure by default' — better isolation than processes, weaker than VMs
# - 'Docker is Linux-only' — runs on Mac / Windows via lightweight Linux VM
# - 'Docker Inc owns the format' — OCI standardised the spec; many runtimes exist

# ===== Trade-offs you accept =====
# - Image bloat if you are not careful (multi-stage builds help)
# - Networking is non-trivial (especially across hosts)
# - Layer caching surprises in CI (order Dockerfile lines carefully)
# - Persistent state needs volumes; ephemeral by default

# ===== Patterns to internalise =====
# - Image as code; Dockerfile committed; reproducible builds
# - Multi-stage: build tools out, runtime image small
# - Non-root user in production images
# - Pin base image digests in prod

Why it matters

Docker exists to make the same software run the same way in dev, CI, and prod. The image is the artifact, the container is the running process, and the registry is the shared store. The wins are reproducibility, density, and dev/prod parity — well worth the trade-off for any non-trivial app.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
# 'It works on my machine' — solved.
# Same image runs identically in dev / CI / prod.
Try it Yourself »

Discussion

Loading…