Azure Bicep

What is Bicep?

For the purpose of expressing Azure Resource Manager (ARM) templates, Azure Bicep is a declarative domain-specific language (DSL). In essence, it provides a more condensed and accessible definition of your Azure infrastructure as code (IaC). The ARM templates, which are JSON files that specify the resources you want to deploy on Azure, may be made more easily with Bicep.

While ARM templates have been used for managing Azure resources for many years, they have some limitations, such as complex and verbose syntax, making them challenging to write, understand, and maintain. Azure Bicep was developed to address these pain points and to provide several key advantages.

Why Bicep?

The Azure infrastructure and configuration can be declaratively defined using ARM templates, which are JSON documents. The ARM template language provides built-in functions as well as additional language structures like loops that help us define more dynamic infrastructure. However, because we must only use the JSON statistics representation that is supported, the JSON syntax for ARM templates makes the files rather bulky and limits expansion.

• Our ARM template becomes nearly unreadable and challenging to maintain as the infrastructure's complexity rises. There are options for deploying an ARM template. especially Pulumi SDK or HashiCorp Terraform. These tools offer alternative methods for outlining our infrastructure as code instead of using ARM templates.
• It is challenging to keep the template up to date because of the infrastructure's complexity. The template can be applied in additional ways. especially the HashiCorp Terraform or the Pulumi SDK. These tools provide alternative approaches to define our infrastructure as code rather than using templates.

A Bicep file differs from a template that functions similarly. Two instances of deploying a storage account are given. The differences between an Azure Bicep file and its equivalent JSON template are shown in the examples that follow. A storage account was set up in both instances.

To develop a reusable Bicep file that can generate an ARM template to provision an Azure storage account, you need the 26 traces in the example above. Compiling this results in the creation of a big ARM template.

The size of the resulting template is almost twice that of the Bicep file. The crucial parameter values can be supplied as additional JSON or at the command line when using Azure CLI or Azure PowerShell to install this ARM template.

This is a case where it demonstrates the freedom we have when using this language on its own to produce ARM templates. Bicep now offers a mechanism to compose our Azure infrastructure specifications as smaller, reusable modules in addition to the language's basic building blocks.

Benefits of Bicep

Azure Biceps provide the following benefits:

• Support for all resource types and API versions: All preview and general availability (GA) versions of Azure services are automatically supported by Bicep, as are all resource types and API versions. You can use new resource types and API versions as soon as a resource provider makes them available in your Bicep file. The upgraded tools are not required before using the new services.
• Simple syntax: Bicep files are shorter and simpler to understand than the corresponding JSON template. Bicep doesn't require any prior programming language expertise. Declarative Bicep syntax allows you to specify which resources and resource characteristics to deploy.
• Efficiency: Bicep simplifies the process of defining and deploying Azure resources, reducing the time and effort required for infrastructure management.
• Error Reduction: Its concise and human-readable syntax minimizes the potential for errors in code, leading to more reliable deployments.

Get started with Bicep

To begin using Azure Bicep, take the following actions:

• Set up your local development environment with the Bicep CLI tool.
• To define your infrastructure, create a new.bicep file.
• To define Azure resources and specify their attributes and dependencies, write Bicep code.
• To create the Azure Resource Manager templates from your Bicep files, use the Bicep CLI.
• Utilising PowerShell, Azure CLI, or other Azure deployment tools, deploy your infrastructure.

How does Bicep work?

A Domain Specific Language (DSL) for declarative Azure resource deployment is called Bicep. Through enhanced type safety, stronger support for modularity and code reuse, and a cleaner syntax, it seeks to significantly ease the authoring process. Anything that can be done in an ARM Template can also be done in Bicep, as it is a transparent abstraction over ARM and ARM templates (except from brief, known limits). Every resource type, apiVersion, and property that is accepted in an ARM template is also accepted from the outset in Bicep.

The ARM Template is essentially treated as an Intermediate Language (IL) when Bicep code is transpiled to normal ARM Template JSON files. First, use the Bicep language service included in the Bicep VS Code extension to create your Bicep code.

Bicep functionality is integrated into both the PowerShell Az module (v5.6.0+) and the Az CLI (2.20.0+). This implies that the tools will transpile the code and submit it to ARM on your behalf if you use the usual deployment instructions with your *.bicep files. For example, to deploy main.bicep to a resource group my-rg, we can use the CLI command we are already used to:

You can read the migrating from ARM => Bicep manual for further information on how to take advantage of new Bicep constructs that replace an equivalent from ARM Templates.

Known limitations

• The bicep is sensitive to new lines. Azure is investigating methods to get rid of or lessen this restriction.
• The idea of apiProfile, which maps a single apiProfile to a predetermined apiVersion for each resource type, is not supported. Azure is trying to provide support for this kind of capacity, and anticipate that it will operate a little bit differently.