Defining your Azure infrastructure as code with Bicep

The first thing that comes to mind when you think of Infrastructure-as-Code (IaC) in Azure is Azure Resource Manager (ARM) templates. After all, for every service – regardless of how you deploy it – an ARM template is created in the background.  However, when you think of ARM, you probably also think of JSON files that are difficult to maintain and read. At least that’s what I think.

Microsoft had the same thought as I did. So they launched Project Bicep, a domain specific language (DLS) or mini language. This means that Bicep is designed specifically for declarative development of Azure resources.

Infrastructure-as-Code (IaC)

Before we dive deeper into Bicep, we will first briefly summarize what Infrastructure-as-Code entails. With IaC, you manage an infrastructure – from networks and virtual machines over databases and more – in a descriptive model. The need for Infrastructure-as-Code was born out of the fact that, in the past, everything was set up manually. This meant that often when changes were made to a virtual machine (VM) , whether consciously or unconsciously, nobody knew about it or no one knew what the change was. Or even worse, a service could accidentally be deleted.

When one of the above situations occurs, the power of IaC becomes clear. With the entire environment and infrastructure stored in descriptive files, the responsible people can easily figure out how a service is configured or, if needed redeploy it with the same settings.

An example of its power

Let’s look at a practical example of IaC in the Azure cloud. Using Bicep, you developed an Azure Data Factory and an Azure Data Lake Gen2 and made it so those can communicate with each other. A colleague modifies a service within your environment thinking it won’t have much of an impact. However, the result is that both your deployed services can no longer communicate with each other. Whereas, you’d usually have to spend some time Sherlock Holmes-ing your way to the cause of the problem. The Bicep file can easily fix your problem by by rebuilding your service from the ground up. You just have to deploy the infrastructure as described in the file and suddenly your solution is working again.

What is Bicep exactly?

Azure Bicep is a Domain Specific Language (DSL) that provides a more transparent abstraction of ARM. As such, everything that can be done in an ARM template can also be done in this new DSL. All resource types, API versions, properties, and the like that are valid in ARM are also valid in Bicep. However, you cannot push your Bicep file directly to the Azure cloud. When you finish or modify such a file, you need to build and compile it. The build process will then generate an ARM template for you. Afterwards, you can release this template to your Azure environment through, for example, the Azure command-line interface (CLI).

The difference between ARM and Azure Bicep

As mentioned earlier, ARM templates – because of their JSON code – are often difficult to maintain. Azure Bicep offers a solution to this by allowing you to more easily and drastically extend your Azure environment thanks to its clear syntax and better support for modularity.

In the images, you can clearly see the difference in complexity between the two. Both codes only deploy a single Azure Data Factory.