To achieve scale, DevOps teams are always looking for ways to quickly deploy code with a trusted and repeatable process. When it comes to the cloud and infrastructure, this process is increasingly accomplished with infrastructure-as-code (IaC). IaC tools range from general-purpose tools to tools intended for specific environments. Terraform is an example of the former, while Bicep is designed to handle Azure-related tasks.
In this article, we compare nine infrastructure and integration features of Bicep and Terraform. Understanding these differences helps you decide which tool best supports your infrastructure and processes.
State and backend
Both Terraform and Bicep are desired state configuration (DSC) which makes it easy to manage IT and development infrastructure as code. Terraform stores state about your managed infrastructure and configuration. Terraform uses this information to map real-world resources to your configuration, track metadata, and improve the performance of larger infrastructures. State is stored in a local file named terraform.tfstate, but can also be stored remotely. It's critical to back up and secure your state files. Like Terraform, Bicep is declarative and goal-seeking. However, Bicep doesn't store state. Instead, Bicep relies on incremental deployment.
Infrastructure targets
When comparing Bicep to Terraform for managing cloud infrastructure, it's important to consider your target cloud environment:
- Azure-only
- Multi or hybrid-clouds
Bicep is Azure-specific and not designed to work with other cloud services.
If your goal is to automate deployments to any of the following environments, Terraform is likely the better option:
- Virtualization environments
- Multicloud scenarios - such as Azure and other cloud(s)
- On-premises workloads
Terraform interacts with other cloud providers or APIs using plugins called providers. There are several Terraform Azure providers that enable the management of Azure infrastructure. When coding a Terraform configuration, you specify the required providers you're using. When you run terraform init, the specified provider is installed and usable from your code.
Command Line Interface (CLI) tools play a key role in orchestration through the implementation and management of automation technology. Both Bicep and Terraform offer CLI tools.
Bicep integrates with Azure CLI, allowing developers to use az commands such as:
az bicep: The az bicep commands allow you to perform such tasks as installing Bicep, and building and publishing Bicep files.az deployment: The article How to deploy resources with Bicep and Azure CLI explains how to use Azure CLI with Bicep files to deploy your resources to Azure.
The Terraform CLI allows you to perform such tasks as validate and format your Terraform code, and create and apply an execution plan.
Bicep also provides a feature that makes it easy to integrate Bicep with Azure Pipelines. There's a similar feature available for Terraform but you must download and install the Azure Pipelines Terraform Tasks extension for Visual Studio. Once installed, you can run Terraform CLI commands from Azure Pipelines. Moreover, both Terraform and Bicep support GitHub Actions to automate software builds, tests, and deployments.
Processing
There are some important differences between Bicep and Terraform in terms of the efficiency and optimizations of deployments. With Bicep, processing occurs within the core Azure infrastructure service side. This feature offers advantages such as preflight processing to check policy or the availability for deploying multiple instances within a region. With Terraform, processing is done within the Terraform client. Thus, preprocessing involves no calls to Azure since it uses state and HCL (HashiCorp Language) to determine the required changes.
Authentication
The Azure authentication features vary between Bicep and Terraform. With Bicep, an authorization token is supplied during the request to submit a Bicep file and ARM Template. ARM ensures that you have permission to both create the deployment and deploy resources within the specified template. Terraform authenticates each API based on provider credentials – such as Azure CLI, service principal, or managed identities for Azure resources. Moreover, multiple provider credentials can be utilized in a single configuration.
Azure integrations
You should also consider your use of Azure features such as Azure Policy and how each interacts with other tools and languages. Bicep's preflight validation determines whether a resource doesn't comply with a policy so that it fails before a deployment. Thus, developers can remediate resources with policy using provided ARM templates. The ARM template can be used to create a policy assignment to another resource for automated remediation. Terraform, however, fails when a resource is deployed that is disallowed due to policy.
Portal integration
One major advantage that Bicep has over Terraform is the ability to automate portal actions. With Bicep, you can use the Azure portal to export templates. Exporting a template helps you to understand the syntax and properties that deploy your resources. You can automate future deployments by starting with the exported template and modifying it to meet your needs. Until Terraform templates are supported, you need to translate the exported template manually.
Although Terraform doesn't provide the same portal integrations as Bicep, existing Azure infrastructure can be taken under Terraform management using Azure Export for Terraform. (Azure Export for Terraform is an open-source tool owned and maintained by Microsoft on the Azure/aztfexport GitHub repo.)
Out-of-band changes
Out-of-band configuration changes are changes made to a device configuration outside the context of the tool. For example, let's say you deploy a Virtual Machine Scale Set using Bicep or Terraform. If you change that Virtual Machine Scale Set using the portal, the change would be "out-of-band" and unknown to your IaC tool.
If you're using Bicep, out-of-band changes should be reconciled with Bicep and the ARM Template code to avoid having those changes overwritten on the next deployment. These changes don't block the deployment.
If you're using Terraform, you need to import the out-of-band changes into the Terraform state and update the HCL.
Thus, if an environment involves frequent out-of-band changes, Bicep is more user-friendly. When you use Terraform, you should minimize out-of-band changes.
Cloud frameworks
The Cloud Adoption Framework (CAF) is a collection of documentation, best practices, and tools to accelerate cloud adoption throughout your cloud journey. Azure provides native services for deploying landing zones. Bicep simplifies this process with a portal experience based on ARM templates and landing-zone implementation. Terraform utilizes an Enterprise-Scale Landing Zones module to deploy, manage, and operationalize with Azure.
Summary
Bicep and Terraform offer many user-friendly infrastructure and integration features. These features make it easier to implement and manage automation technology. When deciding which is best for your environment, it's important to consider if you're deploying to more than one cloud or whether your infrastructure consists of a multi or hybrid-cloud environment. Moreover, be sure to consider the nine features discussed in this article to make the best choice for your organization.
Today's organizations face dynamic challenges that require a great deal of flexibility and agility. Public cloud environments meet these needs through automation - especially via infrastructure as code (IaC). Two leading IaC options are Hashicorp Terraform and Bicep. Terraform is an open-source tool that helps DevOps professionals manage on-premises and cloud services using declarative code. Microsoft Bicep utilizes declarative syntax to simplify the deployment of Azure resources.
In this article, we compare several key user-experience features to identify similarities and differences between Terraform and Bicep.
Language syntax
Bicep and Terraform are domain-specific languages (DSL) that are easy to use and save developer time. Both tools incorporate similar keywords and concepts. Some of these concepts are parameterization, support for multi-file projects, and support for external modules. Terraform, however, offers a richer library of built-in functionality for certain tasks. Deciding between the two is a matter of preference and experience. The following are brief overviews and some of the user-friendly features that each language syntax offers.
Bicep is a declarative language. As such, the order in which the elements are defined in the code doesn't affect how deployment is processed. Bicep's default target scope is the resourceGroup. Users can employ variables to encapsulate complex expressions and make Bicep files more readable. The concept of modules enables the reuse of Bicep code across projects or teams.
Terraform is also a declarative language that uses the HashiCorp Configuration Language (HCL). The primary purpose of HCL is to declare resources. Other language features serve to make defining resources more convenient. And like Bicep, the ordering of code in Terraform configuration files isn't significant.
Language helpers
Both Bicep and Terraform provide language helpers to simplify coding tasks. Since both are user-friendly, the choice largely depends on preferences and requirements.
Bicep supports expressions to make your code more dynamic and flexible. Different types of functions can be used in a Bicep file. Some of these function types are logical, numeric, and objection functions. Loops can define multiple copies of a resource, module, property, variable, or output. Loops help to avoid repeating syntax in a Bicep file.
Terraform also offers built-in functions that are called from within expressions to transform and combine values. Like Bicep, Terraform expressions can include complex expressions such as references to data exported by resources and conditional evaluation. Loops can handle collections and can produce multiple instances of a resource without the need to repeat code.
Modules
Both Bicep and Terraform support the concept of modules. Modules allow you to create reusable components from your code. Modules play a key role in scaling infrastructure and keeping configuration clean. Since modules encapsulate groups of resources, they reduce the amount of code that must be developed for similar infrastructure components. While modules function similarly in Bicep and Terraform, they vary in implementation.
In Bicep, a module is simply a Bicep file that is deployed from another Bicep file. Bicep modules serve to improve the readability of Bicep files. These modules are also scalable. Users can share modules across teams to avoid code duplication and reduce errors. For more information about defining a Bicep module, see Bicep modules.
In Terraform, modules are the primary means of packaging and reusing resource configurations across teams. Terraform modules are containers for multiple resources that are packaged as a single logical unit. A module consists of a collection of .tf and/or .tf.json files stored together in a directory. In addition to modules from the local filesystem, Terraform can also load modules from various sources. These sources include the registry, local path, modules, and GitHub.
Provisioning lifecycle
Both Terraform and Bicep allow developers to validate a configuration before deployment and then apply the changes. Terraform provides more flexibility to destroy all remote objects managed by a particular configuration. This feature is useful to clean up temporary objects once your work is completed. It's crucial to consider the lifecycle requirements of typical infrastructure deployments when choosing the best option.
Bicep offers a what-if operation that allows you to preview changes before deploying a Bicep file. The Azure Resource Manager provides the what-if operation and doesn't make any changes to existing resources. It's then possible to use Azure PowerShell or Azure CLI with your Bicep files to deploy your resources to Azure. Azure PowerShell and Azure CLI don't support the deployment of remote Bicep files. However, you can use Bicep CLI to build your Bicep file to a JSON template and then load the JSON file to a remote location.
In Terraform, the terraform plan command is similar to the Bicep what-if operation. With the terraform plan command, you create an execution plan to preview before applying it. You then apply the execution plan via the terraform apply command. Almost anything you do with Terraform involves using both the terraform plan and terraform apply commands.
Getting started
Bicep and Terraform both offer resources to help you get you started. The Learn module for Bicep helps you define how your Azure resources should be configured. You're also guided through the deployments of several Azure resources to give you hands-on experience.
Likewise, HashiCorp Learn provides users with various Terraform training resources to teach you how to install and use Terraform. These resources include information showing how to use Terraform to provision infrastructure on Azure.
Code authoring
The code-authoring experience is dependent on the number of add-ins that are available for your editor of choice. Fortunately, both Bicep and Terraform offer resources to improve code-authoring efficiency.
For Bicep, one of the most effective add-ins is the Bicep Visual Studio Code extension. The extension provides such features as code validation, Intellisense, dot-property access, and property autocompletion.
For Terraform, the Terraform Visual Studio Code extension with the Terraform Language Server offers many of the same features as the Bicep Visual Studio Code extension. For example, the extension also supports syntax highlighting, IntelliSense, code navigation, and a module explorer. HashiCorp also offers [detailed installation instructions] on its GitHub repo (https://github.com/hashicorp/terraform-ls/blob/main/docs/USAGE.md) for configuring and using the Terraform Language Server.
Azure coverage
Bicep has an advantage over Terraform when it comes to configuring Azure resources. Bicep is deeply integrated with Azure services. Moreover, it offers immediate support for new Azure features. Terraform provides two providers that allow users to manage Azure: AzureRM and AzAPI. The AzureRM provider offers a fully tailored experience for stable Azure services. Sometimes getting to this tailored experience can result in a bit of a delay. The AzAPI provider is a thin layer on top of the Azure Resource Manager REST APIs, which - like Bicep -enables immediate support for new Azure features. It's important to consider your organization's infrastructure requirements and whether they're fully supported before making a decision.
Community and Support
The community plays a key role in helping to learn and overcome challenges. Both the Terraform and Bicep communities offer a high level of engagement and support.
For Bicep support, where you go for help depends on the nature of the issue:
For Terraform support, where you go for help depends on the nature of the issue:
Summary
Bicep and Terraform are two leading IaC options that make it easy to configure and deploy Azure resources. Both offer user-friendly features that help organizations boost efficiency and productivity. When assessing the best fit for your organization, carefully consider your infrastructure requirements and preferences.
