Why would you choose Microsoft’s new Bicep DSL over HashiCorp’s Terraform? I would like to give you my perspective, as someone who ditched ARM templates for Terraform in most of my Infrastructure as Code projects. To set the context of this blog post, I’ll be talking about Azure focused customers. Also, I won’t be going over the basics of what Bicep is (that can be found in README here) or comparing it to other IaC solutions like Pulumi or Farmer. If there is interest, I can cover those in another blog post. This will be a direct comparison to Terraform.
Note: Opinions expressed are solely my own and do not express the views or opinions of my employer.
Don’t get me wrong, there are some great reasons to use Terraform. Multi-cloud support is one of them. Or for some of you who already have large investments in Terraform, starting over may not make sense. If that’s the case, you’re still in good hands. There is a dedicated team at Microsoft responsible for making Terraform on Azure as good as it can possibly be. However, there are some benefits that come with the first class, Azure native, experience of Bicep:
Day zero support for all resource types & API versions
With Bicep, there will be day 0 support for new resources. Similar to ARM templates, the schema of the resource provider is used directly. With Terraform there is potential for a delay between new Azure resources being released and them being available to create in Terraform. A Terraform community member must add any new Azure features to the Azure Terraform provider. Yes, you can have Terraform deploy an ARM template or use the Azure CLI, but that can get messy stringing it all together, and none of these resources will be tracked by TF state.
No state files
Terraform’s source of truth is the state file, which comes with some baggage. With the state file, you have an extra file that is critical to your deployments that you need to manage and keep safe. If you lose your state file or it gets overwritten, you could be in a lot of trouble. With Bicep, the state is maintained by Azure. You can perform a what-if (TF Plan equivalent) operation without any state file management. Azure IS the state.
Bicep/ARM does preflight validation on the entire template, so you can fail fast. Resource Manager checks the template before starting the deployment to make sure the deployment will succeed. Because of this, your deployment is less likely to stop in a half-finished state.
The Terraform VS Code extension leaves a lot to be desired. The Bicep extension is superior in many ways. It gets you rich validation and Intellisense with GET properties from the Azure Swagger documents of the resource providers. The Intellisense can even see into modules, to assist with inserting parameters.
In addition to the VS Code extension, you can use the web-based Bicep Playground. This is an interactive playground where you can author Bicep code and have it auto-generate the corresponding ARM template without needing to use the CLI. It also has features to share links to your playground, insert example templates, and even decompile an ARM template into Bicep code.
What’s stopping you?
To see a simple example of Bicep code that deploys a common architecture (app+data+identity+monitoring), take a look in the Bicep examples folder here: bicep/docs/examples/301/web-app-managed-identity-sql-db at main · Azure/bicep (github.com)
It’s still early days for Project Bicep and it’s not yet production-ready; but when it is, as an Azure customer, would you choose Bicep over Terraform? If not, what would prevent you from making the switch? I would love to hear your thoughts in the comments below.