Project Bicep Demo at Ignite 2020 by Mark Russinovich

Jay Gordon

Microsoft Ignite 2020 was an incredible opportunity for our virtual attendees to learn about all the great new features and advancements at Azure. One of the big new releases we saw was Project Bicep. This video with Azure CTO Mark Russinovich gives you insight into this new way of managing your Azure infrastructure with Bicep.

Bicep is a Domain Specific Language (DSL) for creating your Azure resources. While many different methods may select programming languages such as Ruby, Bicep really aims to reduce complexity by introducing a cleaner syntax for you to reuse your code more often. Bicep is a transparent abstraction of ARM templates, which differs from using another general-purpose programming language. Bicep uses Azure Resource Templates (ARM template) files in JSON to compile and deploy your desired infrastructure.

The following are the goals and the non-goals of this new DSL from the Project Bicep Repository documentation. For more information reach out to the team on how to contribute, please visit the CONTRIBUTING documentation from the repository.


  1. Build the best possible language for describing, validating, and deploying infrastructure to Azure.
  2. The language should provide a transparent abstraction for the underlying platform. There must be no “onboarding step” to enable it to a new resource type and/or apiVersion in Bicep.
  3. Code should be easy to understand at a glance and straightforward to learn, regardless of your experience with other programming languages.
  4. Users should be given a lot of freedom to modularize and reuse their code. Reusing code should not require any ‘copy/paste’.
  5. Tooling should provide a high level of resource discoverability and validation, and should be developed alongside the compiler rather than added at the end.
  6. Users should have a high level of confidence that their code is ‘syntactically valid’ before deploying.


  1. Build a general-purpose language to meet any need. This will not replace general-purpose languages and you may still need to do pre or post bicep tasks in a script or high-level programming language.
  2. Provide a first-class provider model for non-Azure related tasks. While we will likely introduce an extensibility model at some point, any extension points are intended to be focused on Azure infra or application deployment related tasks.

Is this ready for production use? If not, when will it be ready? Not yet. We wanted to get the 0.1 release out quickly and get feedback while we still have an opportunity to make breaking changes. By the end of the year, we plan to ship an 0.3 release which will be at parity with what you can accomplish with ARM templates. At that point, we will start recommending production usage.

What are you looking for feedback on? The language syntax and the tooling. Now is the best time to make breaking changes, so syntax feedback is very appreciated.

To learn more about Project Bicep, check out the following resources:

Azure Bicep on GitHub
Bicep Language Specification
Microsoft Open Source Code of Conduct
@BicepLang on Twitter