Microsoft flexes Bicep to strengthen ARM

In the cloud-native world, infrastructure is code, often written using declarative languages such as YAML. Instead of building virtual machines and networking by clicking in Web forms, you put together a template that can be accessed by a script to deploy the features it describes: machines, applications, services, networking. You can write a template once, sharing it with colleagues or even managing it in your GitHub repository, pushing out a new infrastructure automatically at the end of each CI/CD (continuous integration/continuous development) build.

If you’re using this technique with Azure you have several options: its own built-in Azure Resource Manager (ARM) templates or third-party tools such as HashiCorp’s Terraform and Pulumi’s use of languages like JavaScript and Python to build out entire infrastructures. Although ARM is a commonly used tool for describing Azure resources, it’s not the simplest tool. It can be quite easy to fall into anti-patterns, developing templates that are either too complex or too simple for your application infrastructures. It’s very much infrastructure-heavy, making it hard at times to construct application-specific templates.

Introducing Bicep

Microsoft recently announced a new way to build ARM templates with a new language that treats ARM as a compilation target. There’s no change to Azure, so your existing ARM templates can still be used, but the new language is designed to make it easier to validate your Azure resource descriptions. Currently code-named “Bicep” (it’s the muscle that makes your ARM work), Microsoft has opened it up for contributions on GitHub.

Like many other infrastructure as code solutions, Bicep is a Domain Specific Language (DSL) designed to describe resources used in an Azure application, from VMs, networks, and Azure services. The existing ARM language manages this too, but it can be hard to build repeatable patterns in ARM, and Bicep is being designed to produce modular code that can be used and reused to assemble complex architectures. Microsoft describes it as a “transparent abstraction” of ARM, an approach that can be compared to the relationship between TypeScript and JavaScript.

Getting started with the first public release of Bicep

The first set of Bicep tools can be downloaded right away. It’s not complete by any means, and some planned features aren’t ready yet. But you can use it now with macOS, Linux, and Windows, with a CLI with a Bicep compiler and a Visual Studio Code extension that includes basic Intellisense support and language validation.

Installing the CLI is easy enough. On macOS and Linux you can use curl to download the current binary release of the CLI from GitHub. Windows systems can do much the same using PowerShell. With the CLI installed, add it to your system path, ready for use. You can now install the Visual Studio Code plug-in. It’s not yet in the marketplace, so download it from the releases page and then use Code’s built-in extension side-loading features. Alternatively, you can use a variant of the command line instructions used to download the CLI before installing via Code’s command line.

The Code plug-in includes a language server, which gives you appropriate syntax highlighting. You are now ready to add resources to a Bicep file. All resources have symbolic names used to describe them in your infrastructure as code. These are linked to the type of resource, using its provider, type, and API version as used in ARM templates. You can then add properties—again those used in ARM templates or set using the Azure Portal. When compiled using the Bicep compiler, the file generates ARM JSON, ready for deployment using the Azure CLI. If you want to play with it before installing any tools, an online scratchpad lets you try out the editor features.

Programming infrastructures for Azure

Bicep supports parameters, so you can control specific resource properties programmatically: for example setting the region where a resource is being deployed. Although you can put default values for parameters into a Bicep definition, they can be overridden at run time, targeting a different region or changing network names or storage sizes. There’s also support for variables and expressions, as well as outputs that can be passed to other templates or to a deployment script.

Parameters can be delivered to a Bicep template either from the Azure CLI, as part of a deployment, or included in a JSON parameter file. Having all your parameters in a build artifact makes more sense, as it allows you to manage them more effectively and reduces the risk of error when launching a deployment. Bicep supports expressions, so you can use functions to generate resource parameters automatically. Instead of having to name every server you deploy, you can create a function that generates those names using appropriate rules and a powerful set of string interpolations. That way a Bicep generic template for a virtual machine can be used for many different purposes, with appropriate names, sizes, and the like chosen for each deployment.

Other Bicep programming constructs include a ternary operator that can be used for simple conditionals and compile time tools that help automatically manage dependencies using symbolic names. These features help avoid what would be complex scripting tasks around ARM templates, allowing you to build them into your Bicep resource descriptions.

The future of Azure infrastructures as code

Bicep isn’t only a DSL for ARM. It’s also a statement that Microsoft is rethinking the role of ARM as part of Azure’s infrastructure-as-code implementation. The Bicep documentation repeatedly refers to ARM as an intermediate language, which Microsoft expects to become the target for many different infrastructure DSL compilers such as Bicep’s. ARM and its associated infrastructure runtime in the Azure CLI will remain the preferred tool for deploying resources in Azure, but your devops team can pick and choose the languages, tools, and technologies that are compiled into ARM templates.

It’s not hard to a see a future with a Visio-based design surface in either Visual Studio or Visual Studio Code where you’d be able to sketch an application architecture, define the resulting infrastructure and services needed to implement it, and then save out as Bicep into your source control or configuration management platforms before deploying the entire virtual infrastructure as part of a build. Another intriguing option would be using Bicep as an input to Azure’s billing tools to get an estimate of the operational costs for an application before a deployment, adding cost management to your resource validation

By delivering Bicep as a complete suite of tools from editor to compiler, Microsoft is showing how it expects these tools to be delivered. It’s easy to imagine a Bicep server definition being edited and verified in Visual Studio Code, autosaved onto GitHub, and then compiled to ARM as part of a deployment Action. The command line Bicep compiler makes it easy to add it into whatever CI/CD pipeline you’re using without needing multiple APIs and connectors. If you’re using Jenkins or Azure DevOps it’s as simple to implement Bicep in your existing tools pipeline as anywhere else. With Bicep your infrastructure descriptions should be a generated artifact, just like the rest of your code.

One final caveat: These are very early days for Bicep, and it’s not yet ready for production. Some key features still are missing, but it’s a good time to give it a once-over. Convert existing ARM templates, see what works for you and your infrastructure needs and what changes you think are necessary, and then contribute to the project. That’s why today’s much more open Microsoft has released Bicep so early, to make it a collaborative open language that works well for everyone.