Bicep - Flexing our Infrastructure as Code muscle

Great State have been using Microsoft technologies for over 20 years, more recently this includes Azure Resource Manager (ARM) templates for the design and creation of infrastructure in Azure. In March 2021, Bicep, a domain specific language for ARM moved out of alpha and immediately came to our attention as the obvious evolution from writing ARM templates.

When looking at new technology I always ask myself what’s wrong with the old way of doing it, what problem are they (Microsoft in this case) trying to solve? The answer in this case is many things. Bicep has been designed to be developer friendly, have day 0 support for any Azure resources, Visual Studio Code linting and autocompletion and more.

Bicep still transpiles to ARM so Microsoft haven’t fundamentally changed how Azure works but being able to describe architecture in a (mostly) human readable way, separating resources into modules is a game changer as far as I’m concerned. To see the transpiled ARM version of a Bicep template, use the Azure CLI tool, az bicep build.

We have embraced Bicep on multiple projects now and the onboarding process for other developers to understand and contribute to the templates has been very easy. With little or no handover, the templates are understandable and written in a familiar way, if you ever write code.

Some of the features that have been most useful for us have been:

String interpolation

Writing ${project}-${env}-${uid} instead of [format('{0}-{1}-{2}', parameters('project'), parameters('env'), parameters('uid'))] is the most simple example to demonstrate how writing Bicep has started to simplify things.

Modules

Much in the same way common programming practices tells us to separate code into different files to logically split application logic, Bicep introduces this same concept to allow for code reuse. We usually create each resource in its own module and call those modules from a ‘main’ script. This means the ‘main’ script is kept short and high level, leaving the logic in each of the modules. Modules can still pass information back to the ‘main’ script using `output`.

This is one of the biggest benefits to our clients as it allows us to reuse modules across projects, saving large amounts of time and money. 

Open source

It’s completely free to use, regularly updated and well documented. Visit the Github page to find out more https://github.com/Azure/bicep.

We generally must maintain multiple environments and much in the same way you can use parameter files in conjunction with ARM templates, you can with Bicep too, the same parameter files/formats in fact! The ease with which to decide to create a resource in Bicep is as simple as adding an if statement. For instance, we tend to add less or no diagnostic settings to non-production environments, this can be setup as follows:

param addDiagnosticSettings bool 

resource diagnosticSettings 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = if(addDiagnosticSettings) {
…
}

Infrastructure automation is proving to be hugely beneficial for our clients. DevOps and Infrastructure as Code (IaC) allow us to reliably create application environments in Azure at pace, consistently.

In summary, there are lots of things to be excited by with Bicep and the above is just a taster. If you’re already using ARM, give Bicep a go, if not and you’re using Azure then describe your infrastructure using Bicep.

If you want to know more, feel free to get in touch for an informal chat with one of our engineers