Terraform Is (One Of) The Best Tools For Managing Infrastructure
Pros and Cons
In a modern Cloud Computing environment, most of the time it is not feasible or practical to manually go in and add, edit, and otherwise manage your resources. Some of the reasons include but are not limited to unintentional stack drift, highly time consuming, and potentially more expensive if you do not properly setup and size your resources correctly.
As with everything else, we can make things easier and reduce human error by implementing automation where we can, which is where Terraform comes in. In a nutshell, Terraform is a cloud agnostic tool that uses a language called HCL (similar to JSON) to track and define templates, and manage your resources.
What cloud agnostic means, is that you can use it with any provider (AWS, GCP, Azure, etc.). You only need to reference the documentation and see what the specifics are to deploy and manage a given resource within your architecture using a particular provider.
As with anything else, there are some pros and cons to using terraform as opposed to the templating service other providers will have specifically for their services (CloudFormation, ARM templates, etc.). However, I think that the pros outweigh the cons just enough to make Terraform a viable option for managing your infrastructure as code.
One of the most obvious benefits is in regards to pricing, seeing as to how Terraform itself is free (of course the resources you provision are not free). When compared to CloudFormation pricing though for example, you are going to pay based on how many handler operations per month you have per account. When we are designing the best possible architectures we always want to consider cost savings where we can, as that is one of the biggest benefits of cloud computing.
Another benefit is that you can use something like Terragrunt to do multiple things like keeping your code DRY (Don’t Repeat Yourself), easily managing remote state files, and running commands across multiple modules. Essentially, you can cut down on the amount of manual labor you have to put in to configure and track changes in your architecture.
I also like Terraform because it has essentially the same templating as a cloud computing provider’s native service, such as inputs, parameters, resources, outputs, etc. So if you are already familiar with one of these technologies it will be a pretty low learning curve to pick up the rest.
Finally, as I mentioned earlier, Terraform is Cloud Agnostic. Many businesses nowadays see the value in leveraging multiple cloud providers, for example maybe they use Azure for their storage solutions and AWS for their computing workloads. With Terraform, you can configure and manage resources from both providers using a single configuration. There is no need to hop back and forth between different consoles or CLIs and try to keep track of what you have done and still need to do. Again, the more we can automate and simplify the easier our life would be (working with tech is hard enough!).
I wouldn’t be doing my job if we didn’t mention some of the drawbacks to using Terraform. Off the top of my head, the most immediate one that comes to mind is that there is no automatic rollback function for incorrect changes to resources. With a native solution like CloudFormation, if something goes wrong then it will automatically roll back your changes so your architecture is in the state it was in before it hit the error.
However with Terraform, you will simple receive an error when you go to deploy about which resources had a problem, but it will still deploy other resources if they did not have any issues. So if you have larger more complex architectures it could potentially lead to some confusion about what did or did not successfully deploy.
Another drawback is that while Terraform will support the most widely used and popular resources in each provider, it doesn’t necessarily cover all of them. As compared to a native solution which would more quickly encompass new services being developed and released, with Terraform you are slightly limited in which ones you can use. Though as I mentioned it covers the major resources, so this wouldn’t really apply unless you had a specific use case.
Finally one drawback to consider is that you need to continuously update the version specified in your templates, as there are bugs to be found in certain versions. Additionally, if a new version is released (which is relatively often), your older version may no longer be supported in regards to specific functionality. Luckily, it is a relatively easy fix and if you have a remote state file you can always just update that one source with the correct version and all of your local templates will know what version to reference.
Hopefully this helps you to at least consider the possibilities available to you to better and more efficiently manage your architecture.
If you are currently manually editing and managing your architecture then you are certainly behind the curve. Make your life easier and start leveraging tools to automate and track changes for you, regardless of if it is Terraform or a service native to a specific cloud provider.
As always, best of luck in your continued journey through cloud computing.
