Terraform - Simply Explained

0:00 Terraform exists because your Azure Portal clicks can't be rebuilt twice. It writes that infrastructure down as a file. You can read, review, and run again. Small plugins called providers, many of them written by the platform teams themselves let Terraform reach Azure, AWS, and thousands of other services. Welcome to the M365 FM podcast where we explore the people, ideas, and technologies shaping the future of work. Cloud teams keep coming back to it because writing infrastructure down means nobody has to remember it. So it's worth understanding even if you never write a line of it yourself. By the end, you'll be able to read a Terraform setup and say what it will do before it does anything. What infrastructure as code really means? Think about the last time you built something in the Azure portal, a resource group, or a storage account, or a small virtual machine you needed for testing.

0:43 It took ten minutes and everything worked. Now imagine someone asked you to build that same setup again next month. For a different team, you have to do it from memory naming every setting you picked in the order you picked it. Almost nobody can get through that without missing something. And that gap is the entire reason. Infrastructure as code exists. Infrastructure as code means you write down what you want to exist in a file instead of clicking it into existence. The file is plain text, and it names the things you need, the way you'd write a list for someone else. It sits in the same place as your other work, which changes how a team behaves. A change to the file can be reviewed before it happens and traced afterwards. It also means you can copy the file, so a setup that works in one place can be reused somewhere else without anyone rebuilding it from memory.

1:24 People describe infrastructure in a file in two different ways, and the difference matters more than it sounds. One way is imperative, where you spell out every step in order, creating one thing and then the next, and then connecting the two together. The other way is declarative, where you describe the result you want and let the tool work out the steps. Terraform belongs to the second group, which is why you almost never see it written as a list of instructions. So the habit shift is simple enough to say out loud. You stop remembering what you clicked and you start writing down what you want. Everything else in this episode is a detail hanging off that one change. The first time a plan comes back with nothing to change. You'll see why teams get attached to it. What Terraform actually is. Terraform is an infrastructure as code tool that lets you build, change, and version your cloud resources safely and efficiently.

2:06 That's how HashiCorp, the company that built it, describes the product. Those three verbs build, change, and version cover nearly everything you'll ever do with it. It also works with older infrastructure that runs in your own data center, which is what people mean when they say on premises. HashiCorp released Terraform in twenty fourteen, and the tool has had more than a decade to grow up in public. It grew alongside cloud platforms and had years to smooth down the rough edges. It now handles small things like a single storage account and large things like an entire network with routing firewalls and a load balancer in front of it. It also had time to settle into a shape a beginner can pick up in an afternoon, which is not something every cloud tool can claim. The workflow underneath all of that has three stages, and they're worth holding on to because every other idea in this episode hangs off them.

2:49 First, you write the configuration, which is a text file in a language HashiCorp built for the job. It reads close to plain English. Once you know a handful of words, then Terraform produces a plan describing what it intends to create, change, or destroy. Once you approve that plan, it goes and does the work in the right order without you walking it through the steps. That order matters more than beginners expect. Terraform builds what's called a dependency graph. It knows that a network has to exist before anything can be attached to it, and it works through everything that doesn't depend on anything else at the same time. You never write that sequence yourself. You describe the destination and Terraform finds a route providers how Terraform talks to your cloud. The next word to learn is provider, and it's the one that unlocks the rest of Terraform.

3:30 A provider is a plugin that teaches Terraform how to speak to a single platform. It uses the interface that platform publishes for software, which the cloud world calls an API. Add the Azure provider and Terraform can create Azure resources, add the AWS provider, and it can create AWS resources. With both in place, it can build across the two in a single run. There's a provider for almost everything you've heard of from the three big clouds to Kubernetes, GitHub, Datadog, and a long tail of smaller services HashiCorp and the community have written thousands of them, and they're all listed publicly in the Terraform registry. The reason providers exist as a separate thing is worth a moment. Terraform itself stays fairly small and only knows how to compare what you want with what exists. Each platform contributes its own translation layer, written by the people who know that platform best.

4:12 A resource is the second piece of vocabulary. A resource is one thing you want to exist, such as a storage account or a virtual network. You describe it by naming the kind of thing it is, then listing the settings you care about. Everything else gets a sensible default. That's the entire shape of a Terraform file, repeated as many times as you have things to build. This is also where the fear about being locked into one cloud falls apart. Because providers are separate from Terraform, the same tool reaches several platforms, and one configuration can manage an Azure environment and a GitHub repository at the same time. You're not choosing a vendor when you choose Terraform, you're choosing a way of describing what you want. The part people get wrong first is not the provider, though. It's the file Terraform keeps about everything it has already built, and that file has caused more damage to more teams than any other piece of this tool.

4:55 We'll get to it and I'll tell you exactly where it bites. Plan and apply the safety net you meet for commands when you start with Terraform, and they arrive in a fixed order and it prepares your working folder and downloads the providers you asked for. Plan works out what would change and apply makes those changes real. Destroy takes everything down again, which is the command you keep in your pocket and treat with respect. Plan is the one that earns Terraform. It's trust. Terraform compares three things what you wrote, what it recorded last time, and what exists in your cloud right now. Then it shows you a list of what it intends to add, change, or delete before it touches anything. You get to read that list, argue about it with a colleague, and change your mind. Apply as the short step. At the end, you confirm the plan and Terraform executes it respecting the dependencies it worked out earlier.

5:39 If your configuration asks for a virtual network and three machines inside, Terraform will make sure the network exists. First, nothing has to be sequenced by hand, and once you approve the plan, you can step back in. A team plan stops being a personal habit and becomes a checkpoint. The plan gets attached to the change request. A colleague reads it and the apply only happens after someone else has looked at what's about to happen. That feels different from watching a colleague click through the portal while you read the output afterwards. Destroy deserves its own mention because it does exactly what it says, and it does it to everything in that state file at once. There's an honest caveat worth saying out loud. Plan output can be a wall of text on your first attempt, and some entries are hard to predict. That's especially true when Terraform warns that a change will force a resource to be replaced. That warning is not an error.

6:19 It's Terraform telling you it plans to delete the old thing and build a new one. Read those lines slowly, because that's where surprises live. So plan is the safety net, and the reason it can work at all is that Terraform has something to compare your file against. That something is the state file, the one I mentioned, and it gets its own section in a moment. The state file Terraform's memory. The scary file is called the state file, and it is terraform's memory of the infrastructure it built. HashiCorp describes it as the source of truth for your environment. In plain terms, Terraform uses this record to decide what has to change. So reality matches what you wrote. Without it, Terraform would have no idea which of the resources in your subscription it created and which ones were there before. Inside the state file, you'll find real details about real things, including the identifiers your cloud assigns to each resource and the values you gave it.

7:04 Some of those values are passwords, connection strings, and private addresses, and they sit in that file as readable text. That one detail explains most of the rules people repeat about state. Never commit it to your team's code repository and never open it and start editing entries by hand. Instead, you use the commands built for the job. Moving a resource or renaming it in state is a command, and removing something from state without deleting it from your cloud is another. They exist precisely so you never have to touch the file itself. It sounds fussy until the first time you rename something in your configuration and need the record to follow along without rebuilding the resource from scratch. If the state file is lost or damaged, the recovery is not quick. You can restore an older copy from a backup if you set your storage up to keep versions, which is a small decision with a large payoff without one, you rebuild the record by importing each existing resource one at a time, and that gets slow very fast.

7:52 On a large environment. It's the kind of afternoon nobody plans for and everybody remembers. Handled properly, though, this file is what makes Terraform feel fast on your first run, it records the things it created on your second run. It looks at those resources, notices that most of them already match what you want and leaves them alone. Nothing is created twice, nothing is deleted by accident, and the only work left is whatever you changed. That's the payoff of keeping the record honest. And it's why the boring advice about backups and access control turns out to matter so much. Modules stop rebuilding the same thing. Once you've written the same block of configuration a few times, you'll notice the pattern. Every new project needs a storage account, a network, and a set of permissions, and the details differ only slightly from the last one.

8:33 A module is how Terraform answers that, and it's a reusable bundle of infrastructure that you can hand to a colleague or keep for yourself. HashiCorp calls them configurable collections of infrastructure, which is accurate and a little dry. Think of a module as a recipe with a few blanks you fill in each time. Modules come from two places. There's a public registry full of modules that other people published, covering everything from a single secure storage account to complete multi-region environments. Then there are the private modules your own team writes, which encode how your organization does things from naming conventions to the network rules that must be applied. The private ones are usually the more valuable of the two, because they carry knowledge that isn't in any vendor's documentation. There's a cost worth naming a module you didn't write is still code that runs against your subscription, and you're the one who answers for it.

9:16 PIN the version you're using so an update doesn't arrive while you're asleep, and read what the module does before you point it at anything. That's not caution for its own sake. It's the same instinct that stops you installing software from a link a stranger sent you the first time. You swap a hundred lines of repeated configuration for a module you call with three settings, the point stops needing any explanation at all. Remote state working with other people. Everything so far works on one laptop, and that's where it stops being simple. Picture two engineers on the same team, both fixing something on a Friday afternoon. The two of them run a plan, see the same state file and apply a change. One of those applies wins and the other person's work vanishes without a warning on anyone's screen. It isn't carelessness. It's what happens when the team's shared record lives on two machines.

9:58 Remote state is the fix. Instead of keeping the state file on a laptop, you keep it in a shared place, such as an Azure storage account or an AWS bucket. Every engineer then reads and writes the same copy. That one move buys three separate things. Two runs can't collide because Terraform locks the state while it's working. Encryption keeps those passwords and connection strings out of the open. Access can be restricted, so the state is only visible to the people who should see it. Teams that have done this for a while add a few habits on top. They keep one state file per environment and per component, instead of one enormous file that touches everything at once, versioning gets switched on so a bad day can be undone and the state store gets its own credentials. Rather than reusing the admin account somebody created in a hurry. If you'd rather not run any of that yourself, there are managed services that store the state and execute the runs for you, and HashiCorp sells one of them.

10:45 It's a reasonable option for a small team with no platform engineer. The concepts are the same either way, and it's worth learning on the command line first, so you can tell what the service is doing on your behalf. What matters at this stage is that this record sits somewhere the whole team can reach, and only the right people can change. That's the difference between infrastructure, your team trusts and infrastructure. Your team guesses at drift when reality quietly changes. Even a careful team has one enemy left and it doesn't come from inside. The tool drift is any change to infrastructure. Terraform manages that Terraform didn't make, and it happens more often than anyone admits. The classic version goes like this. An engineer gets paged during an incident, logs into the console, raises an auto scaling limit from five to ten, fixes the problem, and moves on.

11:27 The code still says five. The cloud says ten. Nobody notices for weeks, and then someone runs a plan for an unrelated reason. There it is in the output ten, going back to five. Because Terraform has just read the real world and found a difference. That's the moment people learn to respect drift, because Terraform is about to undo a fix that someone made deliberately. Catching drift is mostly a matter of looking on purpose. A normal plan refreshes what Terraform knows about your real resources and shows you whatever doesn't match. There's also a refresh only version of that command, which updates the record without proposing any infrastructure changes at all. Then you have a choice, and both answers are legitimate. You can update the file to match what's running now, which is the right call when the manual change was a good one. Or you can apply the plan and roll reality back to what the file says.

12:07 And that's the right move. When someone was experimenting and forgot to clean up some drift is deliberate and some is a mistake, and no tool can reliably tell the two apart that judgment belongs to the team. You might expect the obvious answer here to be automation, where every difference gets reversed the moment it appears. People who have run this at scale advise against that, because a tool that reverts every change will eventually revert something that mattered when Terraform is the right choice. So this earns its keep in a few specific situations. The strongest case is when you have more than one place to manage. If your infrastructure lives in Azure, your code sits in GitHub and your monitoring live somewhere else. Terraform gives you one language and one workflow across all of it. The second case is rebuilding, because a written configuration turns a stressful afternoon into a single command.

12:52 The third case is review. Because a file can be proposed, discussed, and approved before anything happens, and that conversation is stored for later. If you have lived through an outage caused by an undocumented change, this tends to matter more than it does to everyone else. There are also honest reasons to walk away from it. If everything you run lives inside a single cloud. A tool built for that cloud is often the simpler answer. Microsoft's own bicep for Azure and Amazon's cloud formation exist for exactly that situation. They're narrower and tied to one platform, and for a single platform team, that is a feature. Between those two extremes, there's a middle ground. Pulumi lets you describe infrastructure in ordinary programming languages instead of Terraform's own, which suits teams that already live in TypeScript or Python. Ansible, which many Microsoft Teams already use, configures software on machines that exist.

13:35 It can create infrastructure too, which is why running it alongside Terraform without clear boundaries is a known way to create drift. One practical note, because it comes up in every team's first conversation. Terraform's command line tool is free to use on your own infrastructure. You'll also hear the name Open Tofu, an open source version built by the community that speaks the same language. The file you learn to write works with both, so this isn't a decision you have to make today. Strip all of it back and Terraform is a trade. You spend time writing down what you want in a language you have to learn, and in exchange, you stop depending on anyone's memory of a portal. Whether that's worth it depends on how much infrastructure you have and how many people touch it. A quick recap and one question for you. So the whole thing comes down to this. Infrastructure as code means the environment you want lives in a file, not in somebody's memory of a portal.

14:19 Providers are how Terraform reaches each platform plan shows you what will change before it changes and apply. Makes it real. The state file is terraform's memory of what it built, and modules stop you rebuilding the same thing twice. Remote state keeps a team from overwriting each other and drift is reality. Quietly disagreeing with your file? There's one question worth taking with you. Which part of your own setup would you most want written down in a file? And what's actually stopped you from doing it?