Azure Bicep comparison with ARM template

Question

I read something about Azure Bicep, it is something new I feel -

Azure Resource Manager and ARM Templates are written in a JSON syntax that can be cumbersome to work with. Azure Bicep is a Domain Specific Language (DSL) that offers a transparent abstraction over Azure Resource Manager and ARM Templates that offers support for a cleaner code syntax with better support for modularity and code re-use. Azure Bicep offers a few improvements for authoring Azure IaC over the use of ARM Template JSON.

I want to understand the comparison between ARM template and Azure Bicep like what are advantage and disadvantage, limitations and use cases for these two.

Answer 1

I think the official GitHub repository for Bicep has pretty much all the answers you mention in your question.

Some extracts:

Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively. It aims to drastically simplify the authoring experience with a cleaner syntax, improved type safety, and better support for modularity and code re-use. Bicep is a transparent abstraction over ARM and ARM templates

How is life better with Bicep?

• Simpler syntax when compared to equivalent JSON
• [...]

Known limitations

• No support for single-line object and arrays (i.e. ['a', 'b', 'c'])
• [...]

FAQ

Is this ready for production use? Yes. As of v0.3, Bicep is now supported by Microsoft Support Plans and Bicep has 100% parity with what can be accomplished with ARM Templates. As of this writing, there are no breaking changes currently planned, but it is still possible they will need to be made in the future.

Update: Updated extracts because it is now production ready.

Answer 2

I think the best way to think about BICEP is simply an easier and less error-prone process to generate ARM templates. Ultimately, the BICEP tool is just a transpiler i.e. it turns BICEP files into a single ARM template that can be deployed in the way you're used to. It's not adding additional layers of abstraction, so you can always use the most recent resource manager API version and attributes.

Having played with it a little, I'm pretty excited about it. Before BICEP came along, I was using linked templates for modularity and re-using code wherever I could, but it was cumbersome to wrangle large and verbose JSON files.

With the VSCode BICEP extension and the efforts Microsoft have put into intellisense and linting of BICEP, plus the ability to quickly see the ARM output, I think we'll enjoy significant productivity increases.

In addition, the BICEP decompiler looks like a really useful migration tool to turn existing ARM templates into BICEP.

ARM templates have been a source of frustration and woe in the past, but BICEP is huge improvement. Obviously Terraform does great work in this area too, but unless you're specifically multi-cloud and multi-resource-provider, I believe BICEP offers a sensible approach.

Answer 3

BICEP is much more approachable than the ARM template syntax.
BICEP is designed as a combination of Yaml/TS/Js formatting without needless punctuation. Bicep is a markup language like CSS with loops, if's, ternary operations, and a VS Code intellisense plugin that validates syntax. Bicep still requires the user to understand Azure Resource Manager "resources" (a Bicep term) but gives the devops monkey a much sweeter syntax sugar to work with than error prone json jibberish {","}; Bicep also adds support for comments which are not part of Json. Bicep is also a bit safer to use with it's -c ("check sanity") since everything (by default) is scoped to the ResourceGroup level.

BICEP provides feature parity with ARM, because it is a transpiler that produces ARM templates but adds higher-level functionality such as loops, includes, symbolic references. ARM is the underlying language to bicep, it is also used by tools such as terraform, or self-managed K8 auto-scaling.

The one downside is that BICEP transpiles into ARM, so if you have bugs in your bicep code you might end up needing to learn ARM anyway to understand what happened.

Answer 4

The one downside is that BICEP transpiles into ARM, so if you have bugs in your bicep code you might end up needing to learn ARM anyway to understand what happened.

I think this shortcoming is easier than debugging when you run into problems with TF.

Currently, the relationship between ARM templates and BICEP is straightforward and one-to-one, which is very straightforward. Unfortunately, working with Azure requires an understanding of Azure REST API Specifications and ARM Tempate. But I like Bisp because I don't want to wrestle with ARM Tempate every time.

Bicep made my Azure Life happy.

Answer 5

Its really simple, Bicep compiles to arm.

Bicep exists to enhance the authoring experience of arm.

There is no use case for continuing to author Arm templates.