Bicep vs. Terraform: Which Should You Choose?

Hashicorp Terraform has made a name for itself as an Infrastructure as Code powerhouse, capable of interacting with many different environments along with a newcomer onto the Infrastructure as Code scene in Azure called Azure Bicep. What is Terraform? What is Azure Bicep? What about Azure vs Terraform? Which solution should you choose for your IaC configuration language? Let’s find out.

Automated Workflows & Infrastructure as Code

The public cloud world has led to an explosion of cloud-based infrastructure in leading public cloud service provider environments. Along with new ways of doing things, tooling, and types of infrastructure, the cloud has led to a new automation workflow for infrastructure engineers known as Infrastructure as Code (IaC). Infrastructure as code allows IT operations to “describe” infrastructure as code and enables the code to provision infrastructure in the cloud in the way it is described and defined in the IaC.

It has opened the door to a developer-minded approach to infrastructure. The birth of DevOps has resulted in mashing up the world of code development with IT operations. Exciting DevOps tools have been born from this movement of infrastructure into code.

What is declarative IaC?

Infrastructure as Code provides a way to describe or declare what infrastructure looks like using code. The declarative nature of Infrastructure as Code is sometimes referred to as the desired state. In the code, you describe the result of the infrastructure and how it should look after the code runs. The code then builds out the infrastructure as described. Any deviation from this declared state can be remediated using the description of the infrastructure as code.

What makes this new approach possible with cloud-native infrastructure? This new method of building infrastructure is made possible by powerful RESTful APIs exposed by public cloud service providers. Public cloud infrastructure environments including Amazon AWS and Microsoft Azure provide API endpoints to perform infrastructure operations using calls to the code’s backend APIs. In fact, generally speaking, the GUI cloud dashboards interact with these backend APIs to complete the various actions accomplished from the web UI.

The exposed RESTful API endpoints have allowed the building of tools like Terraform and Azure Bicep to leverage these APIs in code to perform the building out of infrastructure in the cloud programmatically. Infrastructure as Code platforms such as Terraform and Azure Bicep provide abstractions of the underlying APIs and make writing the code relatively easy to interact with these APIs. Rather than interact directly with the RESTful API endpoints, using the abstraction layer makes a much more human-readable platform to interact with the cloud providers’ backend infrastructure.

Benefit of versioning

Another tremendous benefit of Infrastructure as Code is the ability to version the changes made to the code, and by extension, the infrastructure. Using Infrastructure as Code, DevOps engineers can now use a version control system such as Github to track and check-in changes. This capability has never been possible with physical infrastructure and traditional infrastructure changes.

Also, using a version control system allows DevOps engineers to integrate infrastructure as part of CI/CD pipelines. This integration enables making infrastructure changes a part of the build process to deploy code and production applications through the entire code lifecycle process (Dev to QA to Stage to Production).

GitLab CI/CD pipeline

Infrastructure as Code tools such as Terraform, Azure Bicep, and others, allow DevOps engineers to benefit from making infrastructure changes in code, versioning the changes, and using Git workflows. This capability helps support much more aggressive development lifecycles in the cloud since the required infrastructure is now tracked in code.

What is Terraform?

Terraform is a freely available tool that can be downloaded from the official Hashicorp Terraform site. Hashicorp Terraform allows writing declarative Infrastructure as Code using configuration files in Hashicorp Configuration Language (HCL).

Arguably, there isn’t a more widely known and adopted tool in Infrastructure as Code than Hashicorp’s Terraform. Hashicorp Terraform has achieved a milestone with the recent 1.0 release. It capitalizes on over 100,000,000 downloads and over 1500+ contributors to the project.

What is Terraform used for?

Terraform allows writing descriptions of infrastructure using very human-readable and intuitive descriptions of resources using blocks, arguments, and expressions. These descriptions of infrastructure in code allow quickly building, changing, modifying, and versioning infrastructure.

What is Terraform in DevOps?

DevOps professionals can generally get up to speed quickly using Terraform HCL configuration to describe infrastructure in the cloud or on-premises. In the configuration files, descriptions are presented to Terraform so it can run a single component or application or the entire landscape of your infrastructure environment, whether on-premises or in the public cloud.

Terraform generates what Hashicorp refers to as an execution plan. This execution plan describes to Terraform what it needs to do to achieve a desired state of the infrastructure. Once the execution plan is decided, it is used to build the infrastructure described in the configuration files. One of the features of Terraform is the ability to track the state of the infrastructure. It means that Terraform can track changes made and create incremental execution plans to apply. What types of infrastructure can be managed by Terraform?

• Compute

• Storage

• Networking

• DNS

• SaaS applications

• PaaS

• Single high-level components

• ..many others

Terraform is run using a series of commands that creates infrastructure through the complete DevOps workflow of planning and execution. Take note of the following commands and workflow.

Terraform commands:

• • Terraform refresh – Reconciles what terraform thinks the infrastructure looks like with the real infrastructure state (VMware, Amazon, Azure, etc.).

• • Terraform plan – The plan reconciles the real world (what is running) with what the code “wants” to be running or has described as running

• • Terraform apply – It applies the execution of the plan. It looks at the plan and executes the plan according to the natural dependencies required by the cloud.

• • Terraform destroy – A specialized version of apply that creates a special destroy plan to remove all the elements that exist

Using the workflows provided by Terraform and the ability to describe your infrastructure in Terraform configuration files means the process for both “day 1” and “day 2” infrastructure and lifecycle management is the same. In the day 1 deployment of infrastructure using Terraform, it recognizes that none of the infrastructure exists. So, Terraform builds the nonexistent infrastructure according to the description in the configuration files. Day 2 operations follow the same workflow. The infrastructure needed is simply added to the configuration files. Since Terraform tracks the state, it automatically knows the changes that need to be made when the configuration is updated and the plan is applied.

What is Terraform AWS?

There may be confusion when one sees a reference to Terraform AWS and others when Terraform is referenced along with AWS. Terraform AWS generally refers to the Terraform AWS provider that allows interacting with your Amazon AWS environment and describing your AWS infrastructure in code. However, it can also be a reference to the AWS module for Terraform.

Terraform AWS module found on the Terraform registry site

What is the difference between Ansible and Terraform?

Ansible is a prevalent and robust configuration management solution that provides a great way to control configurations in your environment and is often used to control configuration drift. Ansible’s strong suit is not provisioning infrastructure. Instead, it is more focused on configuring the infrastructure once it has been provisioned.

Conversely, Terraform is much more adept at provisioning infrastructure and maintaining the desired state of the actual infrastructure in both on-premises and cloud environments. However, it is generally lacking compared to Ansible and other configuration management tools in interacting with the infrastructure, such as configuring guest operating systems, installing software, etc.

Ansible and Terraform are often used together in many environments as complementary solutions that allow provisioning the infrastructure using the desired state (Terraform), interacting with the infrastructure, performing required configuration, installing software, and other actions (Ansible).

Terraform architecture

Terraform architecture consists of the following components.

• • Terraform core – configuration provided by the user and the state (its view of the infrastructure). The core is responsible for the graph of the resources (how they relate, what needs to be created, updated, destroyed, etc.)

• • Providers – how Terraform connects to a particular infrastructure environment (AWS, Azure, GCP, Openstack, VMware, etc.) Providers can also include higher-level components such as Kubernetes, Lamdas, Datadog, Fastly, Github Teams, and many other infrastructure types (IaaS, PaaS, SaaS).

• • • To date, Terraform includes over 100 providers capable of controlling over 1000 different resources

• • Terraform module – A Terraform module is like a “black box” of infrastructure with input variables to toggle output variables and other operations. Modules are published to a central registry that can either utilize the official Terraform registry found at registry.terraform.io, or a private registry.

Terraform Enterprise Edition

For organizations who want to implement Terraform in a more controlled and team-oriented approach, Hashicorp offers Terraform Enterprise. Terraform Enterprise can run as either a self-hosted or a hosted SaaS implementation of Terraform Cloud. It provides a private implementation of Terraform in the cloud with no resource limitations and offers additional enterprise features, including SAML single sign-on and audit logging.

Additionally, with Terraform Enterprise, teams have access to a WYSIWYG editor for those who want to pick and choose Terraform modules from a GUI interface without the need to know the inner workings of Terraform itself. Secrets and other sensitive credentials are managed in an encrypted and centrally located credential repository.

What is Azure Bicep?

What is Project Bicep, Azure Bicep, or Bicep Azure? Fundamentally it is a transpiler, taking a new language and translating that into ARM templates like you can do any other time to deploy on Azure. If you have multiple different languages, you could have a situation where something is supported in one language but not the other.

This idea should be familiar if you have something like TypeScript, a transpiler language that translates its representation into Javascript for execution in something like Node or your web browser. Microsoft developed Azure Bicep to have a new and very easy way to manage and implement infrastructure in Azure with an Infrastructure as Code approach.

Many customers are already using the Azure templates for their environments. Microsoft specifically engineered Azure Bicep to work fluidly with the ARM templates and clean up the “noise” of pure JSON data. The JSON data format that you use between a browser and server to communicate data. It was never intended for humans to read or write. It contains extra commas, brackets, and noise that get in the way of understanding what you want to do.

Below is a comparison of Azure Bicep code on the left, with ARM template JSON code on the right. They both are performing the same operation. However, as you can see below, the Azure Bicep code is much simpler and more concise.

Comparison of Bicep code and ARM template JSON code

Another benefit of Azure Bicep is that because it translates the native ARM template language, Azure Bicep can access every service in Azure on Day 0, even those in preview. It supports any API presently in Azure and any new API added to Azure. Because it has the native binding to the ARM template language, you are assured of having 100% coverage.

Azure services supported by Bicep

Azure Bicep also excels in modularity and code reuse. It introduces the notion of modules. Modules allow taking a piece of your code and breaking it out for reuse and abstraction. Then, you can share the modules for use elsewhere on such platforms as Github.

Microsoft has also engineered it to be built for modern programming tools such as VS Code. In VS Code, it includes such items as Intellisense, language server, TAB complete, and other modern programming tooling. Just like ARM templates, all state management is stored in the cloud in Azure. When collaborating with a team, it is on a single definition and single deployment. When combining Azure Bicep files stored in Github with a deployment stored in Azure, you can do everything you need to do, even using a stateless web browser, tablet, or phone. No matter what happens to the device, the deployment can still be successful since the requirements are all stored in the Azure cloud.

To understand the benefits of Azure Bicep more fully, let’s take a closer look at Azure Resource Manager and ARM templates to see how these components are used in Azure Bicep.

What does ARM stand for in Azure?

ARM is an acronym that stands for Azure Resource Manager in Azure. Azure Resource Manager (ARM) is the native platform for Infrastructure as Code in Azure. The Azure ARM deployment and management services provide a management layer to create, modify, and remove Azure resources. For example, when a DevOps engineer sends a request from a tool such as Terraform or Azure Bicep, the Azure Resource Manager authorizes the user and then sends the request to the Azure service, which then acts.

Azure Resource Manager in Microsoft Azure (image courtesy of Microsoft)

What are Azure ARM templates?

An Azure ARM template is essentially a JSON file that defines Azure infrastructure and configuration in your environment. It allows using a declarative method of deploying infrastructure in an automated way and using the practice of Infrastructure as Code. The ARM template code can then be stored in a code repository with versioning benefits.

Key benefits to using Bicep as transpiler for ARM templates

With a better understanding of Azure Resource Manager and ARM templates, note the following key benefits of using Bicep as a transpiler for ARM templates:

• • Day 0 support for all Azure resource types and API versions – Bicep has been designed such that it automatically supports all preview and GA versions for Azure services

• • A human-readable syntax that is simple – It provides a drastically improved experience working with Bicep code vs. the raw JSON files of the ARM templates

• • Strong VS Code integration – Microsoft has built-in strong support and interaction with Visual Studio Code

• • Modular with strong code-reuse – It provides a modular design and easy code-reuse

Bicep VS Code integration

• • Azure service integration – It integrates natively with important Azure services such as Azure Policy, template specs, and Blueprints

• • No state files to manage – State is automatically stored in Azure. So, there is no state data to maintain

• • Open source no-cost solution – Bicep is a freely available tool from Microsoft, freely supported

Azure Bicep Examples

Azure Bicep is an extremely intuitive and human friendly Infrastructure as Code scripting language, especially when compared with JSON and other formats. Below is an example given by Microsoft to deploy a storage account using Azure Bicep:

param location string = resourceGroup().location

param storageAccountName string = ‘toylaunch${uniqueString(resourceGroup().id)}’

resource storageAccount ‘Microsoft.Storage/storageAccounts@2021-06-01’ = {

  name: storageAccountName

  location: location

  sku: {

    name: ‘Standard_LRS’

  }

  kind: ‘StorageV2’

  properties: {

    accessTier: ‘Hot’

  }

}

Bicep vs. Terraform

Both Azure Bicep and Terraform are powerful configuration languages for provisioning infrastructure. How does one choose between Azure Bicep and Terraform? Is one better than the other? To begin with, Azure Bicep is an Azure-only solution at this point. If organizations are heavily or solely using the Microsoft Azure cloud to house infrastructure, Bicep is undoubtedly worth looking into for organizations using ARM templates. Terraform is a much more multi-purpose configuration language that can interact with multiple public cloud environments, not just Azure.

This first point is undoubtedly a critical delineation between the two solutions and choosing between one solution or the other. When selecting a configuration language and multi-cloud is required, the discussion stops there – choose Terraform. However, as mentioned, if organizations are heavily using ARM templates and Azure in general, this is where Bicep shines. So, from the standpoint of Bicep vs. Terraform in Azure, let’s compare features and functionality between the two.

To properly protect your Hyper-V virtual machines, use Altaro VM Backup to securely backup and replicate your virtual machines. We work hard perpetually to give our customers confidence in their Hyper-V backup strategy.

To keep up to date with the latest Hyper-V best practices, become a member of the Altaro DOJO | Hyper-V now (it’s free).

Conclusion

As businesses decide on their Infrastructure as Code configuration language of choice, many factors need considering. For example, many companies are now running business-critical infrastructure in multiple clouds. For that use case at present, Terraform is undoubtedly the go-to option there. It supports over 100 providers that allow it to communicate with many different clouds and IaaS, PaaS, and SaaS environments.

Microsoft is working on bringing multi-cloud support to Azure Bicep, however, it will most likely be some time in the future before that is the case. It will be interesting to see how Azure Bicep handles state and other components once out of the native Azure environment.

Terraform is the more mature of the two solutions for Infrastructure as Code configuration languages. This fact may hold sway for businesses looking for maturity and the features that have been added to Terraform over time. However, as stated earlier, Azure Bicep is written by Microsoft as an Infrastructure as Code offering tailored explicitly to Azure Resource Manager (ARM) templates. Therefore, it already has features for ARM templates and automation that are lacking in Terraform.

For organizations starting a greenfield deployment of Azure infrastructure and having no prior investment in other configuration languages such as Terraform, Azure Bicep would be a great option. It offers a simple language that allows condensing the native ARM JSON templates exponentially. It supports all features and services in Azure immediately, even those in preview, and it has deep integration with other Azure services such as Azure Policy. The popular VS Code IDE (another Microsoft product), as you would expect, has robust features and supporting functionality for the Azure Bicep configuration language.

Whichever tool is selected, DevOps workflow practices based on Infrastructure as Code are undoubtedly the way of the future. DevOps and IaC allow a much more nimble and developer-minded approach to cloud-native infrastructure. Using a configuration language such as Azure Bicep or Terraform, businesses can quickly and easily automate cloud infrastructure, supporting their modern applications and development pipelines.