Compare ARM templates vs. Terraform for infrastructure as code

Prerequisites

To get started evaluating ARM templates and Terraform, install the following on your machine:

• Microsoft Visual Studio Code and the Azure Resource Manager Template Extension for Visual Studio Code;
• Terraform and Azure PowerShell -- the Azure Cloud Shell interactive shell has both pre-installed; and
• A Microsoft Azure account.

Azure Resource Manager templates

ARM templates are JSON documents that define each aspect of the IT infrastructure. For example, a compute resource for a new VM includes its size, credentials, version and attached storage all defined in the same JSON file.

Below is an example ARM template for an Ubuntu Server VM:

# JSON

...
{
  "name": "ubuntuVM1",
  "type": "Microsoft.Compute/virtualMachines",
  "apiVersion": "2019-07-01",
  "location": "[resourceGroup().location]",
  "properties": {
    "hardwareProfile": {
      "vmSize": "Standard_A2_v2"
    },
    "osProfile": {
      "computerName": "ubuntuVM1",
      "adminUsername": "adminUsername",
      "adminPassword": "adminPassword123"
    },
    "storageProfile": {
      "imageReference": {
        "publisher": "Canonical",
        "offer": "UbuntuServer",
        "sku": "16.04-LTS",
        "version": "latest"
      },
      "osDisk": {
        "name": "ubuntuVM1-OSDisk",
        "caching": "ReadWrite",
        "createOption": "FromImage"
      }
    },
...

IT admins who are familiar with JSON formatting will find this template input familiar: Microsoft has a well-defined schema that enables easy ARM template creation in Visual Studio Code. Open a new JSON document and type arm and you can generate a new blank template to which you can add resources.

These infrastructure-as-code documents can get incredibly long and verbose -- but this is necessary to configure every detail of the infrastructure. The code sample above for the single Ubuntu VM and its supporting components comes from a JSON file that is 167 lines long.

IT admins deploy these configurations from an authenticated Azure CLI or Azure PowerShell session. This article's examples use Azure PowerShell. Run the New-AzResourceGroupDeployment cmdlet in the template file once it, and a resource group, have been deployed.

# Azure PowerShell

New-AzResourceGroupDeployment -Name demodeployment -ResourceGroupName ata-rg -TemplateFile ./az_templates/template.json -Verbose

Provided the template is valid, any defined resources deploy into that resource group when the cmdlet runs. If one of the defined resources gets destroyed, redeploy the template file -- without making changes -- to restore it.

HashiCorp Terraform

Terraform is a popular tool with DevOps practitioners because it can enforce configurations on various cloud platforms, such as Azure, AWS and Google Cloud Platform, but there are also community and experimental providers for PostgreSQL, VMware and even Active Directory.

Terraform is a multi-cloud product. Admins who know how to create infrastructure in a given provider can write Terraform resources for it. The process is relatively similar across cloud platforms.

Typically, Terraform configurations are written in HashiCorp's proprietary, declarative language called HashiCorp Configuration Language (HCL). Consequently, Terraform's learning curve is higher than that for ARM templates, which use the more common data formatting approach of JSON.

An example illustrates the difference in infrastructure code between ARM templates' JSON files and Terraform's HCL structure. The Terraform code below creates the same VM deployment that we made in the ARM template:

# HCL

resource "azurerm_linux_virtual_machine" "example" {
  name                            = "ubuntuVM1"
  resource_group_name             = azurerm_resource_group.example.name
  location                        = azurerm_resource_group.example.location
  size                            = "Standard_F2"
  admin_username                  = "adminUsername"
  admin_password                  = "adminPassword123"
  disable_password_authentication = false

  network_interface_ids = [
    azurerm_network_interface.example.id,
  ]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "16.04-LTS"
    version   = "latest"
  }
}

ARM templates are all created in one file. By contrast, Terraform evaluates every resource in the directory with a .tf extension -- and will do so for every command that runs the resource, which enables IT admins to break up resources into separate files to ease parsing. For example, an IT admin can write infrastructure as code into three files -- all of which must have a.tf file extension:

• subnets.tf
• security_groups.tf
• virtual_machines.tf

IT admins can authenticate the Azure Terraform provider with the CLI or a Service Principal, which is an authentication application within Azure Active Directory. Once you set up the authentication, execute Terraform code with the init command, followed by terraform apply. Terraform should return the following output:

➜  ~ terraform apply
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # azurerm_linux_virtual_machine.example will be created
  + resource "azurerm_linux_virtual_machine" "example" {
      + admin_password                  = (sensitive value)
      + admin_username                  = "adminUsername"
      + allow_extension_operations      = true
      + computer_name                   = (known after apply)
      + disable_password_authentication = false
      + id                              = (known after apply)
      + location                        = "eastus"
      + max_bid_price                   = -1
      + name                            = "ubuntuVM1"
      + network_interface_ids           = (known after apply)
      + priority                        = "Regular"
      + private_ip_address              = (known after apply)
      + private_ip_addresses            = (known after apply)
      + provision_vm_agent              = true
      + public_ip_address               = (known after apply)
      + public_ip_addresses             = (known after apply)
      + resource_group_name             = "ata-rg"
      + size                            = "Standard_A2_v2"
      + virtual_machine_id              = (known after apply)
      + zone                            = (known after apply)

      + os_disk {
          + caching                   = "ReadWrite"
          + disk_size_gb              = (known after apply)
          + name                      = (known after apply)
          + storage_account_type      = "Standard_LRS"
          + write_accelerator_enabled = false
        }

      + source_image_reference {
          + offer     = "UbuntuServer"
          + publisher = "Canonical"
          + sku       = "16.04-LTS"
          + version   = "latest"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

Enter yes to deploy the resources from the desired configuration into the Azure subscription to which you've authenticated. Similar to ARM templates, Terraform restores an altered configuration to its desired state if you rerun the terraform apply command. This capability is useful in times when someone deletes a resource file manually or puts the system out of configuration. You can see the output from the terraform apply command in Figure 3.

To tear down all the resources, run terraform destroy and enter yes -- just like the terraform apply command -- to remove any resources that Terraform created.

ARM templates vs Terraform: pros and cons

There are some significant benefits to defining infrastructure as code. There are also downsides, but they can be inconsequential depending on the use case and requirements.

As these examples of ARM and Terraform show, the same infrastructure deployment looks different depending on the tool in use. To choose a tool, consider the product roadmaps and features. For example, ARM templates work with the latest features from Azure as soon as Microsoft releases them, because ARM is a native product for the cloud platform. Terraform, on the other hand, is open source. A Terraform community member must add any new Azure features to the Azure Terraform provider.

ARM templates' primary downside is that they are restricted to Azure cloud deployments. However, while it takes a significant amount of work to write the same infrastructure in a different provider and achieve identical results, it is possible to do it in the same tool. By contrast, Terraform users can deploy the same setup to Azure, AWS, on-premises servers and other locations by design.

Editor's note: Azure Arc, in preview at the time of publication, extends Azure Resource Manager capabilities to other infrastructure on premises and on other clouds.

ARM templates and Terraform provide different methods for variables, conditions and internal logic. IT admins should invest time in training to understand how the tool works and maximize its usefulness. Whichever tool your organization adopts, IaC provides return on investment almost immediately.

Conversion to infrastructure as code, rather than manual provisioning and maintenance of IT systems, is a simple task for well-defined architectures. If the deployment architecture is not well defined, then the move to Terraform or ARM templates forces your organization to reevaluate segments of its applications in production -- which makes it a great opportunity to review existing architecture.