Key idea
When you rent a server, you almost never get a whole physical machine. You get a virtual machine, one slice of it with its own operating system. Inside that, apps increasingly run as containers: lighter slices that share one operating system and start in seconds.
Machine, virtual machine, container
Virtual machines: many computers in one
A physical server in a data center is far bigger than most apps need. A program called a hypervisor divides it into virtual machines. Each gets its own share of CPU, memory and disk, and believes it's a whole computer.
Because each one runs a full operating system, VMs are strongly separated: a customer on one can't see into another on the same hardware. That's what lets a provider rent one machine to many strangers safely. The price is weight: every VM carries a whole operating system and boots like a real computer.
Containers: just your app and what it needs
A container packs your app with everything it needs to run, such as the language runtime, libraries and files, but not an operating system of its own. Every container on a machine shares that machine's kernel, the core of the operating system that talks to the hardware.
A container starts from an image: a read-only snapshot of your app and its dependencies. Build the image once and it runs the same on your laptop, a test server and production. That's the cure for "it works on my machine".
The limits that matter from the last lesson still apply. A container can be given a share of CPU and a memory limit, and one that goes over its memory limit is stopped.
Which one you get
These layers stack. A provider rents out VMs; a platform runs containers on top of them; you hand the platform your image. You pick the layer to work at, not every layer beneath it.
- Choose a VM when you need to control the operating system itself.
- Choose containers when you want to ship an app the same way everywhere, and start or replace copies in seconds.
The Containers path teaches how to build images of your own.
Check yourself