Why IAC?
The other day I was having a conversation with someone, catching up on the various problems we're solving at work these days. I was on my usual soapbox talking about Infrastructure as Code, CI/CD, automation, and cloud. After my spiel, they asked me: what's the point of IaC? Isn't it faster to just do things in the portal?
Over the years I've gone from asking this question myself to gaining real-world experience that has given me a far more thoughtful answer than I would've had years ago. In the spirit of doing things once, I figured I'd expound on my answer here for the next time I get asked that question.
I've been doing things in the cloud for the last decade. When I started, I thought I was ahead of the game by using Azure Pipelines instead of publishing from Visual Studio. I had a pretty good grasp on various services, how they should be configured, and could talk through what tool was the right one for the task. Imagine my surprise to be sitting in on a Terraform demo one day to find out about an entirely different approach to managing cloud infrastructure. This was the first time I asked myself "what's the point of this?".
Over the next couple of years, I got chances to refine my answer to that question. I worked on a project enhancing and migrating the infrastructure for an application deployed in Azure Commercial to Azure Government. The initial setup did its best to follow best practices, but it was evident where the click-ops approach had left mismatches and misconfigurations between the two environments they had already built. Leveraging Terraform, we were able to:
Apply best practices.
Meet our very strict security standards (and with it being codified, it makes it very audit-friendly).
Allow developers, many of whom never had to consider infrastructure, to contribute.
I want to hone in on the third point. According to HashiCorp's 2025 Cloud Complexity Report, “73% of IT leaders report that their platform engineering teams, security teams, and development teams do not communicate.” This type of culture is actually making all of those groups' jobs far more difficult. For example, earlier in my career I remember working on a project where we were ensuring all of the applications leveraged TLS1.3. This should've been a pretty simple update, but because there was no IaC-driven platform process, this effort spanned multiple teams and took multiple weeks to implement. Had this been on a team with an IaC-first culture, where developers are forced to consider security concerns and other things happening with the infrastructure, leveraging well-thought-out modules, this could've been accomplished with one or two pull requests.
Implementing an IaC-driven platform engineering process builds a bridge between developers, security, and infrastructure, and the benefits are felt immediately. A couple of years ago, while building out this type of process, someone on the team told me: "You don't understand. Before this, the developers were afraid to talk to the security team." To varying degrees, this has happened at every place I've worked at.
So, to the original question of "isn't it faster to just do things in the portal?". The answer is, sure! However, it's the faster route to a worse solution. It contributes to further silos, environment drift, and unnecessary spend. It's a large reason why "The vast majority (97%) of organizations admit struggling with their cloud infrastructure, with a similar proportion (98%) facing associated cost challenges." And with AI on the rise, this challenge isn't going anywhere. Let's leverage tools like Terraform, Bicep, and CloudFormation to build bridges between development, security, and operations to ship higher-quality software faster.
If you're part of that 97% and want to talk through how to get out of it, let's have a chat. I promise we have the solution.