Azure | Lift your ARM with Bicep
If you’ve ever spent time deploying resources to the Azure platform, you’ve probably encountered ARM templates in some way. They get the job done without requiring you to think of state management, but they can be quite challenging to work with. Especially for beginners.
This is in my opinion mostly due to the syntax and verbosity of an ARM template, which is written in JSON following a specific schema. The error messages can be quite undescriptive, making them difficult to debug.
When we started configuring our cloud infrastructure we wanted to configure it as Infrastructure as Code from the get-go.
We looked at several of the more popular tools for the job, such as Terraform and Pulumi. Ultimately we decided that while they are great tools they gave us way more than we needed. But we still didn’t want to deal with the difficulties of ARM templates.
Enter Bicep
Then one of us stumbled over Bicep which had recently been made available by Microsoft. This domain-specific language lets us declaratively configure new resources with all the upsides of ARM templates, but without the verbosity and complexity. It even had good IntelliSense-support through VS Code.
Bicep does not really introduce any new technology but is rather an abstraction over ARM. Meaning Bicep supports everything an ARM template can do.
It’s actually transpiled to an ARM template on deployment, a process that can be reversed if you wish to see how you can express ARM as Bicep.
Bicep in production
We started using Bicep everywhere and were quite happy with the results. Of course, there were some issues related to the relative youth of the language, but these were overcome.
The language turned out to be easy enough that everyone in our team was able to pick it up relatively fast.
We started defining modules for commonly used resources that we could reuse across services to get the infrastructure up and running in no time.
This turned out to be somewhat of a challenge, especially when it comes to versioning as each module had to be copied into place when used. Thankfully a solution for this is in preview which lets you create a private registry, similar to a container registry, where you can upload and use your modules.
Below you can see an example of one of our most common modules.
This module deploys a function app running .NET 6 on Linux.
You can see a lot of similarities between ARM and Bicep, but Bicep is cleaner and not as verbose.
It also gives you the option to let the engine handle things such as defining the dependency graph. Notice that there is no section defining dependsOn as we see in the ARM template.
While the resources and functionality are the same if you’re using ARM or Bicep, it’s clear that Bicep is an upgrade in terms of developer experience.
Curious about working in Elaway? Read more and check out our positions at https://career.elaway.io/
