It’s time for the monthly blog party, and this month the host is Frank Geisler. I was reaching out to various people last year to find hosts, and also (silly-ly) looking for first names to fill out the alphabet on the host page.
Frank is a fellow MVP and a BI expert. He was gracious enough to agree to host and I thought he picked an interesting topic. This month’s invitation is about scripting to deploy resources. I don’t do a lot of deployments over and over, but I have been interested in one area. It’s actually been a tab in my browser open for a few weeks, so I took this opportunity to dig in.
Bicep
I’ve been seeing this term used in various blogs, and in the MVP email list we have. I wasn’t sure what it was, and I kept thinking of this:
That’s not it at all, and I was glad I went through this resource.
Bicep is a transpiler, meaning it takes one language and translates it into another. In this case, the Bicep language will move code into the ARM JSON templates. JSON is really for machines, not humans, so the idea is to give sysadmins and developers an easy way to describe resources they need to deploy into Azure.
The language is new, and it’s on Github. This is a DSL (domain specific language), which means it was designed for a specific purpose. With the 0.3 release, the language is built into the Azure CLI and Azure PoSh utilities, so this will do the transpilation for you. There’s also a decompiler to go from an ARM template back to Bicep. It’s also supported by Microsoft, which is always a plus if you need to call for some issue.
I don’t know a lot about Terraform, but this appears to be another language designed to do the same thing. The FAQ in GH notes this is a revision of ARM, which I guess makes sense. I’m guessing at some point they’ll try to get people to not use ARM (or stop supporting this) and only work with Bicep. Azure supports Terraform, so I’m guessing this is more an attempt to deprecate ARM and the challenges of customers working with JSON.
A couple things I did like about this. First, there are modules, so you can reuse some code. There is also intellisense, validating and getting you actual resources from Azure that are available. I do worry about deprecation that makes it difficult to deploy a copy of an existing resource when Azure is trying to push you to use some new resource. However, I do think the intellisense and validation in the VS Code extension improve productivity for developers and sysadmins.
Reuse also helps infrastructure teams assist developers by providing them modules that adhere to good or best practices.
The language looks like a mix of Python and YAML. Not too hard to understand, and with help, this should be easy to use to create a resource.
I’m pressed for time today, so I’m not going to experiment or set up an environment, but I need to add this to a list of things to do.
Why call it Bicep? No idea. I can’t find an answer, but I did someone say these are “ARMless deployments”. Not sure that fits with Bicep, but I like the logo.
