The Dream — What If We Could Package Everything?

Let’s return to the cargo ship analogy.

Before 1956, shipping was a nightmare. Every piece of cargo was different. Cars, coffee beans, pianos, machinery. Dock workers had to figure out how to load each item individually. Ships were designed for specific cargo types. Trains were different. Trucks were different.

The interface between all these systems was… chaos.

Then Malcolm McLean invented the intermodal shipping container.

A standard steel box. 20 feet long, 8 feet wide. Standard corners for cranes to lock onto. Standard footprint for trucks, trains, and ships.

The genius wasn’t the box. It was the standardization.

Now the crane operator doesn’t care if the box contains iPhones or bananas. They lock onto the corners and lift.

The ship captain doesn’t care what’s inside. The truck driver doesn’t care. The warehouse doesn’t care.

Everyone speaks the same language: containers.

Software containers are the same revolution, but for code.

The “container” packages your application with everything it needs. The “crane” (Docker) knows how to pick up any container and run it. The “ship” (any server with Docker) can carry any container.

We stop shipping “just the code.” We start shipping the environment.

Here’s the key insight that makes containers lighter than VMs:

VMs virtualize hardware. Each VM needs its own operating system kernel.

Containers virtualize the operating system. All containers share the host’s kernel.

Virtual Machines:
┌─────────────────────────────────────────────┐
│  App A  │  App B  │  App C  │               │
├─────────┼─────────┼─────────┤               │
│  OS     │  OS     │  OS     │ ← 3 kernels!  │
├─────────┴─────────┴─────────┤               │
│         Hypervisor          │               │
├─────────────────────────────┤               │
│       Host OS + Kernel      │               │
└─────────────────────────────┘

Containers:
┌─────────────────────────────────────────────┐
│  App A  │  App B  │  App C  │               │
├─────────┼─────────┼─────────┤               │
│  Libs   │  Libs   │  Libs   │               │
├─────────┴─────────┴─────────┤               │
│      Container Runtime       │               │
├─────────────────────────────┤               │
│   Single Kernel (shared!)    │ ← 1 kernel!  │
└─────────────────────────────┘

Because containers share the kernel, they’re:

• Lighter: No OS to duplicate. A container might be 100MB instead of 2GB.
• Faster: No OS to boot. Containers start in seconds or milliseconds.
• Denser: Run 50 containers on hardware that could only run 10 VMs.

Containers promise a world where:

1. “It works on my machine” disappears — The container runs the same everywhere.

2. Dependency hell ends — Each container has its own dependencies, isolated from others.

3. Deployment becomes more repeatable — Ship the container, run the container. Done.

4. Resources are used efficiently — No wasted overhead on duplicate operating systems.

5. Scaling becomes simpler — Need more capacity? Run more containers.

But wait. If containers share the kernel, how are they isolated? What keeps Container A from seeing Container B’s files? What prevents one container from hogging all the CPU?

This is where Linux kernel features come in: namespaces and cgroups. But that’s for a later module. For now, just know that the Linux kernel has built-in features that make this isolation possible.

Docker didn’t invent these features. Docker made them usable. Docker took these complex kernel capabilities and wrapped them in a simple command-line interface that anyone could use.

That’s what we’ll learn in the coming modules.

---