Bicep Is Not Trying To Compete With Terraform

As you probably know, I talk quite a bit about Bicep. Invariably when I do, I get a comment or question like “why would I switch from Terraform to Bicep” or “This is pointless, Terraform already does all this”. Well, here’s the secret: if you’re using Terraform and are happy with it, then Bicep isn’t aimed at you!

Microsoft’s primary goal when creating the Bicep language was to remove the barrier of entry when using Infrastructure as Code in Azure. In particular, to simplify ARM templates, move away from the complex JSON syntax that provided, and make it easier for those new to Azure or IaC to get started without a steep learning curve.

Syntactically Bicep can be pretty similar to Terraform, and I’m sure that Microsoft took some inspiration from HCL when creating the language. Still, it was not designed to compete with Terraform. Microsoft gets the same income from your Azure resources whether you create them with Terraform or Bicep (maybe even slightly more with Terraform if you count the additional storage cost for your state file). The Bicep GitHub repo explicitly calls out that Bicep is aiming to make the experience with ARM templates better and to improve the new user experience:

Why not focus your energy on Terraform or other third-party IaC offerings?

Using terraform can be a great choice depending on the requirements of the organization, and if you are happy using terraform there is no reason to switch. At Microsoft, we are actively investing to make sure the terraform on Azure experience is the best it can be.

That being said, there is a huge customer base using ARM templates today because it provides a unique set of capabilities and benefits. We wanted to make the experience for those customers first-class as well, in addition to making it easier to start for Azure focused customers who have not yet transitioned to infra-as-code.

If you are already using Terraform happily, then there is likely no reason to consider switching to Bicep, which is fine. The only scenario where I would consider a switch is where you are purely deploying Azure resources and your not making much use of the stateful nature of Terraform (you don’t care for Preview, Destroy etc.). In this scenario, Bicep might be a more straightforward approach because you don’t need to manage a state file and have any “onboarding” process when creating a new project or environment. But other than that, if you are happy with Terraform, then there is no reason why you would migrate to Bicep, and that’s ok.

If you’re currently using ARM templates to deploy your Azure resources, moving to Bicep makes a lot of sense. It’s much easier to work with, especially with some of the more advanced techniques. Modules, for example, are far easier to use than nested ARM templates, functions are easier to consume, and it is generally easier to read and write Bicep templates than ARM. If you already have existing ARM templates, you’d want to evaluate whether there is value in migrating your existing templates, but certainly, for new templates, I would recommend using Bicep.

If you are brand new to infrastructure as code, starting with Bicep is not a bad idea. The language is much simpler and easier to pick up than ARM templates, and I would argue that it is quicker to start deploying than Terraform. There is no need to set up state files, providers etc.

Now, if you need the features of Terraform, particularly the ability to deploy non-Azure resources, then, of course, it makes sense to start directly with Terraform, but if you’re just doing Azure deployments, then you might want to consider starting with Bicep. All in all, it’s about using the right tool for the job. If you just need to deploy Azure resources and want the most straightforward approach, then look at Bicep. If you want to deploy to multiple clouds, want the preview/destroy command, or if your company standard is to use Terraform, then use Terraform. Your choice of IaC tooling should be based on what works best for you, not what anyone else thinks!