Infrastructure as Code: A Shift in Infrastructure Provisioning Thinking

Adam Bertram

Adam Bertram

Read more posts by this author.

Infrastructure as Code (IAC) or Configuration as Code: These terms have come up within the past few years based on various DevOps concepts and configuration management tools.

For me, IAC is best defined as an example. Let’s attempt to explain IAC regarding automating the building of a virtual server. When you build a virtual web server, that server will require lots of different configuration items to be labeled as “done.” That server requires creating a virtual machine, a virtual hard disk, perhaps a few Windows features, getting IIS installed, setting up a website, a couple of application pools, etc.

Let’s say you’re automating this server build with a PowerShell script. The PowerShell script starts at the top and builds your virtual machine, Windows features, IIS deployed, etc. It’s an iterative process. Each component depends on the last. When it’s complete, you end up with a. fully-functioning virtual server. Great, right?! Not quite.

Perhaps you want to create a server with the name of FOO. Inside of your script, you’ve got the server name hardcoded, and the whole script stops just because there’s already a server with that name but what do you care? You just want a server with the name of FOO. If it’s already out there, great! That’s just one less thing to configure. You don’t want this to stop the entire script. Instead, you’ll want it to continue but instead of building a new VM, use that existing one.

The same goes for a server with an existing Windows feature, IIS site, app pool, etc. You don’t want to stop the script if one of these things are already in place. You want to the script to be resilient or idempotent so that it can account for as many environmental scenarios as possible.

Also, if you need to make a change to this script, you’ll have to go into the script itself and tweak the code. What if a coworker needs to make a change and can’t understand your code? Maybe you need to explain what the script is doing to your manager. What the script is doing will be hard to follow especially if you don’t know PowerShell! Why not instead define the “structure” of the script in an external source like an XML or JSON file?

Instead, why not have a JSON file like below representing everything you want your script to do and then make your script read the JSON and gather up instructions from it? This way, anyone can understand what drives the script and the kinds of input it’s getting. If it needs to be changed, they simply change the configuration document, run the script, and it picks up the change.

    "Server" : {
        "Name" : "MYSERVER"
    "WebSites": [
            "Name": "FOO"
            "Name": "BAR"

Also, if you write your code is written with extensibility in mind, you’re never going to assume just one thing. You’re going to code in support to process multiple things. For example, if you’re creating a website with New-WebSite you wouldn’t do this if the New-Website command didn’t support creating multiple sites at once.

New-WebSite -Name BAR

Instead of writing code to support just one website, why not write code to support multiple websites like this?

$sites = 'BAR','BAZ'
foreach ($s in $sites) {
    New-WebSite -Name $s

If multi-object support is added into your code, it becomes more flexible and will require less modification down the road.

This concept is generic. The idea of defining how infrastructure should look and writing idempotent code to read from a manifest of some kind is the epitome of infrastructure as code. We’re mainly just changing how the code receives input. Lots of configuration management product leverage this methodology. Products like Desired State Configuration, Puppet, Chef, Ansible, Salt and the like all use something similar.

It’s all about defining what you’d like the infrastructure to look like and having some codebase behind it to read that manifest and apply whatever configuration is described.

I highly recommend looking more into IAC if you’re on a DevOps team, a build and release engineering team, or in charge of automating infrastructure builds in general. It’s a mindset shift for sure. It’s a different way of thinking about provisioning, but a light bulb goes off once you get it.

This post was brought to you by a YouTube #CarTalks video. Check out all of the other video content on the Adam the Automator YouTube channel!

Subscribe to Adam the Automator

Get the latest posts delivered right to your inbox

Looks like you're offline!