Why Containers?
Your app works perfectly on your laptop. You hand it to a teammate — it crashes: wrong Python version. You deploy it to a server — it crashes differently: missing system library. Same code, three machines, three behaviors. Every developer has lived some version of this, and the phrase that goes with it — "works on my machine" — is the exact problem containers were invented to kill.
💡 The Bottom Line
A container packages your application together with everything it needs to run — runtime, libraries, system tools, configuration — into one isolated unit that behaves identically on any machine with Docker installed. The environment ships with the app, so there's no separate "set up the server" step to get wrong.
The real problem: environments drift
Code isn't the only input to a running program. It also depends on:
- A runtime — Node 18 vs Node 22, Python 3.9 vs 3.12.
- System libraries — the OpenSSL or ImageMagick version the OS happens to have.
- Configuration — environment variables, file paths, locale settings.
- Other processes — a database, a cache, a message queue at the right version.
Traditionally, all of that lived on the machine, set up by hand or by scripts that slowly drift out of date. Containers flip it: all of that lives in the container image, declared once, and the machine only needs one thing installed — Docker.
Containers vs virtual machines
Virtual machines solve a similar problem by emulating an entire computer, each with its own full operating system. That works, but a VM is gigabytes big and takes minutes to boot. A container doesn't bring its own OS kernel — it shares the host's kernel and isolates just the process, filesystem, and network view. The result:
- Megabytes, not gigabytes — an image carries only your app and its libraries.
- Milliseconds, not minutes — starting a container is closer to starting a process than booting a machine.
- Dozens per laptop — you can run your whole microservice stack locally.
🙋 There Are No Dumb Questions
Q: Is Docker the same thing as containers?
A: No — containers are the concept (Linux kernel features like namespaces and cgroups doing
the isolation), and Docker is the tool that made them usable: one command to build an image,
one command to run it, and a registry to share them. Alternatives like Podman exist and even
use the same image format, but Docker is where nearly everyone starts, so that's what this
track uses.
⚠️ Watch Out
Containers are isolation, not full security sandboxes — they all share the host's kernel. For running your own apps consistently that's exactly what you want; for running untrusted code from strangers, it's not enough by itself. Keep that distinction in mind and containers won't surprise you.
🔧 Try It Yourself
Install Docker Desktop (Mac/Windows) or Docker Engine (Linux) from docker.com,
then verify it works:
docker --version
docker run hello-worldThat second command downloads a tiny image and runs it as a container. If you see "Hello from Docker!", your machine can now run anything anyone anywhere packaged as a container — which is the whole point.
✅ Quick Check
What is the key difference between a container and a virtual machine?
Next up: the two words you'll use every day from now on — what an image is, what a container is, and the handful of commands that manage them.