In previous articles, we’ve been working on deploying solutions using Bicep, the Domain Specific Language (DSL) for deploying Azure resources declaratively.
This article will review three best practices you can adopt when transitioning from ARM templates into Bicep files.
While there’s some familiar syntax in ARM templates and Bicep, I strongly recommend you check the syntax when you need to get resources IDs of a resource or when declaring property values.
Some examples are listed here: https://github.com/Azure/bicep/blob/main/docs/arm2bicep.md
Here’s an example, in a previous article, we reviewed how you could deploy an Azure Machine Learning Workspace and Datastores.
In that Bicep file, while it is recommended to use the latest stable version of the API, there are properties defined in the ARM template that are not available in the Bicep property values, at least not yet.
For those cases, I recommend you verify the properties needed in your resource and how the missing properties impact your environment in Azure.
The good news is that the documentation in Azure for Bicep and ARM templates show, in most cases, the versions supported and the template format:
Similar to ARM templates, you can target your deployment to different scopes depending on the environment.
Having a clear understanding of the hierarchical resource structure with multiple levels of management is critical to managing your deployments better. These include Tenants, Management Groups, Subscriptions, and Resource Groups.
Think of a scenario where you have an Azure Tenant with two Management groups and two subscriptions under each Management Group. You need to deploy a different set of resources depending on the environment type like Production or Testing with virtual networks, DNS, App Services, VMs, etc.
When you fully understand the various levels of the hierarchy, you can apply flexible controls on how your Azure environment is managed using Bicep.
For example, you should target a Subscription when you need to create multiple resource groups and grant access to all resources within a subscription.
You can target a Management group when you need to provide access to all the resources in a specific subscription.
You could target a Tenant in the case you need to create multiple subscriptions.
Also, think of modularization, for example, a Bicep file that defines a virtual network could be consumed as a module and be deployed across multiple subscriptions.
A single set of Bicep files can be used to deploy resources across multiple scopes in a single operation.