A few months back, we had to migrate a client’s infrastructure setup from their data centre to Amazon Web Services ( AWS ). The requirements were to use a VPC and all the general security measures that Amazon has to offer around it. While deciding the tool to be used for setting up the infrastructure, we scrutinised CloudFormation, Elastic Beanstalk, OpsWorks and Terraform initially. Lets not delve into why we rejected Beanstalk and OpsWorks ( that could be a different post altogether ); finally the decision was between CloudFormation and Terraform. We went ahead with Terraform, although, in this post, I am going to give an unbiased view of how these two tools compare to each other as of today and what might be suitable to use when.

1. Vendor Neutrality

Terraform is vendor neutral. It describes resources for multiple popular providers like AWS, DigitalOcean, Google Cloud, CloudFlare, Heroku, Consul and some more. On the other hand, CloudFormation is an Amazon product and hence obviously there is vendor locking. So, if vendor neutrality is your need, then Terraform can be the answer.

2. Support for standard AWS components

Currently, Terraform does not support all the AWS resources. Resources for VPN Gateway setup, VPC peering etc. are missing. However, Terraform is open source and is written in Golang, so you can always contribute to it. CloudFormation is packed with all the resources you will need.

3. State management

State management is currently the “chink in the armor” for Terraform and I would like to elaborate on this. Terraform manages state via a json file. This file serves as the source of truth about what the actual environment contains. However, the problem is the inability of terraform to uniquely identify resources that it creates.

This is how terraform works – It maintains a local state file where it keeps track of any CRUD operations that it performs. Whenever terraform is invoked to perform any operations, it compares –

a) resources defined in the template files by the developer.

b) and the local state file.

Now take the state file away and everything will be lost, it will again recreate all the resources that are defined in the .tf files. This means the state file needs to be shared between developers and that can lead to chaos!

CloudFormation, on the other hand has no state. Multiple developers can work on the same environment / stack without worrying about polluting it.

4. “Infrastructure As Code”

Terraform provides a DSL to setup the different resources. However, it lacks the common logical constructs found in most programming and scripting languages. It does not have any looping constructs and does not support conditional statements. CloudFormation templates are written using json. So, here too there are no constructs but there are some popular Ruby gems like cfndsl which provide a better abstraction over the json.

5. Infrastructure Updates

This is the absolute killer feature of Terraform. Terraform has a separate planning and execution phase. The planning phase shows which resources will be created, modified and destroyed. It gives you complete control of how your changes will affect the existing environment, which is quite crucial. This was one of the main reasons why we went ahead with Terraform. CloudFormation does not show you what changes it is going to make to the environment. At times, it might end up deleting resources without prior notice. The main drawback is that developers are forced to mentally reason about the effects of a change, which quickly becomes unmanageable in large infrastructures.

6. Roll back Mechanism

If a resource is successfully created but fails during provision, Terraform will error and mark the resource as “tainted.” In the next execution plan, Terraform will remove the tainted resources and will attempt to provision again. This is because it follows the execution plan very strictly. In CloudFormation, if a resource creation fails then the entire stack is rolled back by default and sometimes the roll back also fails resulting in frozen stacks which require Amazon technical support.

7. Stability and Community Support

Terraform recently released version 0.3.5, it is not completely mature and stable but it is moving in that direction. It is an open source tool managed by Hashicorp, the renowned creators of Vagrant, Packer and Consul. CloudFormation is a stable tool being used for quite some time and is managed entirely by Amazon.

Conclusion

As you can see, overall both Terraform and CloudFormation have their pros and cons. The reason we went ahead with Terraform was that the planning phase was quite important for our workflow. Also, we had a workaround in mind to solve the state management problem. Regarding the missing resources, we started contributing whatever was essential for us.

So, thats all folks! Based on your requirements and priorities you will need to decide which one of these tools is more suitable for you. Hope this post gives you an insight into making that choice. Do post your suggestions and feedback. Happy coding!!