Organizations strive for automated and consistent cloud deployments, allowing workloads to be rapidly provisioned and de-provisioned while adhering to best practices for cost management and security. This need has led organizations to adopt Infrastructure as Code (IaC) as the preferred method for deploying cloud resources. Several years ago, Microsoft introduced ARM templates as the coding language for provisioning resources through IaC. However, Azure ARM templates come with their own set of challenges, including code complexity, lack of modularity, and a less-than-ideal authoring experience, making the creation of ARM templates difficult.
Microsoft’s Bicep ProjectMicrosoft announced the 0.1 version of the Bicep Project to address these challenges in 2020. Bicep was developed to overcome the issues users faced when working with ARM templates, offering a more streamlined and user-friendly approach to infrastructure coding. As a transparent layer over Azure ARM, Bicep enhances functionality and simplifies the user experience with a much simpler code declaration.
The Diagram illustrates how the bicep code is decompiled in ARM template and how the resources are deployed in Azure.
Azure Bicep is not an entirely new language; However, it operates as an abstraction layer over Azure ARM and ARM templates. The current version, Azure Bicep 0.3, is the latest release and is stable for use. Any workload that can be managed with Azure ARM can also be efficiently handled with Azure Bicep.
Challenges with Azure ARM TemplatesA lot of Noise was involved with JSON as well as extra commas and semi-colons, making it hard to read for a user. Also, the deployments could not be divided into different modules for their reusability in different deployments.
The important features of BicepNo State File Management – Deployment templates are saved in the cloud which helps in collaboration between different teams. When the Bicep templates are saved in GitHub, it allows you to manage the state of the infra from anywhere and in case of any catastrophe or resource failure, we will still have the deployment available.
Modularity - Bicep codes can be divided into different parts and then can be reused for other resource deployment. For example, a Module to create the virtual network can be used while creating a Virtual Machine and can also be used while creating an application gateway and any other Azure service that uses virtual network. This saves time in creating each resource each time.
Authoring Experience - The inbuilt Bicep Extension along with Visual Studio provides IntelliSense, Tab Completion, Language Server. All these help writing a code in Bicep much simpler increasing the code writing experience with higher accuracy.
The below picture depicts the comparison between Bicep and Azure ARM. We can see that Bicep makes it easier for cloud enthusiasts to declare the resources in a much simpler way.
Microsoft Support - Bicep is CLI integrated with AZ cli and PS Cli, and will compile the bicep files automatically, supported by Microsoft plans. The support team can help in debugging the codes in case of any issues.
Every single Resource is available on Day Zero with all the API support.
No cost and open source- Bicep is completely free. You don't have to pay for premium capabilities. It's also supported by Microsoft support.
Azure Bicep’s code is decompiled into a JSON file standard to Azure ARM. This functionality treats Azure ARM as an intermediary language. While the language syntax for Azure Bicep is different from Azure ARM, the core functionalities of Azure ARM templates remain the same. The resource declarations and template functions are also the same.
The existing ARM templates can easily be compiled into the Bicep files and can be used to deploy the infrastructure as code. Also, the existing resources in Azure can be imported into Bicep Modules making it much simpler to manage the infrastructure.
Single Line Array Declaration: In many scenarios, we will have to use an array to create multiple resources, in which case you would have passed an array parameter (that is, [‘a', ‘b', ‘c']). You cannot have the same in Bicep, you would require mentioning the values in separate lines:
‘Basic'
‘Standard'
‘Premium'
]
Key Vault Secret Creation: For the resources that require a secret to be created to grant access on the resource (SQL server, VM) in the ARM template we had the function to create the secret in the key vault which can then be used to attach with the resource. This way there is no hard-coded secret which is provided during the resource deployment. Also, a single deployment creates the secret in the key vault and attaches with the resource. Currently, Bicep Deployment doesn't have this functionality and the secret needs to be created before the resource creation.
| Azure ARM | Bicep | Terraform | |
|---|---|---|---|
| Provider Support: | Primarily used for provisioning resources in Microsoft Azure. It doesn’t support any other cloud services. | Primarily used for provisioning resources in Microsoft Azure. It doesn’t support any other cloud services. | Supports multiple cloud providers including Azure, AWS, Google Cloud, as well as various on-premises and third-party services. |
| Language and Syntax: | It uses JSON (JavaScript Object Notation) for defining infrastructure resources. JSON is a verbose language, which can make templates more complex and harder to read. | Bicep aims to reduce complexity with a cleaner and more understandable syntax compared to ARM templates. Bicep is transpiled into standard ARM templates ensuring compatibility and consistency. | IT is a more human-readable and concise language specifically designed for infrastructure provisioning. This makes Terraform code easier to write and maintain. |
| Resource declaration: | Defines resources explicitly and often requires a deep understanding of the Azure Resource Defines resources explicitly and often requires a deep understanding of the Azure Resource | Defines resources explicitly and often requires a deep understanding of the Azure Resource decide the order of deployment. | Uses a declarative approach where you specify the desired end state and Terraform figures out the actions required to reach that state. This can make it easier for users to describe their infrastructure intent. |
| Complexity: | Can become complex and hard to manage for large and intricate infrastructures. | Bicep is an abstract layer on complex Json templates of ARM template. Also, it doesn’t require Providers as it is a DSL. This Makes Bicep code much simpler to read and work with. | Offers better modularity and organization through modules, which can help manage complexity. |
| State management: | Azure ARM templates do not have a built-in state management system. | The complete state is stored in Azure Deployments. This saves the complexity of managing the state file | Terraform uses a state file to keep track of the current state of deployed resources. |
| Idempotency: | Not inherently idempotent. Repeated deployments can be problematic without careful design. | Bicep is idempotent. This allows you to run the same command repeatedly and this will add/modify/do nothing as appropriate. | Designed with idempotency in mind. Repeated executions of Terraform plans typically do not result in unintended changes to infrastructure. |
| Modularity: | Azure ARM Templates do not have the modularization of infrastructure code. | Bicep allows you to break your code into manageable parts which are called modules. Modules enable you to reuse code and simplify development. Add the module to a bicep file anytime you need to deploy those resources. | Terraform allows for modularization of infrastructure code using modules. |
| Support and Cost: | Azure ARM is completely free and is completely supported by Microsoft. | Bicep is completely free and is completely supported by Microsoft. | The basic tier of terraform is free which has a limitation of 500 resources. For a large environment customer need to purchase the terraform support plan. |
The selection of the ‘Infrastructure as a code’ tool largely depends on the specific needs and environment. If the requirement is in a context of a multi-cloud environment with a broad ecosystem and mature features, then Terraform is the right fit for the environment.
However, if your cloud strategy is to leverage Microsoft Azure and you prefer a tool which is tightly integrated with Azure, then Bicep is a great option as it has a day-one integration available for all the Azure resources. It also has complete Microsoft Support.
Bicep gives you a kick-start with the language as you can import the existing Azure resources in Arm Template and then subsequently compile them into Bicep Template, using visual studio code. Also, as it has no state file management and there is no pre-integration required with Azure tenant to start deploying the resource.
To learn more about Coforge’s cloud services, please visit
https://www.coforge.com/what-we-do/capabilities/cloud-services