Bicep — Sustainable Coding!

There is no doubt that ARM is extremely powerful; GitHub is filled with thousands and thousands of samples everyone can reuse and also contribute to. Despite the power of ARM, the complexity of coding with JSON can be very tedious. Still, you need to build up quite some experience to become a seasoned ARM Templates developer.

JSON: Is never meant to be human-readable!

This blog post is not to challenge your minds to quit famous InfraAsCode deployment tools (e.g. Terraform), but to motivate you smoothly get your hands out of JSON into the Bicep universe.

No deep dive is provided for now, but this could be the case in a future post.

Project Bicep — Forge Infra to Code!

Concepts to understand at first

It doesn’t matter how you interact with Azure Cloud, from the APIs, Portal, PowerShell, AZ-CLI; all will definitely go through “Azure Resource Manager”, a consistent management layer that ensures having a similar overall experience governed by the same policies.

Bicep is that additional layer on top of ARM, that reduces the pain of dealing with JSON unless it is really unavoidable.

Project Bicep — Simplify the coding process

Bicep was proposed in 2019 as Microsoft’s “Domain-Specific Language”, with a focus on reducing complexity and making the code better sustainable; Optimizing the coding experience with less code to write and maintain.

Bicep — For a Cleaner Syntax

ARM and JSON are still around; If you use Bicep properly you’ll never see those JSON templates again 🙏

The Resource Manager is still working with ARM templates. Bicep is added in front of the ARM-Templates, which means we can now start coding using Bicep configuration files; But then, we need to compile the Bicep configuration files into ARM templates; the rest of the process remains unchanged, as illustrated below.

Bicep-The Playground

Easily you can start playing with Bicep without any need of having it installed locally (Redirect to the playground!)

Bicep Playground takes some long seconds to load! Be patient ;)

Bicep — Tools

To start coding Bicep locally, some tools are required, which are around:

• The so-called Bicep-CLI: Available in both the Standalone and Az-Cli integrated versions. The latter is the one recommended by Microsoft. It allows directly deploying the Bicep file to Azure without even recognizing that an ARM template has been created in the backend.
• And an optional Visual Studio Code extension to assist in creating, validating, and Linting Bicep code (with an Auto-Complete feature).

Microsoft is only providing support for the version V0.4 of Bicep CLI, which is published as Prod-Ready tooling.

Visual Studio Code — Bicep Extension

Bicep tools installed? We’re ready to start authoring the first .bicep files.

Bicep Reverse Engineering

The Bicep-Cli does compile “Bicep Config Files” to “ARM-Template”, decompiles existing “ARM-Templates,” and modernizes them to “Bicep Config”. The latter is a great feature as it assists in modernizing the existing code with less effort/costs and thus drastically reduces the risk of technical-dept.

To minimize the Technical-Dept as you are moving towards Bicep, it’s so useful to convert existing ARM Templates to Bicep Config using:

az bicep decompile --file deploy-aks.json

Do not expect to have a fully-working version of a Bicep Config file for complex and linked ARM Templates. However, errors and warnings would assist you in doing the right adaptations.

Bicep — In Action

Let’s get back to practice, and exercise compiling JSON-based templates first! Bicep files need to be compiled first before firing the deployment against Azure.

We’ll be deploying an Azure Log Analytics workspace. To have the latter created, open Visual Studio Code and create a file called “bicep.main”. Start typing “res-log” to trigger the auto-complete capability and finally create a basic definition of a Log Analytics Workspace (LAW):

resource law ‘Microsoft.OperationalInsights/workspaces@2020-10-01' = {
  name: ‘name’
  location: resourceGroup().location
  properties: {
    sku: {
      name: ‘Free’
    }
  }
}

The extension ‘Bicep’ for VSCode did assist you in auto-completing the code, especially defining which properties are needed and the resource types to be appended. The tricky date-based API versioning is also filled automatically; Such as ‘Microsoft.OperationalInsights/workspaces@2020–10–01’.

Let’s try adjusting the generated code to our willingness, by adding dynamic parameters:

targetScope = 'resourceGroup'
@description('Required. The Resource Prefix')
param resourcePrefix string = 'business'
@description('Required. The Resource Purpose')
param resourcePurpose string
resource law 'Microsoft.OperationalInsights/workspaces@2020-10-01'= {
  name: '${resourcePrefix}-${resourcePurpose}'
  location: resourceGroup().location
  properties: {
    sku: {
      name: 'Free'
    }
  }
}

The friendly name, “law,” is used as a resource identifier within the Bicep Template (It is not the name of the Resource to create on Azure). This bicep resource identifier could be used to reference Bicep Resources within modules and templates, define dependencies, and more.

Build/Deploy

At this stage we can already deploy our code with a ResourceGroup scope:

az group create -n rg-spoke-we-001 -l westeurope
az deployment group create \
  -g rg-spoke-we-001 \
  -f main.bicep \
  -p resourcePrefix=core \
  -p resourcePurpose=backend

Cleanup!

Don’t forget to clean up the resource with the below command:

az resource delete -g rg-spoke-we-001 -n ata2021bicepdiskstorage --resource-type "Microsoft.OperationalInsights/workspaces"

Start small, think big!