A previous post of mine highlighted the flexibility that Azure DevOps provides for automation across a wide spectrum of products. In that example, I deployed AWS infrastructure via ADO Pipelines using Terraform configured with an Azure backend. That example worked fine for my use case, but just because you can do something doesn’t always mean you should. Considering that Terraform was my deployment tool of choice, I looked into other options to see how I could simplify my toolset and still obtain the same outcome.
Terraform Cloud was the first choice that came to mind. Terraform Cloud is a SaaS product from HashiCorp that comes with a great set of free options, in addition to paid offerings for larger organizations. While Terraform Cloud does allow the ability to collaborate on infrastructure as code (IaC) for up to five free users, the paid options include many additional benefits, not limited to:
- Team Management and Governance (w/ Sentinel Policy as Code Management)
- Advanced Security and Compliance
- Self-service
- Cost Estimation
- Concurrent Runs
For the purpose of my demo, the free version of Terraform Cloud was more than sufficient to provide a quick comparison against my previous environment. Before I get into the specifics, let me explain what a Terraform Backend is and why you would want to utilize one. A backend is essentially a place to store a Terraform state file that also allows for remote executions of Terraform. A local backend is used by default, which is why you don’t necessarily need to declare a backend when running Terraform from your local workstation. A remote backend is something that comes into play when collaborating on IaC as a team. It allows for a centralized remote location for state files, keeps data/code off mobile endpoints and enables remote operations. Many backends are compatible with Terraform, including AWS, Azure, GCP, Kubernetes and of course, Terraform Cloud.
To get started with Terraform Cloud, I logged into my account/organization and first created a new Workspace. When creating a Workspace, you have the option to choose from a version control workflow, CLI-driven workflow or API-driven workflow. To keep in line with my ADO environment I stuck with version control.
Once your workflow is chosen, you can connect your favorite version control system (VCS) where you store your code. Terraform Cloud doesn’t provide its own VCS like ADO does, but has plugins to all the major VCS providers.
After choosing and connecting to your VCS, you can select a specific repo in which to install Terraform Cloud. For this demo I simply created a new repository in my account and selected that repo for the Terraform Cloud install.
Once the Workspace settings were fully configured and the new Workspace was created and plugged into my GitHub repo, I was ready to roll. Out of the gate, you can see that you have tabs to show Runs, States, Variables and Settings. There is also a button that allows you to manually queue up a plan, as well as apply the plan should it finish successfully.
As you can see, Terraform Cloud is very intuitive and easy to navigate. Adding environment variables is straightforward and allows for sensitive values to be written. My ADO project required a number of environment variables that allowed me to connect an Azure backend. With Terraform Cloud, I only needed AWS keys to build the actual infrastructure since the backend was already inherently part of my Terraform Cloud Workspace.
You can also view past runs and corresponding states from within the main Workspace screen. I chose to manually use the Queue Plan button to test my runs for the demo, but you can simply commit changes to your VCS repo to trigger a plan as well. Once a plan is run successfully, you can apply the plan or discard the run.
Applying the plan sets Terraform in motion. Once applied, Terraform will deploy the infrastructure as defined in your code, store the state in your Workspace and show you the results of the apply. It does all this through a built in virtual machine used to perform remote operations. Where ADO requires you to provision an agent VM if need be, Terraform Cloud provides it by default as part of the service. The virtual machine displays the run as well as any defined output, so you get the same look and feel as if you were running Terraform on your local workstation.
virtualBonzo’s take
It’s hard to answer the question posed in the title of this post. Like so many other things, what is best always comes down to your specific use case. I found Terraform Cloud much simpler to consume then Azure DevOps … for deploying IaC with Terraform! Azure DevOps has TONS of potential use cases. With any product that can do lots of different things, there can be a good bit of complexity involved. ADO is more than capable of deploying IaC and that may be enough for organizations that already utilize ADO (or other similar products) as their central DevOps hub. It isn’t geared specifically for Terraform, but it balances that with being capable of many other things.
Terraform Cloud really shines for organizations that want a tool specific to Terraform itself. It is very easy to use and manage. For shops that need centralized of their management Terraform and don’t mind it being a separate tool, Terraform Cloud is a great option. It has a great set of free features that may be more than enough for smaller organizations and certainly individuals. If you are looking for the best way to collaborate and maintain your Terraform code, look no further than Terraform Cloud.
