Terraform vs The Rest

Terraform (tf) is an open-source tooling (offered in enterprise editions by HashiCorp) used to provision cloud services. For those looking to decide between tf and the various managed alternatives provided by AWS/Azure/GCP/other cloud vendors, in this post I’ll run through a high-level comparison to list out the pro’s & con’s of tf vs the other.

Photo by lanah nel on Unsplash

Comparisons

Speed of iteration

With >1,000 active contributors participating in its development as an open-source tool, tf is often first-to-market in terms of being able to configure resources, even beating CloudFormation itself for AWS, Azure Resource Manager itself for Azure, and Cloud Deployment Manager itself for GCP. Those provider-managed tools have become associated with the term “support lag” as builders are often lumped with a new tool they’re unable to provision using modern IaaC principles even though they’re strongly encouraged by the providers themselves (see the 2017 whitepaper by AWS).

Be cloud-agnostic

tf is cloud-agnostic so you only have to learn one new tool; the alternative (become au fait with one of the providers’ managed services) only leads to increased risk & potential for unplanned work when in futrue you may wish to switch from one provider to another, or start to complement services from one provider with services from another (e.g. bioinformaticians may want to pair Google Genomics with Amazon SageMaker Studio for a domain-specific data science application). To be clear, you cannot:

• use CloudFormation to provision resources in Azure/GCP,
• use Azure Resource Manager to provision resources in AWS/GCP,
• use Cloud Deployment Manager to provision resources in AWS/Azure.

Command style

There are also differences in syntax which might sway a developer picking between tf & others, in that it tends towards a style that is more declarative and less verbose: terraform apply vs aws cloudformation create-stack --stack-name mystack --template-body file://template.yaml. tf uses HashiCorp Configuration Language (HCL) whereas its managed equivalents tend to depend on CLI/SDK toolings that by their nature need to be as service-agnostic as they can (into which configs are injected as JSON/YAML).

This could perhaps be reframed as a demerit for tf which, since its language is specific (i.e. limited) to configuration/deployment/provisioning workflows, is not a versatile CLI/SDK that might otherwise be a catch-all enabling you to perform bucket copying, event triggering, log analysis, and network patchings, all in one place. Advice to builders may well be to stick with some vendor-managed config tool at first, gaining just enough light-touch understanding that they can provision infrastructure using it at the terminal without becoming overly dependent upon it… then swap in tf as soon as we find deployments are taking any significant time away from development activities. You certainly want to avoid the scenario of having scripted a bunch of JSON/YAML that then needs translating into HCL 🤦‍♀️

A nifty feature of tf is the ability to count which accepts an integer representing how many times to repeat a given step. The CloudFormation alternative for instance, is to type/paste the code block multiple times (as many times as you need a provisioning step to be run); this process becomes unsustainable for anything more than 3–4 iterations.

GUI support

tf currently has no GUI available without subscribing to an expensive license. This is perhaps the most severe difference for builders just starting out, who may want to interact with services more visually than via CLI/SDK terminal commands. Another reason why you don’t want to go learning tf right from the startl instead focus on the services specific to your product and domain, then reach for tf once you are ready to automate deployments.

Conclusion

By all means try to avoid having to make the commitment to tf or one of its alternatives (i.e. throw developer time at it in terms of learning curve, throw documentation in the trash in terms of manual steps you may hve written up in the past), til you absolutely have to. But when you come to make that decision make sure to consider tf as the most likely to enable best practice with least technical debt & potential for unplanned work later down the line.

Enjoy!