AzureFunBytes Reminder - Intro to @BicepLang with @adotfrank - 7/8/2021

AzureFunBytes is a weekly opportunity to learn more about the fundamentals and foundations that make up Azure. It's a chance for me to understand more about what people across the Azure organization do and how they do it. Every week we get together at 11 AM Pacific on Microsoft LearnTV and learn more about Azure.

When: July 8, 2021 11 AM Pacific / 2 PM Eastern
Where: Microsoft LearnTV

This week on AzureFunBytes we flex some Azure muscle with Bicep. Bicep is a language that allows you to use a declarative syntax to codify your Azure infrastructure deployments. Bicep is an Azure native Domain-Specific Language (DSL) that promotes a cleaner syntax, improved type safety, and better support for modularity and re-use of code. Bicep is a transparent abstraction over Azure Resource Manager (ARM) templates that gives you the ability to create nearly any required resource within Azure. Bicep has a playground that allows you to start using existing ARM Template Quickstarts right away. Or if you choose to build them from scratch, the snippets with the VS Code Bicep extension will be a huge help.

I was lucky enough to get one of the experts on Bicep to join us this week! We'll welcome Microsoft Program Manager Alex Frankel to the show to give us greater insight into how to use Bicep to create our infrastructure. I'll ask Alex your questions, we'll look at some Bicep basics, discuss best practices, and even kick off some deployments. Don't miss this incredible opportunity to learn about building your Infrastructure as Code (IAC) with Bicep!

Our Agenda:

Why we are investing in bicep in the first place

ARM Templates are by far the most popular declarative tool for deploying to Azure, want to improve experience for those customers
Clarify that Bicep is just one of many great options

Key differences between Bicep and ARM templates

Modules, richer intellisense, auto DependsOn, richer type safety

How the language is designed and the importance of tooling

In terms of language design (not complexity), Bicep shares more DNA with C# and TypeScript than traditional “scripting” languages like HCL or Chef
Tooling is built alongside the language, so our syntax decisions are always driven by our ability to build tooling to go with it

Benefits of being “Azure native”

Day zero support for all resource types
No state management without losing the ability to perform what-if (“tf plan” equivalent) and manage lifecycle (“tf destroy” equivalent)
Works with other platform capabilities like Template Specs, Azure Marketplace, etc.

Full details of how the Bicep language works can be found in the [Bicep documentation] and there is a rich library of examples to help you get a jumpstart.

To get going with Bicep:

Start by installing the tooling.

Complete the Bicep tutorial

Alternatively, you can try the Bicep Playground or use the VS Code Devcontainer/Codespaces repo to get a preconfigured environment.

If you have an existing ARM Template or set of resources that you would like to convert to .bicep format, see Decompiling an ARM Template.

Full details of how the bicep language works can be found in the Bicep documentation and there is a rich library of examples to help you get a jumpstart.

How does Bicep work?

First, author your Bicep code using the Bicep language service as part of the Bicep VS Code extension

Both Az CLI (2.20.0+) and the PowerShell Az module (v5.6.0+) have Bicep support built-in. This means you can use the standard deployment commands with your *.bicep files and the tooling will transpile the code and send it to ARM on your behalf. For example, to deploy main.bicep to a resource group my-rg, we can use the CLI command we are already used to:

az deployment group create -f ./main.bicep -g my-rg

For more detail on taking advantage of new Bicep constructs that replace an equivalent from ARM Templates, you can read the moving from ARM => Bicep doc.

Here's an example of a Bicep template to create a two subnet Azure VNET:

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2019-11-01' = {
  name: 'name'
  location: resourceGroup().location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'Subnet-1'
        properties: {
          addressPrefix: '10.0.0.0/24'
        }
      }
      {
        name: 'Subnet-2'
        properties: {
          addressPrefix: '10.0.1.0/24'
        }
      }
    ]
  }
}