Servers That Appear From Code

In Chapter 7 you met infrastructure as code — describing the servers you want in a file instead of clicking through a website to create them. On hardware you own, that idea has a ceiling: the file can set up and configure machines you already have, but it can't make new computers appear out of thin air. You still had to buy the boxes first.

The cloud lifts that ceiling. Because the provider has computers waiting, a single file can ask for servers, networks, and databases, and minutes later they actually exist — and a single command can make them vanish when you're done. Infrastructure stops being something you buy and keep, and becomes something you summon and dismiss.

A file describes itservers, networks, databases

→

The cloud creates itreal, in minutes

→

You use itpay only while it runs

→

You destroy itthe file remains

On Demand

The first new power is speed of arrival. In the cloud, asking for a server and getting one are minutes apart, not weeks. There's no hardware to order, no machine to physically rack and wire. You request a computer of a chosen size, and the provider hands you one that's ready to use.

That changes what's worth doing. When a server takes weeks to get, you hoard the few you have. When it takes minutes, spinning up a fresh one for a single experiment becomes a normal, cheap thing to do.

From Code

Now bring back infrastructure as code. The point of Topic 33 was that DevOps and the cloud fit because the cloud's servers can be created by code. Here is that idea in full: a file lists the infrastructure you want, a tool reads it, and the cloud builds exactly that. Maya and Sam can keep that file in their Pageturn repo, review changes to it, and rebuild their whole setup from it.

Because the file is the source of truth, the same file can build matching copies — a development environment, a staging environment, and production that all look alike. The differences between environments stop being a mystery of who-clicked-what and become lines you can read.

Disposable

The flip side of fast creation is painless destruction. If infrastructure can appear from a file in minutes, it can also be torn down in minutes — and rebuilt later from the same file, identical. So a server isn't a permanent fixture you're stuck with; it's something you can stand up for a test this afternoon and remove tonight.

Think of it like renting a stage and the gear for a one-night event: you set up exactly what the night needs, then return all of it the next morning. You never keep a warehouse of equipment idle between events. Disposable infrastructure works the same way — and because the cloud bills by use, you pay only for the minutes the gear was actually out. A few things — stored data, saved backups, a reserved address — can still cost a little even while the servers are off, but the large compute charge stops.

Elastic

One more property falls out of all this: infrastructure that grows and shrinks with demand. When Pageturn is busy, the system can add more servers to keep up; when it's quiet, it can remove them so nobody pays for idle machines. That stretch-and-shrink is called being elastic, and it's the cloud version of the scaling idea you met with orchestration in Chapter 6.

That's the full picture of cloud infrastructure: on demand, from code, disposable, and elastic. The tool most associated with describing it is Terraform, which you'll actually write in the Terraform courses — and the cloud platforms it runs on are the subject of Cloud from Zero and the AWS, GCP, and Azure courses. This topic is the why; those are the where you do it by hand.