When to use Microsoft’s Azure Bicep?

Infrastructure as code (IaC) is vital to set up and maintain modern infrastructure as the complexity grows. But you might have experienced the fact that, due to the large number of IaC tools, it can be difficult to find the most suitable IaC tool for the right situation. At Gluo, we wanted to find out whether the cloud native IaC tool from Microsoft Azure named Bicep, when it comes to Azure infrastructure, has the potential to replace the tool that is currently mainly used, called Terraform. Through this research, we could find out whether there are better or more efficient tools available on the market to always provide the best services to our customers.

Terraform is a well-known IaC tool, it is cloud-agnostic which means that it supports almost every cloud platform. (Microsoft Azure, Amazon Web Services, Google Cloud Platform, etc.) In addition, there are also cloud-native tools that were developed by the platform itself which in most cases means better support for the latest services, but do not support other platforms.

In this blogpost we are going to focus on Azure Bicep (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/overview) with some references to other tools. Bicep is the cloud native IaC variant of Microsoft Azure. It is an extension to the existing Azure Resource Manager (ARM) templates which means that when running a Bicep file, an ARM template is generated which in turn is used to create the Azure resources.

Like Terraform, Azure Bicep makes it possible to make use of module. The use of modules

ensures that in larger projects the readability and the modularity increases. The latter means that if a specific part must be set up several times with different parameters, this can be done by requesting the module several times in the main program and supplying the necessary parameters.

When we look for the best code editor, we can establish that Visual Studio Code takes the win. Due to Bicep also being developed by Microsoft, the integration with vscode using the Azure Bicep extension is great.

What makes the tool especially nice when using Azure infrastructure, is the fact that the latest and greatest Azure cloud features are almost immediately available to define in code. There is no need to wait for an update of a provider like in Terraform.

One of the main reasons to use IaC is to reduce the risk of configuration drift, also known as environment drift in the infrastructure world. Over time, each environment becomes unique, and it cannot be reproduced automatically. These inconsistencies between environments can result in issues at deployment when developing applications. Bicep checks if the effective infrastructure deviates from the desired infrastructure and makes changes accordingly.

After experiencing some pipeline performance issues using other IaC tools like CDK for Terraform and Pulumi we can say with confidence that Azure Bicep has very low resource usage as the pipeline only copies the Bicep template to Microsoft Azure and the cloud provider does the rest.

Debugging is also improved as every time you run the bicep command a pre-flight validation is run before trying to apply the infrastructure. This way, code issues can be noticed more quickly.

Azure bicep in comparison with Terraform does not make use of a state file. Instead, it only checks with the current Azure infrastructure. This is on one hand an advantage, because no sensitive information can be leaked through these files. But on the other hand, this also means that only Azure resources can be defined in a declarative way, causing the tool to be very limited in handling non-Azure resources. Even when doing simple tasks such as generating a random password, which would be very easy in Terraform, can in Bicep only be done using Powershell scripts.

Lastly, when using Bicep and setting up multiple environments we would recommend splitting them up into different resource groups as Bicep has, as of this moment, no possibility to remove the infrastructure aside from deleting the resource group. It is also advised to run the Bicep command in ‘complete’ mode, as this will remove any obsolete resources from the resource group when changing something of the infrastructure.

Conclusion

It is important to understand that there is no single infrastructure as code tool that is best for every situation. We would recommend Azure Bicep when the infrastructure setup is limited to Azure resources. But even when the amount of non-Azure resources such as generating a random password is limited, Bicep is still a good choice. Bicep offers a readable and easy-to-learn syntax, which means that when there is no knowledge of any IaC tool, the learning curve for Bicep is very low.