How we opted for Terraform at GSoft

Published in

Workleap

5 min readMar 1, 2023

In 2022, we had to define our technological vision and strategies for the upcoming years. One of the goals was to reduce the technological spread we had and build a deeper expertise in some areas.

Our reality

All our products were created in-house, and that gave us complete control over the creation process and the technologies used.

Microsoft Azure was our cloud provider, and with people’s knowledge at the time, it only felt natural to use their infrastructure as code (IaC) and automation technologies, ARM templates.

Later on, along with ARM usage ever increasing, a few teams started using Terraform. I always recognized that ARM had a steep learning curve, and for some people, it provided an uncomfortable authoring experience. With that in mind, and after some time, it was acknowledged that ARM & Terraform were both the possible options for IaC at GSoft.

Azure heard the feedback of people about ARM Templates being difficult and this is how Bicep was born.

In 2022, we were in the process of migrating out ARM templates to Bicep.

Why change?

It was in 2022 that we defined our strategies. Among other areas, we wanted to improve and develop a deeper expertise in infrastructure as code.

We wanted all teams to be autonomous when it comes to IaC. The reality is that too few people were proficient doing IaC. It wasn’t scaling near where we wanted to go in the future, we needed to change that.

With both Azure and Terraform in the house, we knew we were wasting energy. We’re being spread out instead of efficiently focusing on deepening our expertise in one tool and building quality reusable enterprise assets.

There were a few pains using Azure’s tooling, as with Terraform.

For Bicep:

Poor what-if support, a lot of false positive
Complete deployment mode not as robust as in TF, more incremental
Azure only

For Terraform

State can be a nightmare to work with
Moving to a new paradigm often requires a lot of resource MOVE operations
Difficult to debug

We wanted to take a step back and see if something better was out there. If not, we'd decide which one would remain before starting to train a lot of people.

We also wanted to make sure it’d be aligned with the company’s vision and aspirations, which was a strong possibility to perform acquisitions in the future.

Selecting the tool

We decided to gather with a few people that were already doing IaC and brainstorm with them.

It’s no surprise for anybody at GSoft that I had a big preference for Bicep, Azure’s new tool. At that time, I was a core community contributor to Bicep, having a weekly meeting with Bicep’s product team. I was helping the community, answering questions and contributing to Bicep code. I can say without hesitation that I had Bicep tattooed to my heart.

For that exercise, of brainstorm and voting, we created a Miro board to help us contribute and work asynchronously on this. We asked people to come open-minded and detached from personal biases to the exercise. We wanted to focus on what’d bring more value to the business and where we were headed in the future.

We came up with the following preliminary list for determining if a product could make the cut:

Declarative IaC language
Modularized construct
Day 1 cloud providers APIs support
Strong Azure services integration
Resources lifecycle management
Preflight validation / policy validation
What if / Progression testing support
Rich authoring experience
In house knowledge
Community support
Rich documentation
CI/CD pipeline support
Acquisition-friendly (supporting multiple cloud providers)

After a few research and discussions. We decided to focus on the two who had stronger street creds, better community support and that we already had experience with: Terraform & Bicep.

There were really no advantages for us to go with other tools than these 2. Nothing against the other tools out there, just not a good fit.

From there, we decided to compare the two and came up with this table:

We then asked the people participating in the brainstorm to create Post-it with their thoughts that falls into three categories: risks, pros & cons for Terraform & Bicep.

Here is a few of the feedback that got expressed:

Terraform:

Risk: ARM/Bicep to Terraform migration / import of resources
Pros: User interface
Pros: Easy integration with Secret Vault
Cons: At the mercy of the Azure Provider being updated
Cons: Import is more complicated
Cons: State can be very difficult to work with

Bicep:

Risk: Smaller hiring pool
Risk: False positive in what-if might trip up automated workflows
Pro: Direct import from the Azure portal
Pro: Smoother interaction with built-in Azure policies & remediation
Cons: What-if trigger way too much noise

Now we had an objective comparison grid and people’s perspectives and experiences with the post it, we asked people to vote.

Yes to vote. We wanted the people to be part of the process and not decide that in our corner alone.

The Result

With 70% of our Infrastructure as Code on Bicep and 30% Terraform, it is easy to think that Bicep would win hands down. Just because of people’s experience and global preferences.

We reiterated before the vote to people that acquisitions would occur in the future and that the probability of people’s expertise coming in should weight. Same thing for the hosting platform, what would be the chances of the next company being on Azure with Bicep?

We asked them to vote for GSoft’s best interest in mind.