Thoughts on Azure Bicep

In my continueing efforts to learn on paper, I took a few minutes this morning to explore the differences between Bicep and a few other Infrastructure as Code tools I’ve worked with. Again, this isn’t a formal bit of writing, just some thoughts on paper inspired by a discussion from last week’s Modern Data Platform discussion and meeting.

TLDR; I look at Bicep and compare its promise to my own past experience with IaC and decide that moving forward it’s definitely the IaC direction that I want to take.

Bicep is Microsoft’s newest answer to Infrastructure as Code on Azure. Bicep isn’t a replacement for ARM, but a DSL (Domain Specific Language) that helps developers build ARM templates quicker and easier. There are multiple ways to create IaC for Azure, including Powershell, the Azure CLI, and Azure SDKs, but in one way or another all of these use Azure’s API and ARM in some capacity. A number of MVPs have created an impressive array of “Best Practices,” templates and put these out in the world for the rest of us to use, like Azure Quick Templates – https://azure.microsoft.com/en-us/resources/templates/?WT.mc_id=appsonazure-techcommunity-juyoo . However, we as developer rarely use a template out of the box. We normally launch our favorite editor and start hacking away at the templates, which can be a problem if you for a brace, bracket, or comma. Bicep hopes to reduce some of this frustration.

But what about existing IaC solutions like Terraform? Terraform has a lot of support built into Azure. It even has its own section on Azure docs – https://docs.microsoft.com/en-us/azure/developer/terraform/. It’s open source and has a support for many Azure cloud native services https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs. It’s presently one of the most popular ways to work with IaC on the market. It’s definitely not a bad solution.

If I were a DevOps engineer or a solutions developer who exclusively worked with Azure, I would definitely consider investing in Bicep over other solutions for some of the project’s stated goals (https://github.com/Azure/bicep) – my comments in italics:

• Best possible language for describing, validating, and deploying infrastructure to Azure—very domain specific, so no overhead for AWS and GCP here
• The language should provide a Transparent Abstraction for the underlying platform. There must be no “onboarding step” to enable it to new a resource type and or apiVersion in Bicep. I believe this means Day 0 support. If it’s in Azure GA, you can create it.
• Code should be easy to learn and understand at a glance. It looks a lot like JavaScript to me, which is great. These days I prefer Python, but I can live with something that is more like JavaScript than anything that is like YAML.
• Code reuse – Woot! No more copying and pasting ARM template bits parts to build large infrastructure.
• Resource discoverability and validation – how about a drop down of available VM sizes for your specific region? Yeah, I think that’s what they’re talking about here. Validation should also stop me from attempting to do things like attempting to create a private storage account without a VNET or the new private endpoints.
• Syntactically valid code – I hope this means linting support and some type of local tests that can run in the deployment pipeline. That would be awesome.

With Terraform, I could face a delay for new Azure services and functionality. Not a big deal for many engineers working in mature environments that aren’t interested in the latest and greatest, but for some of us who are creating the newest thing the moment it hits preview, this is a godsend.

I love having better validation. I’ll admit it, I’m a sloppy coder sometimes. I miss things. Import things. Like regions. Oh, I’ll have every tag any department has ever asked for, but I’ll put it in the wrong region or even completely forget the region. Having this type of support will be great. I’m not sure how much of this you get from Terraform. Pulumi actually has a really nice test process that it goes through and catches some of these issues, but I have had it pass my test phase, but still cause a corrupted deployment. Granted, it was in Databricks and I had set up something wrong, but it wasn’t the validation experience I was hoping for.

Which leads me to developer tools. Like many of you, my favorite development environment these days is VS Code. Code has great support for ARM templates, but it’s still not easy to work with. Having a healthy set of Bicep extensions and seeing the community embrace and add to these extensions will be something worth looking forward to.

What about system state? I know with Pulumi and with Terraform I need to have some sort of state file that represent the current state of the environment. I haven’t actually seen any documentation that discusses state, but I didn’t see anything in the set up process for development that mentioned needing a state file. So it’s possible that Azure is the state (which kind of makes sense,) or it’s hidden somewhere inside Azure, like the Azure Resource Manager. Please feel free to add a comment pointing me to this information if you know it.

Both Bicep and Terraform appear to have Modules, but they are different. Terraform modules are more about grouping similar items together for reuse. Let’s say that I regularly create a resource group that includes Azure ML, and Data Lake G2, Azure Data Factory, and a Cosmos DB. A Terraform module could group all those things together for a single deployment—big maybe here, because I’ve never attempted that particular configuration in Terraform. A Bicep module appears to be more like a programmer’s concept of a module. It’s an abstraction meant for reuse. Bicep has a single file module, which looks to me like a single file written to represent a single resource. Like I might make a file called, az-rg-data-science-cosmos.bicep to hold me Cosmos DB. It also has a concept called Directory-based Module, which looks a lot more like Terraform’s definition of a module. This is just a directory of bicep files meant to represent a larger collection of resources.

I’m really just scratching the surface here for what’s possible in Bicep. It’s still in its early stages of development and I’m ready to ditch all my other tools to focus on Bicep. When you are like me and you only work in one cloud environment, using a general cloud tool like Terraform doesn’t necessarily make sense.