Infrastructure as Code

If you’ve ever created anything in Azure, you’d know there’s either a lot of clicking or a lot of typing going on. To provision, anything in Azure requires remembering which screen to go to or what command to run. If you’re just playing around and trying to learn Azure, that’s fine. But once that playing turns into business-critical, production processes where time is money, then something has to change.

Once your organization starts to get serious about cloud infrastructure, you’re going to be facing a lot of new challenges. You’ll encounter unnecessary duplication of work, repeated cases of fat-finger syndrome, change management issues, configuration drift, and more. The larger the organization and team, the larger the problems.

You’ll see a full breakdown of how Azure handles this challenge in the next chapter. But, before we can get into ARM templates, it’s important to first understand an umbrella term that ARM templates fall under called Infrastructure as Code (IaC).

Infrastructure as code

IaC is an industry term that refers to storing all of the stuff required to build infrastructure components in code. That code is typically defined in JSON or YAML files, representing what your infrastructure should look like.

Once all components are defined in a structured file, another process comes along, understands the code, and immediately begins using that document as instructions to build the infrastructure.

To provide a generic, pseudocode-like example, perhaps you have a VM to create. That VM has needs like compute, storage, and networking. A rough IaC approach would be to describe the VM and all of its components in a template.

The template

In the following code snippet, you can see an example of how each component could be broken down by a hierarchy with attributes defined about each component. This example was created in a JSON file most services would call a template. In the Azure world, this fictional template is an ARM template.

{
    "VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.1"
        }
    }
}

This template defines the VM and all of the attributes associated with that VM. It has a specific schema that template authors adhere to in order to define what that VM looks like. A schema file is defined as a URL in the template which, when deployed, downloads and compares the template with the schema file.

Suppose this template is then saved to a file called myvm.json.

Source control

You now have everything that makes up a VM saved in a single file. Like any good DevOps professional, you check that file in source control. You now have a way of tracking changes to the file.

The tool

Now that the file is created, you need a tool or service to read the file that understands what you’re trying to build. That tool uses the template as input and builds the VM to those exact specifications with no other interaction.

[some command line tool] -File myvm.json

Good deal, right? That’s not all.

Fighting configuration drift

Now suppose you need to change the static IP address assigned to that VM’s NIC. You could RDP to the VM and change the IP, but you don’t want to do that. Why?

1. You’re making the change manually, which wastes time and is prone to human error.

2. There’s no audit trail of who changed the IP and when.

3. There’s no automated way to revert the change should you fat-finger the IP address.

IaC can alleviate all of the above challenges. With, literally, a few keystrokes, you could make that change in a way your manager and auditor will love you for.

Open up myvm.json and change the IPAddress attribute, commit the change to source control, and run the tool again. Done.

{
    "VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.2"
        }
    }
}

[some command line tool] -File myvm.json

The tool will be smart enough to know what needs to change. It won’t detach the NIC or rebuild the entire VM. All IaC tools and services are smart enough to understand how to make the change. Magic!

But now you just realized that you used the wrong IP and need to revert back. No problem. Revert the change in source control, commit, run the tool, and you’re back in business.

But wait, there’s more.

The beginnings of continuous delivery

When you have infrastructure stored in templates under source control, you have a set of ingredients for the start of an automated release or continuous delivery pipeline.

Do you recall that you had to run that tool every time you changed the template? In an automated pipeline/workflow, that tool runs automatically. Once the process to create or make the change to the environment is automated and the moment you commit a change to the template, the infrastructure matches.

Build enough templates and eventually, your entire infrastructure could be represented in code or as code.