(Part 2 in a 10-part series)
When it comes to deploying resources in the Azure cloud, the inexperienced developer opens up the Azure portal and starts clicking away, randomly setting flags and switches until they get something to work as they expect. That can be great for experimentation, but it doesn’t really lend itself to the modern CI/CD (Continuous Integration / Continuous Delivery) that is expected from even moderately skilled developers these days.
In Azure, defining your resources used to involve some fairly complex JSON documents called ARM Templates (Azure Resource Manager). You can download examples from many places, you can write them from scratch, or you can create them based on an object you define in the portal and export them. They have parameters so you can reuse them (at least – you can if you setup the parameters properly!)
But most developers didn’t love ARM templates because they were very long and wordy. A few years back, Microsoft decided to make a better version and they called it “Bicep”. It’s a domain specific language for defining Azure resources, kind of like a YAML file. It’s much more concise and readable than the ARM JSON.
To make it even easier to use, Microsoft built a Bicep Extension for VS Code which gives you that nice Intellisense and code completion and validation.
You can break your Bicep files up modules and templates, making it very easy to reuse them in multiple places.
There are many places that you can find good Bicep templates to get started — and the next post will show you exactly how to create them.
Next step: Creating Bicep Files