Select Page

Comparing Toolsets for Automating Cloud Infrastructure

Comparing Toolsets for Automating Cloud Infrastructure

As organizations begin considering the addition of Cloud utilization within their environments, we frequently see the entry points focused on application development. Specifically, IT organizations need to make the proper environments readily available to developers to facilitate the required pace of innovation in today’s market. Without this capability, organizations risk their first-to-market strategy and increased competition from rival organizations.

Traditionally, application development is somewhat decelerated by the lack of agility and automation within a business’ IT infrastructure. Submitting a service request to the infrastructure team for a test/dev environment is no longer a scalable option due to the increasing responsibilities of an IT operations team. Also, manual creation of environments introduces human mistakes, potentially leading to misconfiguration, security concerns, and delays. These reasons alone are enough for customers to turn to the public cloud for elasticity.

Also, developers are retooling, using things like Terraform or CloudFormation for automated provisioning and destruction of such environments. This ability to create infrastructure as code enables customers to be nimble, repeatedly creating like-for-like environments in minutes. Equally, and just as important, these tools allow customers to deprovision environments, enabling considerable cost savings for environments in addition to the removal of technical debt upon environment destruction.

As mentioned, Terraform is a tool that allows users to build, change, and destroy application environments in minutes. One of the most robust features of Terraform is its capability to manage a wealth of service providers, including AWS, Google Cloud, Azure, vSphere, GitHub, and many others. This ability allows users to simultaneously provision resources across many providers whereas a tool such as CloudFormation predominately focuses on its native platform, AWS. For example, within a single configuration file, Terraform can deploy a database on your on-premises vSphere cluster, provision web servers behind an Elastic Load Balancer in AWS, and update the CNAME record in UltraDNS for a new test environment. Configuration files are written in HashiCorp Language (HCL) {or JSON} which is simple to comprehend and troubleshoot. Terraform can be that single tool developers and operation teams can utilize across many technology stacks.

CloudFormation, on the other hand, primarily focuses on provisioning resources within Amazon Web Services. CloudFormation is accessed via AWS Management Console, AWS CLI, or APIs and can provision and manage resources in almost every service that AWS offers.  CloudFormation templates are composed in either YAML or JSON, both of which can both be challenging languages for newcomers. For purely AWS environments, it should be one of the most important and frequently used items in your toolbag.

If you’re still deciding on which tool to employ, there are some attributes you should take into consideration. Keeping in mind that both tools are entirely free(HashiCorp does offer a paid, enterprise version), the first decision focuses on the environments you intend to consume. Environments running on the AWS platform can make use of either tool. However, CloudFormation can presently provision across more services than Terraform can. For example, there are currently no Terraform (0.8.8) commands to provision and manage Amazon WorkSpaces, a feature that exists in CloudFormation. Users need to determine if the required data resources exist within the tool when making a selection.

Other criteria for AWS environments that should be considered when making a selection are the languages associated with the tools. Users will more likely be more familiar with JSON or YAML than writing in HCL, which is a language built by the tool creator, HashiCorp. Although HCL seems to be a bit more intuitive than JSON or YAML, learning a new language and its syntax may not be the shortest route to meet your pre-defined goals.

Another important consideration to look at is how you will manage state. If you’re the only engineer using these tools for your organization, managing state isn’t a dealbreaker. However, once you add a second person to that team, managing state becomes more important to ensure consistency among deployments and changes. As a native AWS tool, CloudFormation manages the infrastructure state for the user without additional configuration. Terraform, however, maintains the state in a local file named terraform.tfstate. The state can be stored remotely on Amazon S3 or by using HashiCorp’s Consul. The requirement to add an additional layer to maintain state increases the likelihood of mistakes, misconfiguration, and adds complexity to the solution.

For environments consuming resources from more than one cloud (AWS, Azure, Google, vSphere), you should consider using Terraform, as CloudFormation doesn’t natively support other platforms. Whether you’re planning a multi-cloud strategy or taking a hybrid approach, Terraform can automate and manage resources across the entire stack, giving you complete control across your entire cloud. For services that Terraform does not yet support, you can create CloudFormation stacks within your configuration file to help fill in the last pieces of the puzzle.

As an example of both Terraform and CloudFormation, identical templates for both tools can be seen below. The premise is to create a simple AWS Proof of Concept environment for testing. The environment consists of a VPC, a few subnets (one public, one private) and a NAT Gateway with proper routes to allow the private subnet to enable outbound connectivity to the Internet. (Keep in mind that these are VERY simple examples that don’t take more advanced syntax into consideration)

CloudFormation Template written in YAML:


Terraform Template written in HCL (HashiCorp Language):

About The Author

Bryan Krausen

Bryan Krausen is currently working as a Technical Architect with experience in a vast number of platforms.

Bryan has been active within the VMware vExpert community for several years and is the leader of the Louisville VMware User Group (VMUG) and Louisville AWS User Group.

Leave a reply

Your email address will not be published.