Share:

Has ARM reached its peak of potential and is it now time to say hello Bicep?

Over the past few years, we have seen an abundance of new languages including; Elixir, Go & Dart. But which tool is worth investing our time in?  By mid 2020, the emergence of a new language “Bicep” from Microsoft emerged as an optional replacement for “ARM”. In this article, I will be defining what exactly ARM and Bicep is, I will then demonstrate the similarities and differences between Bicep, ARM and Terraform. I will then discuss whether Bicep has the potential to be successful. 

So what exactly is ARM?

When working with Microsoft Azure Cloud you must create Azure resources. In 2014 Microsoft introduced Azure Resource Manager (ARM), a cheaper and faster way to deploy azure resources via  templates. You can utilise this tool by adopting the Azure Portal, Azure CLI, Azure PowerShell, and by using SDKs.

Introducing Bicep

Bicep is an infrastructure as code  that uses declarative syntax to deploy Azure resources. Within the Bicep file, you define the infrastructure you want to deploy to Azure such as virtual machines and then repeatedly use this file throughout the development lifecycle. (mumian, n.d.)

So how does ARM differ from Bicep?

Everything done with an ARM template can also be done with Bicep, which immediately supports a new resource added to Azure. ARM and Bicep allow you to carry out the same task however, when you start working with ARM templates, you quickly realise that it has quite a few drawbacks. Here is an example: 

Below you can see two templates for creating a storage account, one written in ARM and one written in Bicep. The first noticeable difference is that the bicep template is only half the size of that of ARM. Firstly, the parameters are more compact as the type, name, and default value can all be written in a single line. Secondly, Bicep is smart enough to determine if resources depend on each other.

Nested ARM templates can grow to become quite complex, therefore  a team that perhaps is not so experienced with ARM may opt for using Bicep instead. Just like any other programming language you will still have the template functions, the same resource declarations, properties, outputs, and the ability to modularize templates, however the learning rate will be reduced with its friendly to read and implement syntax. 

BICEP Syntax 

param location string = resourceGroup().location
param storageAccountName string = ‘toylaunch${uniqueString(resourceGroup().id)}’
resource storageAccount ‘Microsoft.Storage/storageAccounts@2021-06-01’ = {
  name: storageAccountName
  location: location
  sku: {
    name: ‘Standard_LRS’
  }
  kind: ‘StorageV2’
  properties: {
    accessTier: ‘Hot’
  }
  }

 

ARM Syntax 

JSONCopy

{

  “$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#“,

  “contentVersion”: “1.0.0.0”,

  “parameters”: {

    “location”: {

      “type”: “string”,

      “defaultValue”: “[resourceGroup().location]”

    },

    “storageAccountName”: {

      “type”: “string”,

      “defaultValue”: “[format(‘toylaunch{0}’, uniqueString(resourceGroup().id))]”

    }

  },

  “resources”: [

    {

      “type”: “Microsoft.Storage/storageAccounts”,

      “apiVersion”: “2021-06-01”,

      “name”: “[parameters(‘storageAccountName’)]”,

      “location”: “[parameters(‘location’)]”,

      “sku”: {

        “name”: “Standard_LRS”

      },

      “kind”: “StorageV2”,

      “properties”: {

        “accessTier”: “Hot”

      }

    }

  ]

}

 

When would you use BICEP?

Terraform VS Bicep

Bicep syntax looks quite similar to the Hashicorp language “Terraform” but there are some parts that make it unique. The first area that a typical Terraform user may look into is the state file and backend. In Terraform, the state is stored in a local file named terraform.tfstate, but it can also be stored remotely. Like Terraform, Bicep is declarative and goal-seeking. However, Bicep doesn’t store state, instead, it relies on an incremental deployment. This offers endless benefits such as reducing the accumulation of technical debt because it becomes easier to observe the changes that have been deployed as opposed to one big chunk of code that would need debugging. 

Another factor to consider is that Azure works with a variety of environments whereas Bicep works directly and only with Azure. Terraform interacts with other cloud providers or APIs using plugins called providers. Since Bicep works directly with Azure it makes it simpler and more efficient to work with. 

There are some essential differences between Bicep and Terraform in terms of efficiency and  deployment optimization. With Bicep, processing occurs within the core Azure infrastructure service side. This feature offers advantages such as preflight processing to check policy or the availability for deploying multiple instances within a region. 

With Terraform, the processing is done within the Terraform client. Thus, pre-processing involves no calls to Azure since it uses state and HCL (HashiCorp Language) to determine the required changes.

Now, does Bicep have the potential?

  1. Provides support for all resource types and API versions: Bicep immediately supports all previews and GA versions for Azure services. Newly introduced resource types and API versions can be used immediately  in your Bicep file,you don’t have to wait for tools to be updated to use new services.
  2. Simple syntax: Bicep requires no previous knowledge of programming languages. Bicep syntax is easy to read and pick up. 
  3. Repeatable results: You can deploy the same file as often as you like and get the same resource types in the same state. 
  4. Integration with Azure services: Bicep is integrated with Azure services such as Azure Policy, template specs and Blueprints.
  5. No state or state files to manage: All state is stored in Azure. Users can collaborate and have confidence that their updates are handled as expected.
  6. No cost and open source: Bicep is supported by Microsoft and is completely free,you don’t have to pay for premium capabilities. .
  7. No multi cloud options: It is almost impossible to use Bicep if you’re using multiple cloud providers and need a consistent programming language across all cloud providers.

In conclusion, Bicep is an easier tool to implement and from which to deploy Azure resources directly, it is cleaner than ARM and unlike Terraform, it does not require a state file or backend to store the statefile.

Reference 

mumian (n.d.). Bicep language for deploying Azure resources – Azure Resource Manager. [online] learn.microsoft.com. Available at: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview?tabs=bicep [Accessed 24 Oct. 2022].