Infrastructure-as-Code (IaC) is a concept that allows for the management of infrastructure through the use of code. This means that instead of manually configuring and setting up infrastructure using a web interface, the infrastructure is defined and provisioned using code. This allows for greater automation, consistency, and repeatability in the management of infrastructure, as well as making it easier to version control, test and rollback changes
Imagine you need to deploy multiple virtual machines, three storage accounts, and a virtual network. Next, you need to configure the network links on that network and format tje diskss. "Just one click" in the UI turns into hours of clicking and filling out all the forms and properties.
Now imagine that something went wrong towards the end and you have to start all over again. With the IaC model, you can write code to describe all infrastructure components and then leave the implementation to Terraform, Bicep, or ARM. In this case, if something goes wrong at the end, you can change a few lines of code to fix the problem and run the code again.
Another benefit is the ability to use a source code versioning system such as Azure DevOps or Github to store your code. This gives you equal version control and makes it possible to easily see all changes in the infrastructure and make them available to all team members. By using versions, you automatically have an audit log in which all changes are recorded
When you start using IaC, you still have to make a number of choices. The most important choice here is: which language will you use? In principle, you have a choice of three languages.
The three languages all use the Azure Resource Manager for the deployment. The Azure Resource Manager ensures that the code is converted to a resource that must be created. For each language I've made an example how to create a resource group within Azure, so that you can see a good difference between the different languages.
In the past, ARM templates were the only way to create resources in Azure based on IaC. This is also the default "language" that the Azure Resource Manager uses.
The following code is required to create a resource group:
{
"$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"rgName": {
"type": "string"
},
"rgLocation": {
"type": "string"
}
},
"variables": {},
"resources": [
{
"type": "Microsoft.Resources/resourceGroups",
"apiVersion": "2021-04-01",
"name": "[parameters('rgName')]",
"location": "[parameters('rgLocation')]",
"properties": {}
}
],
"outputs": {}
}
Bicep is a language developed by Microsoft as a replacement for the ARM templates. The advantage of this language is that it is more readable and you need fewer lines to achieve the same. The disadvantage of Bicep, just like ARM templates, is that it can only be used on the Azure platform.
As indicated, you need less code for the same action, creating a resource group.
targetScope = 'subscription'
resource rg 'Microsoft.Resources/resourceGroups@2021-01-01' = {
name: 'rg-contoso'
location: 'westeurope'
}
Terraform is a language developed by the Terracorp company. This language can be used for all cloud platforms, Google, AWS and Azure. This makes it a language that is widely used by developers in the open-source community and companies with a multi-cloud environment.
Like Bicep, Terraform uses the Azure Resource Manager to create the resources. Because Terraform can be used for multiple cloud environments, you must indicate that you want to use the Azure Resource Manager. To create a resource group you can use the following code:
resource "azurerm_resource_group" "example" {
name = "rg-contoso"
location = "West Europe"
}
The emergence of Bicep and Terraform makes it easier to create resources in an unambiguous way. Because both languages are easy to read, you also have documentation of the environment and, in combination with Azure DevOps or Github, an audit trail for the changes.
There is not really one answer to this and it has a lot to do with which cloud provider you use and the composition of a team.
If you only use Microsoft Azure, it's best to work with Bicep because this language has been developed for Microsoft Azure.
If you use different Cloud environments within your company, for example AWS and Azure, it is advisable to use Terraform because you can then manage both environments with the same language.
In my next blog I will discuss the use of Terraform in more detail.