0 / 11 lessons — 0%
Lesson 01 / 11 📦

Why Docker? Containers vs. VMs

Picture shipping something before shipping containers existed: every crate a different shape, every ship loaded by hand, nothing stacked the same way twice. Then someone standardized the box. Suddenly cranes, ships, and trucks all handle the exact same shape, and moving cargo around the planet gets boring — in a good way.

Docker does that for software. A Docker container is a standard-shaped box for your app: the code, the runtime, the libraries, all the settings, sealed up so it runs the same on your laptop, your teammate's laptop, and a server on the other side of the world.

Technically: a container is an isolated process on your machine's existing kernel — not a separate computer pretending to be one.

VIRTUAL MACHINES hardware hypervisor guest os app A guest os app B CONTAINERS hardware host os (shared kernel) container engine app A app B app C
Each VM packs a whole spare OS. Containers travel light and share one kernel.
Virtual machineContainer
Boots a full guest OS + kernelShares the host kernel
Isolated by a hypervisorIsolated by kernel namespaces & cgroups
Boots in ~minutes, GBs in sizeStarts in ~milliseconds, MBs in size
Strong isolation boundaryWeaker boundary, much lighter weight
Why it matters: "works on my machine" mostly disappears — the image that runs on your laptop is byte-for-byte what runs in staging and production.
Before lesson 2Say the sentence "a container shares the host's kernel, a VM doesn't" out loud once. That one line answers 80% of Docker interview questions.