# Why Containers Exist

## "It works on my machine"

Every engineer has heard this sentence, and it names a real, expensive problem: an application
that runs perfectly on one machine fails on another because of differences in installed
libraries, OS versions, configuration, or dozens of other environmental details that are easy to
overlook and hard to fully document.

## The problem, precisely

- **Dependency inconsistency** — an app needs Python 3.11 and a specific set of libraries; the
  production server has Python 3.9 and different library versions.
- **Non-repeatability** — setting up a working environment by hand, following a README, drifts
  over time and between people — "works on my machine" is often true because "my machine" has
  accumulated years of undocumented manual setup.
- **Deployment friction** — moving an application from a developer's laptop to a test server to
  production means repeating fragile manual setup multiple times, each an opportunity for drift.

## Containers: package the application AND everything it needs, together

A **container** packages an application with its exact dependencies, libraries, and
configuration into one deployable unit — the same container that ran on a developer's laptop
runs, byte-for-byte identically, on a test server or in production. "It works on my machine"
becomes "it works in this container," which is true everywhere that container runs.

## VM vs. container — genuinely different, not just "containers are lighter VMs"

A **virtual machine** virtualizes an entire computer, including its own full operating system
kernel — heavier, slower to start, but with very strong isolation. A **container** shares the
HOST machine's kernel and only isolates the application's process, filesystem view, and network
— dramatically lighter and faster to start (seconds vs. minutes), with somewhat different
isolation properties than a full VM (a well-understood, documented tradeoff, not a hidden flaw).
Neither is strictly "better" — they solve overlapping but distinct problems, and real production
systems often use both together (VMs providing strong host isolation, containers providing fast,
consistent application packaging on top).

## Instructor Notes

**Lesson goal:** Motivate containers through the real, felt problem ("it works on my machine")
before any Docker command — mirrors ROOT 03's "why version control exists" opener.

**Approximate timing:** 12 minutes read; 8 minutes live.

**Common misconception to watch for:** describing containers as simply "lightweight VMs" —
they share the host kernel, which is a genuine architectural difference, not just a size
difference.

**Discussion question:** "Has anyone experienced 'it works on my machine' personally, on either
side of that conversation?" (Real stories make this lesson's premise concrete before the
technical content begins.)