To make the most of this chapter, you will need to have a basic understanding of Infrastructure as Code (IaC), Azure ARM templates, and the Azure CLI. The code used throughout this chapter is stored in this GitHub repository: https://github.com/PacktPublishing/Infrastructure-as-Code-with-Azure-Bicep/tree/main/Chapter01.

In this section, you will learn Azure Bicep and what it offers to developers and DevOps teams. There will be a few code snippets to get your eyes familiar with the syntax and, finally, an overview of its components and building blocks. But before we begin, let's review some concepts to make sure we are on the same page.

IaC

Currently, many companies try to automate their infrastructure creation and maintenance. To do that, and to further keep track of what is happening or has happened in their environments, they use a set of scripts or code files alongside tools and processes that streamline the whole deployment for them.

This practice is called IaC and helps every team to safely establish and configure the required infrastructure for their applications and solutions. This practice became even more simplified when all cloud providers added the ability for their customers to use it, which in terms of Microsoft is called Azure Resource Manager (ARM) templates.

ARM templates

Microsoft Azure used to have a deployment model called classic, which helped users deal with individual services (called cloud services) using three components: service definition, service configuration, and service package. There is no need to delve into the details of these concepts; suffice to say that soon they realized this approach needed to change if they wanted to allow their users to leverage the full potential of IaC.

That is when ARM was introduced as a new way of deploying cloud services in Azure that supported other tools, such as the Azure portal, the Azure CLI, Azure PowerShell, and all their SDKs. Here is what the new deployment model looks like:

Figure 1.1 – Azure Resource Manager

As you can see, it's a much better-unified model, which allows their customers to deploy their resources using a centralized management layer. In addition to that, Microsoft introduced ARM templates, JavaScript Object Notation (JSON) documents, which would declare what resources are needed to be deployed and what the resource manager will use to deploy them in a group, along with their configuration and other files if needed.

Using ARM templates, developers and DevOps engineers can create repeatable deployments that offer auditability, extensibility, testing, modularity, previews, detailed logs, and a status update on the deployments as resources are getting created or modified.

Azure Bicep

Even though ARM templates are great to begin with, it turns out that JSON is not the ideal format to use, especially when the number of resources is high or the deployment model gets complex with time. So, Microsoft started to work on a project called Bicep as a revision to ARM templates to overcome some of the issues people were facing.

Azure Bicep is a Domain-Specific Language (DSL) that has all the benefits of ARM templates, but instead of using JSON, it uses a new language to overcome its shortcomings. It is designed to simplify the authoring experience of IaC and bring more integration with other tools, such as the Azure CLI and Visual Studio Code.

It is worth mentioning that Azure Bicep files will get transpiled to ARM templates very much like how TypeScript files transpile to JavaScript. This means every type, resource, and property that is valid in an ARM template is valid in Bicep as well. We will not go into the details of what a Bicep file looks like, but to pique your curiosity, here is the famous Hello World! in Bicep language:

param message string
var hello = 'Hello World! - Hi'
output helloWorld string = '${hello} ${message}'

When you compile this file, you will get an ARM template that looks like the following:

{
  „$schema": „https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "dev",
      "templateHash": "14991011523779832704"
    }
  },
  "parameters": {
    "message": {
      "type": "string"
    }
  },
  "functions": [],
  "variables": {
    "hello": "Hello World! - Hi"
  },
  "resources": [],
  "outputs": {
    "helloWorld": {
      "type": "string",
      "value": "[format('{0} {1}', variables('hello'), parameters('message'))]"
    }
  }
}

It is amazing how simplified the Bicep file is, don't you agree? Some of the advantages of Azure Bicep are as follows:

• Support for all current resource providers
• A syntax that simplifies the IaC and can reduce a huge amount of code compared to ARM templates
• No need to manage any state (compared to some third-party tools, such as Terraform)
• Native integration with Microsoft tools, such as the Azure CLI and Visual Studio Code
• A modular structure that allows you to break your code and create your IaC with peace of mind
• Backed up by Microsoft support plans
• Native integration with other Azure resources, such as Azure Policy and Blueprints

Now is the time to delve into why Microsoft felt there was a need to create another revision on ARM templates, which will be covered in this section. In addition, we will have a look at the rationale behind when to use third-party tools such as Pulumi or Terraform, and when to go with Bicep.

Why create a new revision?

ARM templates had some issues that were causing many customers to complain about the usage of JSON and its limitations. The first thing that was causing some pain was the way validation worked in ARM templates. Often, the template validation passed but the deployment would fail.

Another reason was not having to comment in the template, especially if the deployment model was very complex. I am not a fan of commenting in code or any script for that matter, but the lack of commenting, even small comments to deliver a hint to the next maintainer or team member, was not something people were happy about.

And the last valid reason was how parameters would be duplicated for different resources or environments. Given the fact that ARM templates themselves are reusable, this was not ideal and would make maintaining the parameter files a nightmare, although they might contain the same value.

To overcome these issues, Microsoft started to investigate different existing tools and new ways to enhance the functionality of ARM templates and, in the end, they ended up with the Bicep language, with its own syntax.

They mentioned in their GitHub repository that they went through more than 120 customer calls and surveyed their Most Valuable Professionals (MVPs) network, and evaluated and even prototyped a version written in TypeScript, but eventually decided that Bicep should have its own syntax.

And to me, it is a valid reason, since the majority of companies will use DevOps engineers or even cloud enablement teams to implement and maintain the IaC. Many of those people do not have familiarity with programming languages, which means that using a high-level language would incur a learning curve many companies cannot afford. On the other hand, many of those folks know scripting languages and can learn Bicep really fast without too much effort.

What about current third-party tools?

Another question people usually ask is why they can't use current tools, such as Pulumi or Terraform. For Pulumi, I have already explained the barrier of knowing a required programming language and the learning curve that would follow. For those who are comfortable using Terraform or are already using it, there would not be any reason to shift to Bicep at all. Of course, that is whether you are happy to pay the price to use Terraform Cloud when Bicep is a free tool.

In fact, Microsoft has already invested in creating a set of documentation to streamline the learning material in their DevOps site regarding using Terraform on Azure, which can be found at https://azure.microsoft.com/en-au/solutions/devops/terraform.

That said, many organizations – some of which I personally have worked with – are using ARM templates and are looking for a solution with the least overhead to move on. For those people, Bicep works well because they are already familiar with concepts such as built-in functions, types, API versions, and so on.

Furthermore, for those who have not started their journey in IaC, it would be much easier to start with something that has integration with the tools they would use, such as the Azure CLI and Visual Studio Code, with as little learning as possible, keeping in mind that Bicep is now supported by Microsoft support plans.

Now that you know what Bicep is and why it was created, it is time to learn how it works and what it takes to get started with it, which you will learn in this section.

Authoring experience

You can create and use Bicep files with Visual Studio Code using the official Bicep Visual Studio Code extension, which can be found at https://github.com/Azure/bicep/blob/main/docs/installing.md#bicep-vs-code-extension.

Figure 1.2 – Visual Studio Code Bicep extension

This means it really feels like a native experience, with all the bells and whistles of autocorrection, IntelliSense, validation warnings, and so on.

To make it even more exciting, both the Azure CLI and Azure PowerShell have built-in support for Bicep. That means you can compile and deploy a Bicep file just like you were doing with ARM templates. The transpilation happens behind the scenes for you and deployment will run afterward.

To give you an example, with ARM templates you use the az deployment group create command to start a new deployment, like so:

az group deployment create \
 -g myResourceGroup -n myDeployment \
 --template-file ./deploy.json \
 --parameters ./deploy.parameters.json \
 --parameters "sqlSAPassword=$password"

The procedure with Bicep would look very similar, if not identical, since the Azure CLI and PowerShell already support Bicep files as templates:

az deployment group create \
 -g myResourceGroup -n myDeployment \
 --template-file ./main.bicep \
 --parameters @parameters.json 

And you should have your template deployed shortly after the command is successful. This is great, since you can easily use your Bicep files rather than compiling them first and then deploying them using one of these scripting tools, which adds extra time to your deployments and potentially adds unnecessary complexity to your pipeline steps.

What happens to my ARM templates?

If you already have ARM templates you wish to migrate to Bicep, the easiest solution is to use its CLI to decompile your JSON files by running the following command:

az bicep decompile --file azuredeploy.json

We will delve into this in much more detail in our upcoming chapters, but I just wanted to let you know in advance that there is no need to worry about the migration of your ARM templates into Bicep. In fact, since even the deployment commands are the same, there would be minimal changes required to your pipeline scripts.

Warning

As with any other tool, decompilation might result in a scenario where it would result in warnings or errors, which should be resolved by you. The possibility is not that high, but it might happen. One of the reasons might be that you are using copy loops or nested templates.

Bicep CLI

Bicep comes with its own cross-platform CLI, which will then be used by the Azure CLI and Azure PowerShell behind the scenes to compile/decompile Bicep/ARM template files. We will talk about this in much more detail later.

For example, if you wanted to decompile an ARM template to Bicep as we saw before, you would use a script like so:

bicep decompile --file azuredeploy.json

We will review this feature in much more detail later in the book.

In this chapter, we had a lot to discuss, a few concepts to agree on, and a few comparisons to make. You learned what IaC is very briefly, and then I made sure you knew about ARM templates, since that is the whole reason Bicep was created.

That was then followed by what Azure Bicep is, and you learned that it is not a new programming language and is a revision of ARM templates, with its own syntax. You saw why there was a need for creating yet another solution to implement IaC, even though there are plenty of tools, such as Pulumi and Terraform, out there. We talked about the cloud enablers not knowing any programming languages and the learning curve that would be in place if they had to learn a high-level language to do their day-to-day jobs.

Once that was settled, you learned how Bicep works and got to know the tools that can be used to create, compile, and deploy your resources using Bicep. We saw the built-in integration with the Azure CLI and Azure PowerShell, and how Bicep has its own CLI, which makes it easy for you to even decompile an ARM template into a Bicep file.

In the next chapter, we will get started with Bicep by going through how to install it on multiple different platforms.