I’ll be the first to admit I’ve never really been an infrastructure guy. I wouldn’t say I’m an infrastructure guy now either, but with Infrastructure as Code things are way more interesting.

What is Infrastructure as Code?

There are a lot of explanations on what Infrastructure as Code is if you google it. I’ll keep it short and link to Microsofts description for more depth.

In the traditional approach IT professionals uses a lot of pointing and clicking in GUIs to get the needed infrastructure up and running. This could be anything from networks, load balancers, virtual machines and PaaS-offerings (if on public cloud). This leads to snowflake-environments which each one gets unique configurations and that cannot be reproduced automatically. With these snowflakes administration and maintenance involves manual processes that are hard to track and is error-prone.

Using IaC you get the ability to provision stable environments rapidly and at scale. Manual configurations are avoided and consistency is enforced through representing the desired state through code. If the enviroment needs an update the environment description is updated and the release pipeline can typically execute the model to configure target environments.

From all this we see that teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure. This is a huge advantage, and gives each team the possibility to really own their own applications (you build it, you run it!).

Infrastructure as Code with Terraform

Some time ago I started playing around with a demo setup using some of the services on Azure for doing OCR analysis of images: OCR Analysis: Demo infrastructure

Even for a setup of just some services in Azure there sure are a lot of steps when you want to recreate the setup through the portal. For a long time I had a todo of looking into doing something around IaC. Having only looked at ARM templates (briefly through working with certifications) I wasn’t really looking forward to diving into this IaC-thing. Nightmarish-JSON files with a lot of specifics did not look very appealing. I of course had heard about Terraform, but I hadn’t touched it before so I didn’t know that much about it. I also knew Microsoft have something called Bicep - but I knew even less about this.

Without doing any heavy studies I chose to go forward with Terraform - mainly because how this is talked about on podcasts I’ve listened to and blogposts I’ve read. Terraform offers the possibility to describe your infrastructure in a declaritive way. Terraform is cloud-agnostic and uses a high level declarative style language called HashiCorp Configuration Language (HCL) for defining infrastructure in ‘simple for humans to read’ configuration files. Below the creation of a Function app is described using HCL:

Creating an Azure Function

Being cloud-agnostic means that each cloud-providers own specific syntax, like ARM templates on Azure and CloudFormation on AWS is abstracted away. Having looked at ARM templates and the JSON that you are expected to produce - it’s an easy choice: Terraform is a lot better. Another feature which I definitively see as useful is the ability Terraform has to create execution plans before creating, modifying and/or destroying infrastructure elements.

To sum up. I am not a Terraform-expert at this time, by no means. But I’ve played around with it and comparing it to ARM templates it is far better. In addition you can use the same syntax for multiple providers: Azure, AWS, GCP, VMware. I can definitively see why Terraform has gained traction! That being said, I haven’t looked at Bicep - it might be as good or better if you are Azure-specific, but at this point I can’t say much about that.

If you wan’t to take a look at my demo project mentioned above you can find more information on Github.