Infrastructure as Code and source controle

For those who don’t what is this about, Infrastructure as Code is a set of files when executed with the right tool, will create resources such as storage account, databases, virtual network etc. It is mostly associated with the cloud. As I’ve been working lately with Terraform, I really enjoyed it and I thought it was worth a blog post.

Premise

As a developer, all you focus on is the code of your application. You launch it locally in order to debug it and this works fine until you’re done with it. Then you need to deploy it and for this to happen, you need to specify which type of resource do you need and have them created in the production environment. It was common before to ask the sysadmin to create the needed resource and also to deploy your code, but with the advent of the cloud and the Continuous Integration/Continuous Deployment, the need to script as many of those steps as possible became more pressing as time went by.

With the advent of the cloud came a paradigm shift where the infrastructure is not in our datacenters anymore nor is our source code. This helped to create the CI/CD pattern which allows the automatic build and release of our applications without human intervention (or limited to the approval of the said deployment)

Source control

Source control has been a important concept in software development for a very long time. It allowed a greater control on what is developped and how, the changes can be seen by other developers in the team so it enhances collaboration, and in the case of a on-premises server or in the cloud, the source code is safe even in the event of a computer crash or disk failure on the developer’s computer.

What we can also say about the source control, is that with it came a lot of different concept like branches and pull requests which makes it easier to review the changes and helps sharing the knowledge of the code among team members.

Regarding infrastructure, most of it used to be made manually. A sysadmin could script some of the task to create a new environment or a new infrastructure for a new project or app. However, this was time consuming. With infrastructure as code, not only we can source control the scripts that are made to create the infrastructure, but also reuse those scripts for any other similar project which we need to create an infrastructure for. With the advent of cloud computing, it makes it even easier to create the environments in the cloud since infrastructure as code usually comes with a lot of supported providers to create any resource in the cloud.

Terraform

Terraform uses yaml files in order to create the infrastructure you need for your project. With the 3620 different providers, one can reasonably assume that wherever you wish to create your infrastructure, they can do it with terraform.

terraform {
  required_providers {
    azurerm = {
      source = hashicorp/azurerm
      version = ">=2.0"
    }
  }

  provider "azurerm" {
    features {}
  }
}

resource "azurerm_resource_group" "example" {
  name     = "my-resource-group"
  location = "westus"
}

In this example, the Terraform YAML file:

1. Defines the required Azure provider and version.
2. Specifies the Azure provider and enables any additional features.
3. Creates an Azure resource group named “my-resource-group” in the “westus” location.

That’s all I have for today, happy terraforming !