Terraform is the Perfect Tool for Building Infrastructure as Code
March 31, 2020

Terraform is the Perfect Tool for Building Infrastructure as Code

Michael Jenkins | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with Terraform

Terraform is my team's primary Infrastructure as Code (IaC) application. And while it's not a mandated requirement, it's almost expected that all teams in my organization use Terraform as they build out cloud resources. Using Terraform, we can produce code that can be shared across teams, build common knowledge on best practices for cloud architectures, and build cloud resources quickly.
  • Terraform does a great job of making cloud resources available as code. Essentially, it provides building blocks for the resources available in the cloud.
  • I use the open source version of Terraform and I appreciate the user experience at the command line. Using the switches available, the CLI lends itself to a flow of formatting and validating code before a plan is developed, reviewed, and applied.
  • Managing the state of the resources created with code is tough but Terraform does a good job of this by providing several ways to manage state. My team uses the bucket approach but I have seen teams use object databases and shared files as well. Each approach comes with its pros and cons but at least there are options.
  • During the plan phase, I appreciate that Terraform shows the changes that are about to be applied to resources that already exist. This gives engineers insight into the changes they're about to make, particularly if the changes are not what they expected.
  • I like Terraforms "desired state" approach to IaC, but sometimes I wish the code was a bit more programmatic. Adding counts and "for_each" statements is nice for creating multiple instances of the same resources. But this approach can be difficult to understand for engineers that come from a programming background. A more expressive approach to looping and other coding styles would be nice.
  • A rollback feature would be a welcome addition to Terraform. At the time I'm writing this, when Terraform encounters an error, it stops on the step where the error is encountered and any resources previously created are left in place. While this is desired in most cases, and option for rolling back those resources would provide functionality similar to other IaC tools.
  • Regarding plan output, a minimized report would be appreciated. Currently I have wrappers around the "terraform plan" command that limit the output to key changes. It would be great if there were switches that built this into the tool.
  • Using code, we are able to build and deploy cloud resources faster and more consistently than producing the same resources in the console manually.
  • For applications that share architectures, we can reuse code to expedite development. We can also do the same with modules that are shared across the organization.
  • By defining all of our resources as code, we can deploy complete environments with "batteries included." For example, we can use code that spins up servers in a cloud provider and at the same time, creates monitors with in our monitoring provider. Likewise, when the servers are decommissioned, the monitors are decommed along with them. In the past, the creation and decom of the monitors would have been a disjointed, manual step. With Terraform we get it all with one "terraform apply."
I can't find these applications listed, but other IaC tools I have used include: AWS CloudFormation, Azure Resource Manager Templates, and GCP Cloud Deployment Templates. For a comparable tool, I have the most experience with CloudFormation.

Compared to CloudFormation, the first benefit that Terraform has is the the code format. That is, CloudFormation is more of a document in YAML or JSON while Terraform is more code-like in structure. This makes it more similar to other programming languages that engineers may be familiar with. In fact, the times that I've worked with CloudFormation, I've used other code (Python with the Troposphere library) to generate the CloudFormation YAML.

Terraform also lends itself to breaking out code into smaller pieces. That is, for a single project, different parts of it can be represented in different files. For example, all the EC2 resources in one file and all the RDS resources in another file, and so on. With CloudFormation, all resources are represented in one file. For large projects this can become unwieldy when trying to track down specific resources. For versioned code (and shouldn't all code be versioned?) tracking changes may also become difficult with one, monolithic file.

Lastly, I will mention state management. I _do_ appreciate that CloudFormation manages state for the user without question; it's one less thing to worry about. However, I appreciate the fact that Terraform gives options for storing state and the ability to examine it outside of the resource implementation process. Honestly, this is a minor detail but sometimes it comes in handy.
I have yet to have an opportunity to reach out directly to HashiCorp for support on Terraform. However, I have spent a great deal of time considering their documentation as I use the tool. This opinion is based solely on that.

I find the Terraform documentation to have great breadth but lacking in depth in many areas. I appreciate that all of the tool's resources have an entry in the docs but often the examples are lacking. Often, the examples provided are very basic and prompt additional exploration. Also, the links in the documentation often link back to the same page where one might expect to be linked to a different source with additional information.

Do you think Terraform, by HashiCorp delivers good value for the price?

Yes

Are you happy with Terraform, by HashiCorp's feature set?

Yes

Did Terraform, by HashiCorp live up to sales and marketing promises?

Yes

Did implementation of Terraform, by HashiCorp go as expected?

Yes

Would you buy Terraform, by HashiCorp again?

Yes

I think Terraform is well suited for many use cases for Infrastructure as Code:
  • For long running resources, having a single source of truth for their desired configuration is handy, since that configuration can drift over time.
  • For short running or experimental cases, Terraform code can be used to quickly spin up environments before spinning them down just as quickly.
  • If a reference architecture is needed, Terraform code can be used to describe all the resources that make up a stack.
Terraform has plenty of functions and programming capabilities but it's not a general purpose programming language. I can see someone trying to do everything in Terraform but there are plenty of general purpose programming languages that are better suited for common tasks outside of building infrastructure as code.