Before we head on to talk about bicep and how it can help you with your IaC development and maintenance, I want to take a quick moment to just go through a very slim summary of the IaC concept! If your already familiar with IaC you can just skip ahead to next headline!
What is infrastructure as code (IaC) and what are some of the benefits?
Infrastructure as code (or IaC for short) is a DevOps methodology for defining and deploying your infrastructure, with the help of a good framework and version handling IaC delivers a consistent result when deploying new infrastructure in Azure. There are two different models for IaC, imperative and declarative. Imperative is more script-based and works in a series of steps to create, delete or modify your infrastructure, while declarative is more about writing a definition template how you want your infrastructure to look. ARM template and Bicep are part of the declarative IaC and is the one I personally would recommend, its easier to get a consistent result in my opinion.
What are some of the benefits?
Avoid manual configuration when deploying new infrastructure helps making sure the deployment process is consistent and without issues!
Setting up an entire environment with the press of a button results in fast delivery of stable test/dev/qa environments, they can also be redeployed again and again for testing purposes or if someone might have completely broken them during testing (never happened to my test environments I promise).
Scanning tools for your code to make sure it is error free and some tools can even check for security compliance and best practices!
An automated procedure reduce the risk for human error, there is also an extra safety with approval control in DevOps, making sure the deployment is approved before!
Easier management of your non production environment by using the same base template but adding definition files for different environments.
And working with infrastructure as a good can actually help you better understand your environment and even Azure itself!
What is Bicep and why should you start using it?
So Bicep is a "new" open-source effort to kind of define a sort of translative language for ARM templates reduce and what I mean by translative is that JSON (ARM templates) are still what is running in the background that Azure understands. If you think JSON is the best thing since sliced bread then maybe its harder to sell you on Bicep, but as for myself and many other technicians out there JSON is not our favorite language at all, especially when it comes to authoring resources in a declarative manner! Do you feel the same? In that case I definitely think Biceps is more up your ally and think you should give it a shot!
Getting started with Biceps is fairly easy as its a easier language to read and contain overall less code, with a simpler way of declaring parameters and variables! If your using something like Visual Studio Code (and you should) there is an Biceps extension that you can use to make your Biceps building even easier with the help of intellisense validation of syntaxes.
A small example of the same code in ARM-templates on the left vs Bicep on the right, same code as below.
Code with ARM (JSON) template
{ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "metadata": { "_generator": { "name": "bicep", "version": "0.6.1.6515", "templateHash": "9102616529359417903" } }, "resources": [ { "type": "Microsoft.Network/virtualNetworks", "apiVersion": "2019-11-01", "name": "devops-vnet", "location": "westeurope", "tags": { "Department": "IT", "Enviorment": "Test", "System": "DevOps" }, "properties": { "addressSpace": { "addressPrefixes": [ "10.0.0.0/16" ] }, "subnets": [ { "name": "Devops-sub", "properties": { "addressPrefix": "10.0.0.0/29", "networkSecurityGroup": { "id": "/subscriptions/a1861b2a-aa4b-47d7-ba05-b03caa62ad3d/resourceGroups/sedc-ARMTemplate-test/providers/Microsoft.Network/networkSecurityGroups/deploy-test-nsg" } } }, { "name": "Devops-sub2", "properties": { "addressPrefix": "10.0.1.0/29", "networkSecurityGroup": { "id": "/subscriptions/a1861b2a-aa4b-47d7-ba05-b03caa62ad3d/resourceGroups/sedc-ARMTemplate-test/providers/Microsoft.Network/networkSecurityGroups/deploy-test-nsg" } } } ] } } ], "outputs": { "subnet1ResourceId": { "type": "string", "value": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'devops-vnet', 'Devops-sub')]" }, "subnet2ResourceId": { "type": "string", "value": "[resourceId('Microsoft.Network/virtualNetworks/subnets', 'devops-vnet', 'Devops-sub2')]" } } }
Code with Bicep (converted)
While a simple ARM-template as above might not save much code, a large project can save you hundreds and even thousands rows of code and if you start working more and more with IaC (which you also should ;) ) then it can save you a lot in the long run and if you ask me its more pleasant to work with.
What about ARM-templates?
ARM-templates are not going away anytime soon, as I mention before Biceps is more of a translation then a replacement. What if your already working with ARM-templates? do you have to make everything different now? Not at all, ARM-templates can actually be converted to Biceps and vise verse with the help of Biceps build, the code example above is actually just that (lazy I know). You can convert between the two as you like but you should know that it can actually change a little how the code looks, for example if you write something in ARM, convert it to Biceps and then convert the Biceps back to JSON it might have minor adjustment, but so far I have not run into or heard of any problems caused by this!
Summary
A short introduction to Biceps and why I think you should start using it as one of your main tools for build infrastructure as code, as I said you can always build your foundation in Biceps and then convert to ARM-Templates if there is a decision to only use ARM in your organization. Working with Biceps can reduce your time spending on building that code with a lot and help employees less experience with IaC to get started in building more efficient code.
Comments