This article is contributed. See the original author and article here.
Introduction
Hi folks! My name is Felipe Binotto, Cloud Solution Architect, based in Australia.
The purpose of this article is to provide a comparison on how you can do something with Bicep vs how you can do the same thing with Terraform. My intension here is not to provide an extensive comparison or dive deep into what each language can do but to provide a comparison of the basics.
I have worked with Terraform for a long time before I started working with Bicep and I can say to Terraform Engineers that it should be an easy learning curve with Bicep if you already have good experience with Terraform.
Before we get to the differences when writing the code, let me provide you with a quick overview of why someone would choose one over the other.
The main differentiator of Terraform is being multi-cloud and the nice UI it provides if you leverage Terraform Cloud to store the state. I like the way you can visualize plans and deployments.
Bicep, on the other hand, is for Azure only, but it provides deep integration which unlocks what some call ‘day zero support’ for all resource types and API versions. This means that as soon as some new feature or resource is released, even preview features, they are immediately available to be used with Bicep. If you have been using Terraform for a while, you know that it can take a long time until a new Azure release is also available in Terraform.
Terraform stores a state of your deployment which is a map with the relationship of your deployed resources and the configuration in your code. Based on my field experience, this Terraform state causes more problems than provides benefits. Bicep doesn’t rely on the state but on incremental deployments.
Code
Both Terraform and Bicep are declarative languages. Terraform files have TF extension and Bicep files have BICEP extension.
The main difference is that for Terraform you can have as many TF files as you want in the same folder, and they will be interpreted as a single TF file which is not true for Bicep.
Throughout this article, you will also notice that Bicep uses single quotes while Terraform uses double quotes.
Variables, Parameters & Outputs
Variables
In Bicep, variables can be used to simplify complex expressions which are equivalent to Terraform “local variables”.
The example below depicts how you can concatenate parameter values in a variable to make up a resource name.
param env string
param location string
param name string
var resourceName = '${location}-${env}-${name}'
The same can be achieved in Terraform as follows.
variable "env" {}
variable "name" {}
variable "location" {}
locals {
resourceName = "${var.location}-${var.env}-${var.name}"
}
Parameters
In Bicep, parameters can be used to pass inputs to your code and make it reusable which is the equivalent to “input variables” in Terraform.
Parameters in Bicep are made of the key work “param”, followed by the parameter name followed by the parameter type, in the example below, a string.
param env string
A default value can also be provided.
param env string = 'prd'
Parameters in Bicep can also use decorators which is a way to provide constraints or metadata. For example, we can constrain the parameters “env” to be three letters only.
@minLength(3)
@maxLength(3)
param env string = 'prd'
Parameter values can be provided from the command line or passed in a JSON file.
In Terraform, input variables can be declared as simple as the following.
variable "env" {}
A default value can also be provided.
variable "env" {
default = "prd"
}
In Terraform, a validation block is the equivalent to the Bicep parameter decorators.
variable "env" {
default = "prd"
validation {
condition = length(var.env) == 3
error_message = "The length must be 3."
}
}
Parameter values can be provided from the command line or passed in a TFVARS file.
Outputs
Outputs are used when a value needs to be returned from the deployed resources.
In Bicep, an output is represented by the keyword “output” followed by the output type and the value to be returned.
In the example below, the hostname is returned which is the FQDN property of a public IP address object.
output hostname string = publicIP.properties.dnsSettings.fqdn
In Terraform, the same can be done as follows.
output "hostname" {
value = azurerm_public_ip.vm.fqdn
}
Resources
Resources are the most important element in both Bicep and Terraform. They represent the resources which will be deployed to the target infrastructure.
In Bicep, resources are represented by the keyword “resource” followed by a symbolic name, followed by the resource type and API version.
The following represents a compressed version of an Azure VM.
resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' = {
name: vmName
location: location
…
}
The following is how you can reference an existing Azure VM.
resource vm 'Microsoft.Compute/virtualMachines@2020-06-01' existing = {
name: vmName
}
The same resource can be represented in Terraform as follows.
resource "azurerm_windows_virtual_machine" "vm" {
name = var.vmName
location = azurerm_resource_group.resourceGroup.location
…
}
However, to reference an existing resource in Terraform, you must use a data block.
data "azurerm_virtual_machine" "vm" {
name = vmName
resource_group_name = rgName
}
The main differences in the examples above are the following:
- Resource Type
- For Bicep, the resource type version is provided in the resource definition.
- For Terraform, the version will depend on the plugin versions downloaded during “terraform init” which depends on what has been defined in the “required_providers” block. We will talk about providers in a later section.
- Scope
- For Bicep, the default scope is the Resource Group unless other scope is specified, and the resources don’t have a Resource Group property which requires to be specified.
- For Terraform, the Resource Group has to be specified as part of the resource definition
- Referencing existing resources
- For Bicep, you can use the same construct using the “existing” keyword.
- For Terraform, you must use a data block.
Modules
Modules have the same purpose for both Bicep and Terraform. Modules can be packaged and reused on other deployments. It also improves the readability of your files.
Modules in Bicep are made of the key word “module”, followed by the module path which can be a local file path or a remote registry.
The code below provides a read-world example of a very simple Bicep module reference.
module vmModule '../virtualMachine.bicep' = {
name: 'vmDeploy'
params: {
name: 'myVM'
}
}
One important distinction of Bicep modules is the ability to provide a scope. As an example, you could have your main deployment file using subscription as the default scope and a resource group as the module scope as depicted below.
module vmModule '../virtualMachine.bicep' = {
name: 'vmDeploy'
scope: resourceGroup(otherRG)
params: {
name: 'myVM'
}
}
The same can be achieved with Terraform as follows.
module "vmModule" {
source = "../virtualMachine"
name = "myVM"
}
Providers & Scopes
Terraform uses providers to interact with cloud providers. You must declare at least one azurerm provider block in your Terraform configuration to be able to interact with Azure as displayed below.
provider "azurerm" {
features {}
}
To reference multiple subscriptions, you can use an alias for the providers. In the example below we reference two distinct subscriptions.
provider "azurerm" {
alias = "dev"
subscription_id = "DEV_SUB_ID"
tenant_id = "TENANTD_ID"
client_id = "CLIENT_ID"
client_secret = "CLIENT_SECRET"
features {}
}
provider "azurerm" {
alias = "prd"
subscription_id = "PRD_SUB_ID"
tenant_id = "TENANTD_ID"
client_id = "CLIENT_ID"
client_secret = "CLIENT_SECRET"
features {}
}
Bicep uses scopes to target different resource groups, subscriptions, management groups or tenants.
For example, to deploy a resource to a different resource group, you can add to the resource, the scope property, and use the “resourceGroup” function.
module vmModule '../virtualMachine.bicep' = {
name: 'vmDeploy'
scope: resourceGroup(otherRG)
params: {
name: 'myVM'
}
}
To deploy the resource to a resource group in a different subscription, you can also include the subscription id as per the example below.
module vmModule '../virtualMachine.bicep' = {
name: 'vmDeploy'
scope: resourceGroup(otherSubscriptionID, otherRG)
params: {
name: 'myVM'
}
}
Deployment
There are many Bicep and Terraform commands and variations which can be used for deployment or to get to a point where a deployment can be performed, but in this section, I will just compare “terraform plan” and “terraform apply” with Bicep’s equivalent commands.
“terraform plan” is the command used to preview the changes before they actually happen. Running it from the command line will output the resources which would be added, modified, or deleted in plain text. Running the plan from Terraform Cloud, you can see the same information but in a nice visual way. Parameters can be passed as variables or variables files as per below.
terraform plan -var 'vmName=myVM'
terraform plan -var-file prd.tfvars
“terraform apply” deploys the resources according to what was previewed in the plan.
In Bicep, the “terraform plan” command is equivalent to the CLI “az deployment group what-if” command or “New-AzResourceGroupDeployment -Whatif” PowerShell command.
Running it from the command line will also output the resources which would be added, modified, or deleted in plain text. However, Bicep still doesn’t provide a user interface for the what-if visualization.
The “terraform apply” command is equivalent to the Bicep CLI command “az deployment group create” or “New-AzResourceGroupDeployment -Confirm” PowerShell command.
Note that these Bicep commands are for resource group deployments. There are similar commands for subscription, management group and tenant deployments.
Conclusion
Terraform still has its place in companies which are multi-cloud or using it for on-premises deployments. I’m Terraform certified and always loved Terraform. However, I must say when considering Azure by itself, Bicep has the upper hand. Even for multi-cloud companies, if you wish to enjoy deep integration and be able to use all new features as soon as they are released, Bicep is the way to go.
I hope this was informative to you and thanks for reading! Add your experiences or questions in the comments section.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments