Here's a situation that's more common than anyone admits. Your application runs on a server, a database and a load balancer somebody set up by clicking through a cloud console a couple of years ago. They've since left. Nobody remembers exactly which options were ticked. The server dies, and rebuilding it turns into a week of guesswork.
Infrastructure as code (IaC) is the cure. You describe your servers, networks and databases in text files, and a tool creates them from those files.
The idea in plain words
Instead of clicking "create server", choosing a size, adding a firewall rule and attaching a disk, you write something like: "I want one server of this size, in this region, with these ports open." Then you run a tool, and it builds exactly that.
Because it's text, it can live in version control next to your application code. You can see who changed what, review changes before they happen and go back to an earlier version.
What you gain
Repeatability. Need a second environment for testing? Run the same files with a different name. The copy matches the original because it comes from the same description.
Recovery. If something is destroyed, you can recreate it in minutes instead of reconstructing it from memory.
Review. A teammate can read a proposed change and spot a mistake, such as a database accidentally open to the whole internet, before it goes live.
Documentation that doesn't go stale. The files are the truth about what exists. A wiki page describing your setup is usually wrong within a month.
Less drift. When people tweak things by hand "just this once", environments slowly diverge. Code that's applied regularly keeps them aligned.
The tools
Terraform (and its open-source fork OpenTofu) is the most widely used. It works across many cloud providers with one approach. You declare the end state, and it works out what to create, change or remove.
Cloud-specific tools such as AWS CloudFormation or Azure's Bicep do a similar job within a single provider.
Pulumi lets you write infrastructure in a regular programming language, which some teams prefer.
Ansible is often used to configure what's inside servers once they exist, such as installing software and setting files.
The differences matter less than getting started. Pick the one that fits your team and cloud, and stick with it.
How it works day to day
You change the files. The tool shows a plan: "I'll create two things, change one, and delete nothing." You read the plan carefully, and only then apply it. That review step is the safety net, so don't skip it.
The tool also keeps a record of what it manages, called state. Protect it. Store it in a shared, locked, backed-up location, not on one person's laptop, because losing or corrupting it creates real confusion.
Pitfalls to avoid
Secrets in the code. Never write passwords or keys into the files you commit. Use a secrets manager.
Mixing hand changes and code. If someone edits a resource in the console, the code and reality disagree, and the next apply may undo their change or fail. Agree that changes go through code.
One giant file. Split things into sensible pieces: networking, databases, applications. It's easier to read and safer to change.
Applying straight to production. Try changes in a test environment first, and require review for production.
Forgetting what it can delete. Removing a block from the files can destroy a real database. Turn on deletion protection for anything that holds data, and read every plan.
How to start without a big project
You don't have to convert everything on day one. Begin with something new, say a test environment or a small supporting service, and build it entirely in code. Once the team is comfortable, bring existing resources under management a few at a time, which most tools support through an import feature.
Even a small step, such as capturing your firewall rules in code, removes real risk. Next time something breaks, you'll be glad you wrote it down.
