You are looking at a website that no human being set up by hand. It was described in a file, and a program read the file and built it. This page explains what that means, using itself as the example.
Written for someone who knows their way around tech but does not work in cloud infrastructure. No prior Azure required.
Every app and website you use runs on computers that somebody rents from a cloud company. Microsoft, Amazon and Google are the big three. You do not buy the machine, you rent a slice of one, by the hour.
The traditional way to rent that slice is a web console. You log in, find the right page, pick a size, pick a country, click Create and wait. Then you do it again for the database. Then the network. Then the firewall rule that lets the first thing talk to the second thing. Then the certificate, so the padlock shows up in the address bar.
This works. Millions of systems were built exactly this way and plenty still are. The problem is not that it fails. The problem is what you are holding at the end of it.
A running system, and no record of how it got that way.
The only real documentation is the memory of whoever did the clicking. Ask anyone who has worked in operations about the server nobody is willing to restart. Nobody knows what was done to it in 2019, the person who did it has left, and the only safe move is to leave it alone forever. There is one of these in almost every company of any age.
Write down what should exist. Let a program make it true.
Rather than performing the steps, you write a description of the destination. One web host, in this country, on the free tier, with these labels on it. Then you hand the description to a tool. The tool goes and looks at what actually exists in your account, works out the difference between that and your description, and closes the gap.
The part that catches people out is what happens on the second run. Nothing happens. A script repeats its steps and makes a mess. This does not repeat steps, it compares and corrects. If the file says three servers and there are already three servers of the right size, there is no work to do, so no work is done.
A recipe is a list of instructions. A floor plan is a description of the result. Infrastructure as code is the floor plan, handed to a builder who is willing to walk the house and re-check it against the plan every single day.
The file itself usually goes into version control, the same system programmers use for source code. That is where the name comes from. Your infrastructure is now literally code, with an author, a date and a reason attached to every change.
Here is the actual description that produced the website you are currently reading. Not a simplified illustration of one. This is the real file, copied out of the folder it lives in, and if you deleted it and ran the tool again this page would vanish.
# A container in Azure, to keep related things together. resource "azurerm_resource_group" "site" { name = var.resource_group_name location = var.location tags = var.tags } # The website host itself. resource "azurerm_static_web_app" "site" { name = var.name resource_group_name = azurerm_resource_group.site.name location = azurerm_resource_group.site.location sku_tier = "Free" sku_size = "Free" preview_environments_enabled = false tags = var.tags }
Twenty lines, and most of them are not doing anything clever. Reading it out loud:
resourcethe only real keyword hereMeans “one of these should exist.” Not “create one.” The difference matters more than it looks. It is a statement about how the world ought to be, which is exactly why running it twice is harmless.
azurerm_static_web_appthe type of thingAzure’s product for hosting a website with no moving parts. There are a few thousand of these type names, covering more or less everything Azure sells.
"site"a nicknameWhat this thing is called inside the file, so other lines can point at it. The second block does that twice, to say “put me inside the container defined above.”
var.somethinga blank to be filled inA value kept in a separate file, so the same description can build a test copy and a real copy without being edited. This is probably the single most useful idea in the whole discipline.
sku_tier = "Free"the priceWhich tier this runs on. It costs nothing, which is the only reason this page exists rather than being a screenshot in a chat window.
tagslabelsSticky notes, so that in six months somebody can work out what this was for and whether they are allowed to delete it. Unglamorous, and the first thing everybody skips.
terraform planlook before you leapReads the file, looks at the real account, and prints exactly what it intends to do. It changes nothing. You get to read that and say no. There is no equivalent of this when you are clicking buttons.
terraform applygo on thenDoes it. In this case it took 38 seconds and printed the address you are reading this at.
terraform destroythe underrated halfRemoves all of it, cleanly, because the file is a complete list of what was made. Anything built by clicking has to be un-built by clicking, and the bits people forget sit there quietly costing money for years.
This is the part that makes the idea click, so it is worth thirty seconds. Below, a file describes three machines, and reality starts out matching it.
Press Someone changes it by hand to simulate what actually happens in real companies: a colleague, in a hurry, at 6pm, clicking around in the console. Then run plan to see the damage, and apply to put it back.
This never changes on its own. It is a file.
Everything matches. For now.
Output appears here. Try the buttons in order, left to right.
applies run: 0
Two things worth noticing. The first is that the tool was never told what changed. It worked that out by comparing the description against reality, which means it can repair damage that nobody reported.
The second: press apply twice in a row. The second press does nothing at all, and says so. That property has a name, idempotence, and it is the whole reason this approach is safe to automate. Something you can run a thousand times with the same result is something you can let a robot run at three in the morning without lying awake.
The gap between the description and reality has a name too. It is called drift, and every infrastructure team on earth has opinions about it.
The preview. Prints what would change and touches nothing. In a healthy team, nobody applies anything that a colleague has not read the plan for.
Make reality match the file. Usually the shortest part of anybody’s day.
A record of what it built last time, so it can tell the difference between “this is new” and “this exists and needs changing.” When people tell horror stories about this stuff, roughly half of them are about this file.
The difference between what the file says and what is really running. Caused by humans clicking. Never fully solved, at any company, ever.
There are two common ways to write this for Azure, which is the reason the other page on this site exists at all. Here is the same web host, described both ways.
resource "azurerm_static_web_app" "site" { name = var.name location = var.location sku_tier = "Free" sku_size = "Free" }
resource site 'Microsoft.Web/staticSites@2023-12-01' = { name: name location: location sku: { name: 'Free' tier: 'Free' } }
Speaks Azure and nothing else. Being made by the same company, it tends to support brand new Azure features on the day they ship.
Speaks Azure, Amazon, Google and several hundred other services besides, in one language. Teams who are not committed to a single cloud reach for it, and so do teams who would rather learn one tool than three.
Neither is the right answer. They do the same work, and arguing about which is better is a reliable way to lose an afternoon.
Most articles about this stop at the good bit. Here is the rest, since you are the sort of person who would ask anyway.
It is still worth it, and essentially the whole industry has agreed on that. But anyone who tells you it is simple is selling something.
There is a second page on this site, written for practitioners rather than for you. It is a working reference on how these files find and call each other once a project has hundreds of them, in both languages, side by side. Fair warning rather than a dare: it gets dense quickly.
Thirteen games, because a web host does not care what it is serving. The same twenty lines above put this page on the internet, and adding Tetris, Snake, Minesweeper, Asteroids and nine others cost nothing extra and took no new infrastructure at all. The description did not change. Only the files it points at did.
Then the games got a shared leaderboard, and that broke the pattern in a way worth watching. A high score has to be remembered for everybody, and a folder of files cannot remember anything. So the Terraform grew for the first time: a storage account, a table, and a narrowly scoped key. That is the real line between the two kinds of change. Content is free. Remembering something costs you a resource.