Choosing between Azure tools? Having a traditional version-controlled code made maintaining a consistent underlying infrastructure that deals with multiple environments like development, staging, and production challenging for a long time. There’s a tendency for those environments to drift out of sync unless they’re maintained manually, and that can cause problems further down the line.
Enter the concept of infrastructure defined as code.
Cloud-based solutions from modern machine learning tools to automated QA testing software offer advantages in terms of everyday functionality. It’s no surprise that as these have become more popular, Infrastructure as Code (IaC) tools have begun to take off.
In this article, we’ll look at two of the most popular Azure tools– Terraform and Bicep – with particular reference to how well each of them gets along with the Azure cloud computing platform.
What Is Infrastructure as Code?
The growing popularity of cloud adoption strategies has been instrumental in the increasing relevance of IaC. That’s because, in public cloud environments, developers can’t access the underlying infrastructure. Instead, cloud providers offer console-based interfaces to allow you to work with the resources you need.
IaC involves describing infrastructure using code blocks, so it’s a convenient way of working in this context. Interacting with this infrastructure programmatically precludes the need to use the GUI console. What this means is that actions can be performed and resources created and configured in an automated way, including vital ones such as patch management.
The code is declarative, meaning you determine which form you would like the infrastructure to take, and the code implements your decision.
If you consider the kinds of use cases Apache Hadoop is used for, you can see that this sort of infrastructure automation is a modern marvel. The wide variety of configurations and resources deployed on the cloud is a testament to the flexibility of this approach. But it also means that sometimes, infrastructure needs to be scaled, provisioned, or destroyed – much more complex jobs if you don’t have an IaC solution available.
The benefits of IaC don’t end there, though. Another big plus is that it makes versioning possible: you can version changes to the code. In practice, this also means that you can capture versions of the infrastructure itself, using a version control tool to track changes.
This incredibly useful functionality was never possible when working with physical infrastructures and represents a real step forward. It also makes it much easier to implement downstream processes such as data orchestration and the flexibility and adaptability it offers are not to be sniffed at.
So let’s look at the first IaC tools we’re considering here: Hashicorp’s Terraform.
Hashicorp Terraform
Hashicorp Terraform is one of the best-known IaC languages in widespread use today. The open-source tool is free to download from the Hashicorp site. It allows you to write declarative IaC using configuration files in Hashicorp Configuration Language (HCL).
Terraform has been downloaded over 100 million times, and it’s easy to see why. Its syntax is very intuitive and developer-friendly, so you can quickly pick it up and get started without wasting too much time. Even if you’re working with complex infrastructures, you can write them in a way that is straightforward and easily readable to other humans—which is always good news.
Terraform works by generating an “execution plan.” This plan sets out what is necessary for Terraform to create a described state of infrastructure from the configuration files. Terraform tracks the changes to the infrastructure and adapts new execution plans to make incremental improvements. The kinds of infrastructure it can be used for include (but are not limited to):
- Storage
- Networking
- Compute
- PaaS
- SaaS
- DNS
- Other complex cloud architectures
There are a few concepts it’s useful to know about when you’re getting to grips with Terraform.
Resources: a fundamental concept in the Terraform language, this refers to anything which describes an infrastructure object such as a DNS record or a virtual network.
State: the state information maps real-world resources to your configuration. It tracks metadata and decides which changes to make to resources to improve infrastructure performance.
Providers: Your plugins. In other words, you tell Terraform which technologies it will need to interact with your infrastructure according to the specific code you’re using, and Terraform pulls them down during the initialisation stage.
Modules: a group of .tf or tf.json files stored in the same directory that are often used together.
Part of the appeal of Terraform is the fact that it’s host-agnostic and, therefore, can be adapted for use with many different platforms. You can deploy Terraform IaC with all aspects of Hadoop components and the results will be scalable and flexible.
If you’re working with Azure, it’s good to know that Terraform does have support for it. However, it’s possible too that you may prefer a native solution, in which case you might be looking at Microsoft Bicep.
Microsoft Bicep
At base, Microsoft’s Azure Bicep is a transpiler. That’s to say, it takes code written in a new language and translates it into another at the same level of abstraction. In this case, that means translating it into the Azure Resource Manager (ARM) templates you are already familiar with. Because it’s a native solution, you can be 100% certain that it will be able to access any service you need to use in Azure from the very beginning.
It is a Domain Specific Language that you can use to deploy Azure resources declaratively. State management works differently in Bicep than in Terraform. While Terraform uses .tfstate files, Bicep performs a direct query on Azure to determine the difference locally between the current resources and the desired state from the Bicep files.
This means you don’t have to keep up with state data as you do with Terraform. Deployment and management are curated using the ARM. Of course, it might occur to you to wonder why you wouldn’t just use ARM templates natively rather than involving Bicep. The reason is that the Bicep syntax is much more intuitive to read and makes the entire process easier.
Of course, one standout difference between Bicep and Terraform is that Bicep is an Azure-only platform. That’s fine if you’re simply working in Azure, but it’s worth looking more closely at some of the differences between these two IaC tools.
Differences Between Terraform and Bicep
Any cloud-first strategy will involve choices, and the choices made have to be relevant to the resources available and the goals of your project. So it’s crucial to be aware of the principal differences between Terraform and Bicep.
Platform support: The most apparent difference. As we’ve already seen, Bicep is Azure-specific, whereas Terraform is host-agnostic.
Native Azure services integration: This is a plus with Bicep if Azure is what you’re working with. Terraform does offer support for Azure, but not to the same level.
Maintaining state data: In Bicep, state data is maintained within Azure, whereas with Terraform, it is stored locally or in a cloud.
Community support: Terraform is the undisputed winner here. If you’re working with Pandas DataFrames and you suddenly find you have an obscure issue with Terraform, someone in the community will be able to suggest the code you need. On the other hand, Bicep is relatively new, so that level of mutual support isn’t quite available yet.
Azure Tools, Which Is Better? Terraform or Bicep
Only you can decide. A lot will depend on the nature of your organisation and its operational aims. If you’re working for a DevOps consultancy, you’re going to be facing very different considerations than if you work for a trade company implementing wholesale warehouse management. The use cases matter.
One aspect to consider is how much critical infrastructure is being run on multiple clouds. If it’s a lot, then the answer is easy. Go with Terraform; its support for over a hundred different providers means it’s ready to go when dealing with communicating with multiple clouds.
The fact that Terraform has been around longer also means it’s had time to develop to a greater level of maturity. It’s a tried and tested product, and for many organisations, that will make it a safe choice.
Nevertheless, you should not discount Bicep. Microsoft is working on equipping it with multi-cloud support, so watch this space. If you’re looking to implement a solution from scratch and you’re using Azure infrastructure, Bicep could be perfect for your needs. After all, it uses a simple language that permits you to condense the native ARM JSON templates exponentially and is already well integrated with all Azure services.
Decisions, Decisions…
Both azure tools are excellent at what they do. The advent of Infrastructure as Code has led to a sea-change in DevOps that has opened up all kinds of avenues for innovation. Whichever you decide to go with, you can be sure that you’re using one of the best top-end tools available to support your organisation’s cloud infrastructure and its development pipeline.
