Docker Course
Virtual Machines vs Containers
VMs and containers both solve the environment problem — but they solve it in completely different ways. One of them carries a house on its back. The other just packs a suitcase.
This is one of the most important conceptual comparisons in all of DevOps. Once you understand how containers and VMs differ at an architectural level, Docker's advantages stop feeling like marketing and start feeling obvious.
Inside a Virtual Machine
A virtual machine is a software simulation of an entire physical computer. It has its own virtual CPU, virtual RAM, virtual disk, and — critically — its own complete operating system. When you run a VM, you are running a full OS inside your OS. A Linux kernel inside a Windows machine. An Ubuntu environment inside a macOS host.
The piece of software that makes this possible is called a hypervisor. The hypervisor sits between your physical hardware and the VMs, managing and dividing up resources. Common hypervisors are VMware, VirtualBox, and Hyper-V.
Virtual Machine Architecture
(Ubuntu)
(CentOS)
(Debian)
Each VM carries its own full OS. Three apps means three complete operating systems running simultaneously.
Every Guest OS in that diagram is consuming RAM, CPU cycles, and disk space — before a single line of your application code runs. A minimal Ubuntu install alone is 500 MB to 1 GB. If your actual app only needs 200 MB, you're paying a 5x overhead just for the privilege of isolation.
Inside a Container
A container takes a completely different approach. Instead of virtualizing the entire hardware stack and running a separate OS, containers share the host machine's OS kernel. They use two Linux features — namespaces and cgroups — to create isolated environments without the cost of a full OS.
Namespaces give each container its own isolated view of the system — its own process list, its own network interfaces, its own filesystem. From inside the container, it looks like you have the machine to yourself. But you're sharing the kernel with every other container on the host.
Cgroups (control groups) limit how much CPU, memory, and I/O each container can use. This prevents one container from consuming all the resources and starving the others.
Container Architecture
Containers share the host OS kernel. Each only carries its own app and the specific libraries it needs — nothing more.
The Hotel Room Analogy
A VM is like checking into a hotel where each guest gets their own fully equipped house — complete kitchen, plumbing, heating system, the works. Expensive and wasteful if you just need somewhere to sleep. A container is like a hotel room — you have your own private space with your own things, but you share the building's infrastructure. Private enough for your needs. Dramatically more efficient.
VM vs Container — Head to Head
Virtual Machines
- Full OS per VM — 500 MB to 2 GB overhead
- Boot time: 1–3 minutes
- Strong isolation — separate kernel per VM
- Heavy resource usage even when idle
- Slow to scale — spinning up a new VM takes minutes
- Good for running different OS types on one host
Containers
- Shared OS kernel — just MBs of overhead
- Start time: milliseconds to seconds
- Process-level isolation via namespaces
- Near-zero resource usage when idle
- Fast to scale — new container starts instantly
- All containers share the host OS type
When to Use Which
Containers are not a complete replacement for VMs — they serve different purposes, and in production, you'll often use both together.
Use a VM when you need to run a completely different OS on the same machine — for example, running a Windows app on a Linux server, or testing your software on multiple OS versions. VMs also provide stronger security isolation, which matters in multi-tenant environments where you're running untrusted workloads.
Use a container when you're packaging and deploying your application. You want the lightweight startup, the portability, and the reproducibility. In a typical cloud deployment, you'll run your Docker containers inside VMs — the VM gives you the isolated hardware environment from the cloud provider, and the containers give you the fast, portable application packaging on top of that.
Teacher's Note
In the real world, AWS EC2 instances are VMs. You deploy your Docker containers onto those VMs. It's not either/or — it's containers running inside VMs, getting the best of both worlds.
Seeing It — How Fast Containers Start
The scenario: You're a platform engineer at a media company. Traffic spikes every evening when your content goes live. With VMs, spinning up new capacity takes 2–3 minutes — you've already missed the spike. With containers, here's what scaling looks like.
docker run -d --name frontend-app-1 frontend-app # start first container — instant
docker run -d --name frontend-app-2 frontend-app # start second — same image, milliseconds
docker run -d --name frontend-app-3 frontend-app # third — you're already scaled
# All three share the host OS kernel.
# No booting. No OS install. No waiting.e7c3a1f98b204d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d b2d4f6a8c0e2f4a6b8d0e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a2 9f1e3c5a7b9d1f3e5c7a9b1d3f5e7c9a1b3d5f7e9c1a3b5d7f9e1c3a5b7d9f1
What just happened?
Three containers started in under a second — each running a fully isolated copy of the frontend app. Each got its own container ID confirming it's live. None of them booted an OS. None of them installed anything. They all started from the same frontend-app image that was already on the machine, using the shared kernel underneath. This is why containers scale so effortlessly — you're not provisioning infrastructure, you're just creating new isolated processes.
Common Misconception
Containers are NOT fully secure isolated environments the way VMs are. Because they share the kernel, a kernel-level exploit in one container could theoretically affect others. For most workloads this is fine — but for running untrusted third-party code, VMs are still the right choice.
Practice Questions
1. What is the name of the software layer that sits between the physical hardware and virtual machines, managing resources for each VM?
2. Unlike VMs, containers do not each run a separate OS. Instead, all containers on a host share the same what?
3. What Linux feature gives each container its own isolated view of the system — its own process list, network, and filesystem?
Quiz
1. What is the fundamental architectural difference between a container and a virtual machine?
2. Which scenario is still better suited to a virtual machine than a container?
3. How long does it typically take to start a new Docker container from an existing image?
Up Next · Lesson 4
Docker Architecture
You know what containers are — now let's go inside Docker itself and understand how the CLI, the Daemon, and the Registry work together every time you type a command.