Virtual Machine

When servers were bought and racked, the convention was one program per machine. That convention existed because it made causes obvious: if something misbehaved, there was only one candidate.

The price was waste. The server handling signups sits idle most of the day, and the server that runs nightly billing is merely powered on for twenty-two hours out of every twenty-four. Stand up twenty machines and measure average utilization and the number commonly lands in single digits, which is an expensive way to own hardware.

Consolidating several programs onto one machine, though, made them interfere. One program exhausting memory takes the neighbor down with it, and the library version one needs conflicts with the version another uses. Restarting to deploy one service stops the other service sharing the box, which turns a routine release into a cross-team negotiation.

The virtual machine split the difference. A layer that apportions resources sits on the physical machine, and several operating systems are booted separately on top of it, each with its own memory, its own disk, and its own idea of what machine it is running on. From inside, each looks like a whole computer of its own; from outside, one machine is carrying five. The waste goes down and the interference does not come back.

It divides one machine into several independent computers, so idle capacity gets used without anything interfering with anything else.

1. Idle resources get used. Put five virtual machines onto hardware that was running at 8 percent and the same power and the same rack space handle five times the work. The saving is not theoretical: it is the difference between buying twenty machines and buying four.
2. Tenants are held apart. Each has its own operating system, so a program that exhausts memory and dies takes nothing next door with it, and library versions can differ freely.
3. State copies wholesale. Capture the current state as an image and standing up ten identically configured machines takes minutes. Nobody repeats an install ten times, which removes the class of problem where each server is subtly different from the others.
4. It becomes the unit you can rent. When you create a server in the cloud, what actually appears is usually one of these. Choose a size on a screen, wait two minutes, and a usable machine exists; delete it and billing stops from that moment.
5. Old environments survive. When a program only runs on an older operating system, one virtual machine keeps that operating system alive. You no longer have to hold everything else back at the old version because of it, which is often the only reason a decade-old integration is still allowed to exist.

Once booting a whole operating system becomes the expensive part, lighter units get chosen. What separates them is what the program is packaged into.

1. A container bundles the program and what it needs to run, and shares the operating system underneath. That means starting in seconds and stacking dozens onto one machine. Because the operating system is shared, the isolation is weaker than a virtual machine's.
2. Orchestration decides, once containers number in the hundreds, how many go on which machine and where to restart one that died. It is less an alternative than the tool that necessarily follows containers into production.
3. Serverless means uploading code at the level of individual functions and having it run only when a request arrives. You never think about machines and you pay only for what ran. After a quiet period, the first request waits while the environment is prepared.
4. Using physical servers directly remains an option. With no layer apportioning resources there is nothing between the program and the hardware, and that shows up in long-running heavy computation, where a few percent compounds into hours.

None of this is a matter of picking one of four. The most common arrangement is renting a few virtual machines from a cloud provider and running containers on top of them, taking machine-level isolation from the lower layer and fast, light execution from the upper one.

"Let's give this its own virtual machine. It needs the older operating system."

A case where the environment has to be kept separate.

"Moving to containers takes startup from a minute down to five seconds."

Proposing a lighter unit where start time is the problem.

"We spread the containers across three virtual machines. One can die and the others absorb it."

Describing an arrangement that uses both units together.

At Pagedeck, Theo rents three virtual machines from a cloud provider and runs containers on them. The web servers and the document conversion workers share hardware, but they are separated across virtual machines so that the hours when conversion is consuming memory do not slow the web servers down with it.

One machine is kept aside. An export feature built years ago depends on a library from an older operating system, so that machine stays on the old version. Mia has rebuilding the feature on the roadmap, and until then this is how it holds. The machine is labeled so nobody upgrades it during routine patching.

The most common error is treating virtual machines as superseded now that containers exist. Nearly every new article and conference talk is about containers, which invites that reading. But the two sit at different layers. When you rent a server from a cloud provider, what you receive is usually a virtual machine, and the containers run on top of that machine. A team convinced it does not use virtual machines is working on top of them all day. Read the two as substitutes and you lose the ability to say which layer your isolation is coming from, which is exactly the question that matters when two workloads start affecting each other and somebody has to say where the boundary was supposed to be.

Believing performance matches physical hardware, or conversely that it is dramatically slower, is also common. Both misreadings come from the same place. Raw computation is nearly indistinguishable, and a few percent gets added when requests pass through disk and network. The difference people actually feel is elsewhere. Booting a whole operating system takes one to two minutes, and several gigabytes of memory are consumed before the machine has done anything at all. With autoscaling, which adds and removes capacity as load rises and falls, that startup time appears directly as lag between the spike and the response to it.