Infrastructure as Code - Simply Explained

Imagine this. You need a test environment in Azure, nothing fancy. Just a virtual network, a couple of virtual machines and a storage account. So you log into the portal, find the resource group button and start clicking. One click to create the group. A few more to set up the virtual network then you walk through the VM creation wizard, pick the region, pick the size, pick the image, configure the disk, set up networking. That is maybe 50 clicks right there. Then you do it again for the second VM, then you configure the storage account, then you set up the firewall rules. And here's the thing. Every single one of those clicks is a chance to make a mistake. Pick the wrong region, your app runs slower than it should, choose the wrong VM size, you are overpaying from day one. Forget to close a port, you just exposed your environment to the internet without realizing it. Now multiply that by three environments. Dev, test, production, suddenly you are not doing 50 clicks, you are doing 150. And somewhere in that process, production ends up looking nothing like dev. A setting here, a checkbox there. Small differences that cause big headaches later. But what if you could describe your entire Azure setup in a file instead of clicking through all those screens? What if you could run that file once and get the same result every single time? That is what we are talking about today. By the end of this episode, you will understand what infrastructure as code actually is, why as your teams rely on it and how you can start using it without being a developer. What manual provisioning actually costs you? Let us walk through a typical Azure setup. You need a resource group inside that, a virtual network with a couple of subnets, then a couple of virtual machines, one for your web server, one for your database and a storage account for your application data. In the portal, that is a solid afternoon of clicking. And here is the problem. Every single click is a chance for a mistake. Maybe you pick the wrong region because the drop down defaults to East US and you meant West Europe. Maybe you choose a VM size that is way too expensive for what you actually need. Maybe you accidentally leave a management port open to the internet. These mistakes happen. They happen because the portal makes it easy to click fast and hard to slow down and check your work. And the real cost is not just the time you waste fixing those mistakes. It is the time you spend repeating the same clicks for dev, test, staging and production because here is what happens. You build dev on Monday. It takes you three hours and it works perfectly. On Tuesday, you build test. You are a little faster this time, two and a half hours. But you forget one setting. A firewall rule that was open in dev is closed in test. Your application behaves differently and you spend an hour debugging it. By the time you get to production on Friday, your environment looks nothing like dev. Different VM sizes, different storage configurations. A few settings you change because someone said, just try this real quick. That is configuration drift. And it is the natural result of building environments by hand. The real problem is that you cannot audit a mouse click. You cannot roll back a mouse click. If something breaks in production six weeks from now, you will not remember which checkbox you checked or unchecked. You will not have a record of what changed between dev and production. So what if you could describe your entire Azure setup in a file instead of clicking through screens? One file that says exactly what your environment should look like. Run it once, get the same result every time. Run it again, get the same result again. No drift, no forgotten settings, no production environments that look nothing like dev. Infrastructure as code, the one sentence definition. Infrastructure as code means describing your infrastructure in a file that Azure can read and build for you. That is it. One sentence. You write a file, Azure reads it, and your environment appears. Think of it like an office building. If you wanted to set up a new office, you could walk around and tell each worker where to put every desk and every chair. That is the manual approach. It works, but it is slow and everyone will end up with a slightly different arrangement. Or you could hand them a blueprint. One piece of paper that says exactly where everything goes. Every room is identical because everyone followed the same plan. Your ISE file is that blueprint. It is a single source of truth for your entire Azure environment. Everything your environment needs, the resource groups, the virtual networks, the VMs, the storage accounts, the firewall rules, it is all in that one file. Now there is an important distinction here. IAC uses what is called a declarative approach. That is a fancy way of saying you tell Azure what you want, not how to build it, step by step. You do not say create a resource group, then create a virtual network inside it, then create a subnet inside that. You say, I want a resource group with a virtual network that has a subnet. Azure figures out the order. This is different from the scripts that system administrators have used for years. Scripts are imperative. They tell the system exactly what to do, step by step, do this, then do that, then do this other thing. And if one step fails, the whole thing breaks. IAC is the opposite. You describe the end state and the system figures out how to get there. Here is a concrete example. Instead of typing 50 separate CLI commands to create a virtual machine, you write something like, I need a virtual machine with eight gigabytes of RAM, running Ubuntu 22.04, connected to this virtual network with this storage account attached. That is it, one description instead of 100 commands. And this matters for Azure specifically because the portal makes it so easy to start. You can have a virtual machine running in 10 minutes with a few clicks. But the portal does not scale when you need 10 environments instead of one, the portal becomes a liability. IAC is how you break out of that trap. So that sounds useful, right? But what tools does Microsoft actually give you to write these blueprint files? The Azure IAC toolkit, ARM, bicep, and the elephant in the room. So what tools does Microsoft actually give you to write these blueprint files? The original one is called ARM templates. ARM stands for Azure Resource Manager, and these templates have been around since the beginning. They are written in JSON, which is a data format that looks like a configuration file from 2015. Lots of curly braces, lots of brackets, lots of indentation. If you have ever looked at a JSON file, you know what I mean. It is functional, but it is not pleasant to read. ARM templates are still widely used, especially in enterprise environments. Big companies have invested years into building their template libraries. And they are not about to throw that work away. But if you are a beginner looking at an ARM template for the first time can be intimidating. It is verbose, it is easy to break. One missing comma and the whole thing fails. Writing one by hand is painful. Microsoft recognized this problem. So they built bicep. bicep is Microsoft's answer to ARM templates are too complicated. It is a newer language that compiles down to ARM templates behind the scenes. But the syntax is much cleaner. It looks like actual code. You write something like resource myvm, Microsoft. Compute virtual machines at 223.0301. L.O. Instead of pages of nested JSON. It is designed for humans first. Now there is another option you will hear about Terraform. Terraform is a tool from a company called Hashikorp and it works with Azure and other clouds. If you need to manage infrastructure across AWS, Google Cloud and Azure all at once, Terraform is your best bet. It is more portable. But that portability comes with a cost. Terraform adds a layer of abstraction between you and Azure. You have to learn Terraform's own language, HCl, on top of understanding Azure itself. It is powerful but it introduces its own complexity. So which one should the beginner pick? If you are a Zua only, start with bicep. The reason is simple. Native integration. bicep is built by Microsoft specifically for Azure. It has fewer moving parts. It gets Microsoft's full support. And because it compiles down to ARM templates, you are not locked into anything. You can always switch to raw ARM templates later if you need to. bicep is the path of least resistance for someone who just wants to get started. Here is how these tools work in practice. You write a file. A bicep file, an ARM template, whatever you choose. Then you run a command. A bicep that command is as deployment group create. Azure reads your file. Compares it to what already exists and builds whatever is missing or changes whatever is different. You do not have to tell Azure what order to do things in. It figures that out on its own. And here is where it gets really interesting. You can hook this into a CICD pipeline. Continuous integration, continuous deployment. That means every time you push a change to your code repository, Azure automatically runs your IAC file and updates your infrastructure. No manual steps, no one logging into the portal. That code changes flowing into production automatically. So you have a file that describes your infrastructure. You can run it and get a consistent result. You can even automate the whole thing with a pipeline. But what does that actually unlock? That is where things get really powerful. What version control does for your Azure environment? Here is the thing people do not talk about enough. The real superpower of IAC is not the template format itself. It is not bicep versus ARM versus Terraform. The real superpower is version control. When you store your IAC files in a repository like GitHub or Azure Repos, every single change becomes trackable. Who changed what? When they changed it? Why they changed it? You get a complete history of every modification to your infrastructure going back to day one. And that means you can roll back. If a deployment breaks something, you do not have to guess what went wrong. You do not have to dig through portal audit logs hoping to find the answer. You just revert to the last working version of your IAC file and redeploy. The problem disappears. That is something you simply cannot do with mouse clicks. It also means your environments stay consistent. You have tests and production all come from the same files. Not similar files, not files that started the same but drifted apart over time, the same files. You deploy dev from your main branch. When you are ready for test, you deploy the same files to the test subscription. When you are ready for production, you deploy the same files again. Every environment is identical because every environment was built from the same blueprint. And because these files live in a repository, you can do code reviews for infrastructure. Before anyone deploys a change, another team member has to look at it and approve it. It catches mistakes before they ever reach your environment. It is the same process software developers use for application code. Apply to your Azure setup. Here is a real world example. Someone on your team accidentally opens a storage account to the public. Without IAC, you might not notice until the bill arrives. Or until someone tells you your data is exposed. With IAC, that change is visible in the repository. It goes through code review. Someone spots it and says, "Hey, that storage account should not be public." The change gets blocked before it ever reaches production. And if it somehow slips through, you can roll it back in seconds. You can even use branching strategies. Want to experiment with a new configuration? Create a separate branch, make your changes, deploy to a test environment, see if it works. If it does merge back to the main branch. If it does not, delete the branch and try something else. Your production environment never gets touched until you are confident that change is safe. Consistency is great. But IAC also makes your Azure setup more secure. And that matters whether you have one person managing everything or a whole team. Security by design, not by accident. Here is something that surprises a lot of people. When you use IAC, security is not something you add later. It is baked into the template from the start. Instead of remembering to enable encryption on every new storage account, it is already in your file. Instead of hoping someone configured the firewall rules correctly, the rules are written down and enforced every single time. This idea has a name, policy as code. You encode your security rules directly into your deployment pipeline. So every time someone tries to deploy a storage account, the pipeline checks that HTTPS is enabled, that encryption is turned on, that public access is blocked. If the template does not meet those rules, the deployment fails. The insecure configuration never reaches your environment. Think about what that replaces. Dozens of manual checks. Someone remembering to tick the right checkbox. Someone else auditing those checkboxes later. All of that goes away. One secure template, one set of policies and every deployment automatically meets your security baseline. But here is where it gets really interesting, disaster recovery. The file that describes your infrastructure can rebuild it anywhere. If an attacker compromises your environment, you do not have to spend days trying to figure out what they changed and how to fix it. You tear it down. You redeploy from your IAC file. Your clean environment is back in minutes. That is not possible when your infrastructure was built by hand. And because everything is in version control, you have an audit trail. Every change to your infrastructure is recorded. Who made it? When? Why? That is compliance evidence without anyone having to fill out a spreadsheet. For small teams, without dedicated security staff, this is a force multiplier. You get enterprise grade security practices without hiring an enterprise grade security team. This all sounds great on paper. But getting started can feel overwhelming. Let me give you a realistic path forward. How to start without breaking anything? Rule one. Do not start with production. I cannot emphasize this enough. IAC is powerful, but it is also new. You will make mistakes. Make them somewhere. It does not matter. Pick one small piece of your Azure environment, a resource group with a single virtual machine or a storage account. Something simple that you already have running. Something you know works. Here is the trick. The Azure portal can actually generate arm templates from your existing resources. You go to your resource group, click export template. An Azure gives you the JSON file that describes everything in that group. It is not perfect. The exported template often includes things you do not need. But it is a starting point. You take something you build manually and convert it to code. That is the reverse engineer approach and it is the fastest way to learn. Start with bicep and the free Azure tools. Microsoft has a VS Code extension for bicep that gives you syntax highlighting, auto completion and a visual preview of what you are building. You can see your virtual network and your subnets rendered as a diagram before you deploy anything. That makes it much easier to understand what your code actually does. Use a separate subscription for testing. Most Azure subscriptions have spending limits and free credits. Create a test subscription. Deploy your IAC there, break things, fix them, learn. When you are confident, move to a non-production subscription. Production comes last. Here is the part that might surprise you. You do not need to be a software engineer to do this. The citizen developer angle is real. Bicep was designed for people who manage Azure infrastructure not for professional programmers. It is readable. It has less ceremony than traditional programming languages. It is focused on Azure and nothing else. If you can understand what a virtual machine is, you can learn to describe one in bicep. Your first practical project? Automate your dev environment, tear down and rebuild. Write a bicep file that creates your dev setup. Deploy it, use it, then tear it down and deploy it again. Do that a few times until the process feels routine. And exercise alone will teach you more about IAC than any tutorial. A few pieces of common beginner advice. Commit early and commit often. Every time you get a piece of your template working, save it to your repository that gives you checkpoints you can go back to. And always run the preview command before deploying. In bicep that is what if. It shows you exactly what will change before anything actually changes. No surprises. Even with the best intentions, there are a few traps beginners fall into. Let me save you some late night debugging sessions. Three mistakes that will haunt you. And how to avoid them. Mistake number one is the classic. Hard coding secrets. You are in a hurry. You need to get a template working so you drop the database password right there in the file. It works. You move on. And now your password is sitting in your IAC repository for anyone with access to see. Obviously in hindsight, right? But it is incredibly easy to do when you are focused on getting something to work. The solution is Azure Key Vault. Both bicep and ARM templates can pull secrets directly from Key Vault at deployment time. Your file says get the password from this vault instead of containing the actual password. The secret never touches your repository. Never put passwords, connection strings or API keys in your IAC files. Use Key Vault every single time. Mistake number two is treating IAC like a one time script. You write a template, deploy it, it works, and you never look at it again. Six months later, something breaks. You open the file and have no idea what half of it does. That parameter called Param1, no idea. It resorts with the cryptic name, no clue. Write your IAC as if someone else will maintain it six months from now because that someone else is probably you and you will have forgotten everything. Add comments, use descriptive names instead of abbreviations. Keep files small and focused on one thing. A bicep file that creates a virtual network should be about virtual networks, not about the whole data center. Mistake number three is bypassing the pipeline for quick fixes. The portal is always tempting. You need to change one setting. It would take five minutes to edit the template, commit and deploy through the pipeline. Or you can just log into the portal, click three times and be done in 30 seconds. That quick change creates drift. Your code says one thing, reality says another. Next time you deploy from your template, as you are trying to undo your manual change. Or worse, it does not notice the drift and your environment slowly diverge until production behaves completely differently from dev. The discipline is simple. Make the change in code, deploy through the pipeline. Even if it takes five extra minutes, that five minutes saves you hours of debugging later. One bonus tip, always run the preview command before applying changes. In bicep, that is what if? It shows you exactly what will be created, modified or destroyed. No surprises. You see the impact before it happens. That is, IAC in plain English, no jargon, no marketing fluff, just a practical tool that makes your Azure life easier. The one thing to try this week. So here is what we covered. IAC turns your Azure infrastructure into a version controlled, repeatable, secure blueprint. One file that describes everything, deployed the same way every time. Your challenge this week. One existing Azure resource as an ARM template. Open it in VS code. See if you can understand what it does. That single exercise will teach you more than any explanation I could give. Next up in this series, we walk through writing your first bicep file step by step. Subscribe on your favorite podcast platform and share this with a teammate who is still clicking through the portal.