Containers vs Virtual Machines
By the end of this lesson
Explain how a container differs from a virtual machine and why that difference matters in practice.
Both containers and virtual machines solve the same problem: running software in a predictable, isolated environment. They do it at different levels, and that single difference explains nearly everything about how they behave.
A virtual machine virtualises hardware. Each one runs a complete operating system of its own, including its own kernel. That is thorough isolation, and it means booting a whole operating system every time.
A container isolates processes while sharing the host's kernel. It carries your application and its dependencies, but not an operating system kernel. There is nothing to boot, so it starts in about the time it takes to start a process — because that is essentially what it is.
| Virtual machine | Container | |
|---|---|---|
| Includes an OS kernel | Yes, its own | No, shares the host kernel |
| Typical size | Gigabytes | Tens to hundreds of megabytes |
| Start time | Tens of seconds | Well under a second |
| Isolation strength | Stronger — separate kernel | Good, but shares the kernel |
| How many per host | A handful | Dozens or hundreds |
| Can run a different OS kernel | Yes | No |
Image and container are not the same thing
- Image
- A read-only package: your application, its dependencies, and instructions for starting it. Built once, stored, shared.
- Container
- A running instance of an image. Start three containers from one image and you have three isolated processes from the same package.
The class-and-object comparison is apt: an image is the definition, a container is an instance of it. Changes made inside a running container do not affect the image, which is why containers are treated as disposable and anything that must persist is kept outside them.
Summary
- A virtual machine virtualises hardware and runs its own kernel; a container isolates processes and shares the host kernel
- Containers are smaller and start in under a second, which enables workflows VMs cannot support
- An image is the read-only package; a container is a running instance of it
- Containers are disposable — persistent data belongs outside them
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
A build pipeline needs a fresh, empty database for every test run, several times an hour. Why is a container a better fit than a virtual machine here?
Show solution
Start time and cost. A container database is ready in a second and discarded just as quickly, so a clean database per run is entirely practical.
With virtual machines the boot time would dominate the build, which in practice leads teams to share one long-lived database — and shared state between test runs is exactly the thing that makes tests unreliable.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.