It's Cloud Agnostic, and it makes Life easier but consider its Limitations...
No one software product is perfect, including Infrastructure As Code (IaC) products such as Hashicorp's Terraform. Many differ on the actual value Terraform has to offer but as an Open Source Software fan, I have to say I like Terraform as an IaC product for software deployments and/or configuration maintenance.
Some key benefits of Terraform are as follows:
- Uses common communication protocols such as SSH and WinRm for agentless communication with target resources
- It is a cloud platform-agnostic tool that is easy to understand for the engineer using very clear basic syntax along with JSON for datastore in its state file
- Terraform supports encryption at rest
- It is flexible with remote or local states, although remote is a centralised and more securable option
- It will track via state file the deployments, creation/updates to resources and can delete those resources very easily
- It is efficient at scale given its agentless architecture
- It has a great open source community so troubleshooting is made inherently easier with the vast amount of online resources, tips, answered questions, etc
All of that good stuff is blanketed across the board of use cases, but more enterprise-related use cases do present with limitations. Some of these I have found as follows:
- Given its open-source lineage, not all public providers (platform related tools) are supported by the respective vendor who enables the open-source development of their product integrations for Terraform. This leaves questions open around development security, dependency vulnerabilities in providers as an abstracted package called by pipelines. Enterprise use cases with elevated security requirements may want to consider this as would others. When we think of the recent Log4J security issue, infrastructure as code deployments and security come sharply into focus.
- Whilst I love the flexibility Terraform provides, provisioners for spinning up resources are not recommended by Hasicorp Terraform themselves. Creating target resource actions (e.g. commands normally in user data for VM deployments spinning up Apache Server over the VM layer) present an issue due to them being in isolation from the Terraform state file. This makes it untrackable by the Terraform state file with only explicit destroy commands possible. Whilst it's accepted that declarative commands in Terraform are never complete, the overreach possible with provisioners can create debugging and possible security issues. I would advise considering native options (e.g. User Data feature in AWS/Azure VMs) before considering provisioner command blocks in your Terraform configuration to fill the gap declarative commands in Terraform have left.
- Limitations in Terraform around secrets management, changes in your code paths, tagging, etc can make the basic command language tricky and difficult to maintain consistently.
- A standard set of modules for key features and syntax does not seem to be there, which I can only assume is on Hashicorp's roadmap so project requirements, security assessments and product selections (AWS/GCP/Azure/etc) are key in considering Terraform as a good fit for your project.
This brief look at the product does not detract from its usefulness or effectiveness as an IaC product, instead advising caution in terms of setting out your context for its use to maximise your best chances of success with this innovative IaC product. Stay tuned for more on DevOps in this blog along with articles on other areas of interest in the Writing and Infrastructure arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!