Provisioning: Creating Servers From Code

The last topic argued for describing infrastructure in a file instead of clicking. This topic is about the first thing that file does: bring the infrastructure into existence. Creating the servers, networks, and storage themselves — from a written description — is called provisioning.

Here's the shape of it. Sam writes what he wants — say, one small server in a particular region — into a file. A provisioning tool reads that file, talks to the cloud provider on his behalf, and a few minutes later the server is really running. The same file, run again tomorrow, builds the same server again. Terraform is the best-known provisioning tool, and it's where Sam would do this for real.

What provisioning means

Provisioning is the act of creating infrastructure from a description. The word just means "providing what's needed" — and what's needed here is the raw machinery: the servers, the networks that connect them, the storage they keep data on. Before provisioning, that machinery doesn't exist; after, it does.

It helps to be precise about the boundary, because the next topic sits right next to it. Provisioning creates the machine. It does not install Pageturn, or set anything up inside the machine — it hands you a running but empty server. Making that empty server ready is configuration, the second half of the chapter.

Declarative: you state the result, not the steps

The surprising part of provisioning is that you don't write out the steps. You don't say "first do this, then click that, then wait." You state the end result you want — "one small server in this region" — and the tool works out the steps to get there on its own. This style is called declarative: you declare what, and the tool decides how.

You've already met this idea. In Chapter 6, you told the orchestrator "keep five copies running" rather than babysitting each one. Provisioning works the same way: you describe the desired state of your infrastructure, and the tool makes reality match it. Declaring the destination, not the turn-by-turn directions, is the heart of both.

What the description looks like

It's worth seeing one, just to make it concrete. Below is a tiny, made-up example in the style Terraform uses. You are not going to write or run this — read it like a label on a museum exhibit. It declares one thing called a "server," names it pageturn, and gives it two properties: a size of "small" and a region of "us-east." That's the whole idea — a short, readable block that says what server should exist, with no steps for how to make it.

resource "server" "pageturn" {
  size   = "small"
  region = "us-east"
}

Notice what isn't there: no clicking, no sequence of commands, no mention of how the provider builds the machine. The file states the destination and stops. A provisioning tool reads it and does the rest. You'll write real Terraform like this — for actual clouds — in the Terraform on AWS / on GCP courses; here it's just enough to see what "infrastructure as code" literally looks like.

Repeatable environments

The payoff of a description is that you can run it more than once. Teams usually run software in a few separate copies — a development copy for building, a staging copy for final testing, a production copy for real users (you'll meet these properly in Chapter 8). Provisioning from one file means all three can be built from the same description, so they actually match.

That solves a real headache: bugs that appear only in production because production was set up slightly differently from where it was tested. When every environment is provisioned from the same file, "it worked in testing" carries a lot more weight. Build it, change it, and rebuild it identically — that repeatability is the whole reason provisioning beats clicking.