Machines Made of Software

01The Machine-Sharing Problem

Notes 01 made an economic argument: elasticity pays because the provider pools resources, and pooling works because your peak and a stranger's peak land at different hours. But that argument quietly assumed something technical — that a provider can slice one physical machine among many unrelated tenants, safely, in seconds. This week is about the machinery that does the slicing, because every service you will rent for the rest of the term is built out of it.

Start with the on-premises server from last week, running at eight percent utilization. The obvious fix is to run more things on it, and the moment you try, you discover why nobody wanted to. Application A needs one version of a shared library; application B needs another. B has a slow memory leak, and when it finally eats the machine, A dies with it. A security hole in either one exposes both, because they share a filesystem, a process table, and every open port. An ordinary operating system gives each process its own address space and stops there — everything else on the machine is a commons.

What you actually want is for each workload to believe it has a machine to itself. There are exactly two ways to manufacture that belief, and this whole session is the pair of them. You can fake the hardware — build a software copy of a computer, and let a whole operating system run inside it. That is virtualization. Or you can partition the operating system — keep one kernel, and make it show each group of processes a private view of the machine. That is the container model. Everything else is consequences.

02Hypervisors and Virtual Machines

A hypervisor is the program that fakes the hardware. It creates and runs virtual machines — software computers — and its whole job is arbitration: hand each guest a share of real CPU time, real memory pages, and real I/O, while making certain no guest can see or touch another's. Each virtual machine is complete: virtual firmware, virtual disks, a virtual network card, and inside all that a full operating system with its own kernel, which boots believing it owns a computer.

It is worth being concrete about what the guest is given. A vCPU is not a chip; it is a hardware thread of a real core, time-sliced by the hypervisor's scheduler. A virtual disk is typically a large file on the host (or a network volume) presented as if it were a block device. The virtual network card delivers packets to a software switch. The guest OS mostly cannot tell the difference — and where performance matters, it often chooses to tell the difference, loading paravirtual drivers that cooperate with the hypervisor instead of pretending it isn't there.

Hypervisors come in two shapes, and the names are unglamorous. A Type 1 hypervisor runs directly on the metal, with no host operating system beneath it — VMware ESXi, Microsoft Hyper-V, Xen, and KVM (which turns the Linux kernel itself into the hypervisor). A Type 2 hypervisor is an application running on a host OS — VirtualBox, VMware Workstation, Parallels, UTM. Type 2 is what you run on a laptop to try things; Type 1 is what runs every physical host in every public cloud, because it wastes less and exposes less. Step through the plate below and watch what gets duplicated in each arrangement — the duplication is where both the cost and the isolation come from.

Read the amber. Every virtual machine carries a complete operating system: gigabytes of disk, hundreds of megabytes to gigabytes of RAM, a boot sequence measured in seconds to minutes, and a patch schedule — multiplied by however many guests the host carries. That overhead buys you the strongest practical isolation short of separate physical machines: the boundary between guests is enforced by the hypervisor and the processor's virtualization hardware, not by the operating system the workloads run on. Hold that trade in your head; the rest of the session is about paying less for the wall.

03What an Instance Actually Is

When you rent compute from a public cloud, the thing you rent is called an instance on AWS, a VM instance on Google Cloud, and a virtual machine on Azure. Same object: a virtual machine on a Type 1 hypervisor, on a physical host you will never see. When you click Launch, the provider's control plane picks a physical host with room for the shape you asked for, in the availability zone you asked for; the hypervisor carves out the vCPUs and memory; your chosen machine image becomes the boot disk; the guest OS boots; and the per-second meter from Notes 01 starts running. The whole ceremony takes tens of seconds — this is the collapsed lead time that Section 01 of Notes 01 was about, made mechanical.

So an instance is not a machine; it is an agreement, with four parts. An instance type — the hardware shape: how many vCPUs, how much memory (next week's subject). An image — what the disk looks like at first boot. One or more volumes — the disks themselves. And a network identity plus a bundle of metadata: addresses, firewall rules, tags, and the role it acts as. The physical host behind the agreement is deliberately not part of it: stop and start an instance and it may come back on different metal; if the host fails, the provider replaces the hardware under you.

That ephemerality is a feature, and it forces the first real design rule of the course: treat instances as cattle, not pets. A pet has a name, gets nursed back to health, and is irreplaceable; cattle are numbered, interchangeable, and replaced without ceremony. Concretely: never store anything you care about only on an instance, because instances are designed to be disposable — durable state belongs in the storage services we cover in Week 4. If the death of one particular instance would ruin your week, your architecture is wrong, and Project 1 will be graded with that sentence in mind.

Notice where this sits in the vocabulary of Notes 01: an instance is IaaS, exactly. The provider operates the hypervisor and everything below it; from the guest operating system up — patching included — the amber layers are yours.

04Containers: Partitioning the Kernel

Now the second way to fake a machine. Instead of building software hardware and booting a second kernel on top of it, keep one kernel — the host's — and have it lie selectively to groups of processes. A container is nothing more exotic than an ordinary process (or a small tree of them) that the kernel shows a private view of the machine. There is no virtual firmware, no guest OS, and nothing to boot. Two kernel mechanisms, plus a packaging format, produce the whole illusion.

The consequences follow directly. Starting a container is starting a process — the kernel is already up — so it happens in milliseconds, not minutes. A container adds megabytes of overhead, not gigabytes, because there is no second operating system inside it. And an image is a portable, immutable artifact: the same bytes run on your laptop, a teammate's laptop, and a rented instance, which quietly retires the phrase “works on my machine.” We go deep on building images well in Week 7; today you only need the model.

The catch is the flip side of the same fact: every container on a host shares that host's kernel. Shared kernel means shared fate — a kernel panic takes everyone down — and shared attack surface: a kernel vulnerability reachable from inside a container threatens every other container on the machine. The wall between containers is real, but it is drawn by the operating system, not under it.

05VM or Container: The Trade-offs

You now have two ways to give a workload a machine of its own, and they price the wall differently. The comparison comes down to three axes — isolation, density, and speed — and the honest summary is that each side wins exactly what the other pays for.

5.1 The density argument, with numbers

Density is the argument you can put numbers on, and the numbers depend on one ratio: how big your workload is compared to the operating system it would otherwise drag along. Set up a host below and see how many copies of a workload fit as VMs versus as containers. Every square is a running copy; the pale blue squares on the VM side are memory spent on duplicate guest operating systems — capacity you paid for that runs no workload at all.

Play with the ratio and notice when the argument is strong and when it is not. A 256 MB microservice next to a 1.5 GB guest OS packs an order of magnitude denser as a container — this is why the microservices era and the container era are the same era. Drag the workload up to 8 GB — a fat JVM, say — and the multiple shrinks toward 1×: the OS overhead stops mattering when the workload dwarfs it. Density is not a slogan; it is this ratio.

And the isolation verdict, stated once so you can carry it for the term: no public cloud puts different customers' containers on a shared kernel. When a provider runs your containers for you, it wraps them in a virtual machine — increasingly a microVM (AWS's Firecracker is the famous one) that strips the virtual hardware down until a guest boots in about 125 milliseconds. Hardware-grade walls at near-container speed: both of this week's ideas, stacked. You will meet microVMs again next week, because they are what serverless functions run in.

06Back to the Service Models

Pull up Plate 3.1 from Notes 01 in your head — the responsibility stack. This week you met the machinery of its middle row. The virtualization / hypervisor layer is not an abstract label anymore: it is a Type 1 hypervisor on every physical host, and in IaaS it is precisely where the provider stops and you begin. The provider operates the hypervisor down to the concrete floor; you operate the guest OS up — and now you know exactly what object changes hands: a virtual machine.

Containers slot into that picture one level up, and where they run tells you which service model you are in. Run them yourself on rented instances and you are still in IaaS — the runtime is just software you installed. Hand the provider a container image and let them worry about the instances underneath — AWS Fargate/ECS, Google Cloud Run, Azure Container Apps — and the line has moved: they own the OS and runtime, you own the image. That tier (sometimes called containers as a service) sits between IaaS and PaaS, and it exists because the container image turned out to be the most convenient unit of handoff the industry has found. And in PaaS and FaaS, where you hand over bare code, your code still ends up inside a container or microVM — you just never see it. “Serverless,” which Notes 01 called a billing and operations claim, can now be stated precisely: there is a server, there is a hypervisor on it, and there is very likely a microVM with your name on it.

The arc from here: next week stays at the instance level — instance types, machine images, autoscaling, and serverless functions, which is this week's machinery with the provider driving. Week 7 goes deep on Docker and building images well; Week 8 is what happens when you have enough containers that they need a manager.

07Before Session 3 — September 14

Shorter list than last week, but two items produce things you will bring to class. The Project 1 specification is out — read it this week while it costs nothing; in Week 3 you start building against it. Tick items off as you go; the list remembers your progress on this device.

• Review Notes 01 and 02 together. Step through Plate 3.1 in Notes 01 one more time, and this time say out loud what physically sits at each layer. If “virtualization / hypervisor” is still an abstract phrase to you, reread Section 02 above before Session 3.
• Read the Project 1 specification, released this week in the course repository. Do not start building yet — read for shape: what has to exist, what has to be written down, and where the cost estimate fits. Bring at least one question about it to Session 3; “no questions” historically correlates with “hasn't read it.”
• Run the shared-kernel experiment. Run docker run -it ubuntu bash, and inside the container run uname -r and cat /etc/os-release. The OS release says Ubuntu no matter what machine you are on — but the kernel version is the host's. On Mac or Windows, that kernel belongs to Docker Desktop's hidden Linux VM. Take a screenshot of both outputs.
• Find your provider's instance catalog (EC2 instance types, Compute Engine machine types, or Azure VM sizes). Write down the smallest general-purpose type you can rent, its vCPU and memory, and its on-demand hourly price in your region. Next session opens by decoding these names, and yours will be one of them.
• Confirm your billing alert survived Week 1. Log in, check the budget alert exists and points at an email you read. From next week onward you will be leaving resources running between sessions, and this is the seatbelt.

08Key Terms

Hypervisor

Software that creates and runs virtual machines, arbitrating each guest's share of the real CPU, memory, and I/O while keeping guests isolated.

Type 1 / Type 2

A Type 1 hypervisor runs directly on hardware (ESXi, Hyper-V, Xen, KVM); a Type 2 runs as an application on a host OS (VirtualBox, Parallels). Clouds run Type 1.

Virtual machine (VM)

A software computer — virtual firmware, disks, and NIC — running a complete operating system with its own kernel.

Guest / host

The guest is the virtualized system; the host is the physical machine (and, for Type 2, the OS) it runs on.

vCPU

A virtual CPU presented to a guest: in practice a scheduled hardware thread of a physical core, not a whole chip.

Instance

The unit of rented cloud compute: a VM defined by an instance type, an image, volumes, and a network identity — deliberately not tied to particular hardware.

Machine image

The template a boot disk is created from: OS plus whatever was baked in. Much more on these in Notes 03.

Kernel

The core of the OS that owns hardware, memory, and processes. VMs each have their own; containers share the host's.

Namespaces

Kernel mechanism controlling what a process can see: its own process table, network stack, filesystem root, hostname, users.

Cgroups

Kernel mechanism controlling what a process can use: limits on CPU, memory, and I/O consumption.

Container

A process (or process tree) isolated by namespaces and limited by cgroups, sharing the host kernel. Starts like a process, not like a machine.

Container image / layers

An immutable stack of read-only filesystem layers plus a writable top layer at run time. Layers are shared, so you ship only what changed.

MicroVM

A minimal virtual machine (e.g., Firecracker) that boots in ~100 ms; how providers give containers and functions hardware-grade isolation.

Density

Workloads per physical host. Containers win on it in proportion to how small the workload is next to a guest OS.

No term matches that filter.