Terraform is the Perfect Tool for Building Infrastructure as Code
March 31, 2020
Terraform is the Perfect Tool for Building Infrastructure as Code
Score 10 out of 10
Vetted Review
Verified User
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.
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.
Do you think HashiCorp Terraform delivers good value for the price?
Yes
Are you happy with HashiCorp Terraform's feature set?
Yes
Did HashiCorp Terraform live up to sales and marketing promises?
Yes
Did implementation of HashiCorp Terraform go as expected?
Yes
Would you buy HashiCorp Terraform again?
Yes