The IaC effect

Once upon a cloud, users had to provision, configure and deploy all their applications manually. That meant that somewhere a system analyst was drawing up a list of virtual hardware—your infrastructure stack—that would be required to run the application. After this was provisioned and configured, it would be deployed in their hosting environment. If the same application were required to run again in another region, the entire process would have to be repeated. This method was a waste of resources. Further, being manual, the process was susceptible to human errors, and it was expensive.

Clearly some way to automate the process was needed. Enter Infrastructure as Code (IaC).

IaC in a nutshell

IaC is basically a document; a script that spells out the group of actions that an operator would need to carry out manually. e.g. provision servers, load balancers, instal libraries, databases, set up security, etc. to run an application. Like application code, IaC can be run on multiple machines, enabling users to run the same application with predictable results regardless of hosting environment. The benefits are three-fold: Cost reduction; speed of execution; reduced risk from errors. All you need is the proper tool to run your IaC.

AWS CloudFormation and Terraform are simply tools to run and manage IaC .There are others as well; however, since, CloudFormation and Terraform are the most popular, this article spells out the benefits and drawbacks of these.

Both CloudFormation and Terraform are services that let you create, provision and deploy infrastructure without going through the grind of doing it manually. That means both the solutions address the deficiencies of manual provisioning and deployment by leveraging automation to provision infrastructure using configuration files that are treated as source code to create instances, such as compute storage network and application services…in short everything required to run the application in question.

But there are fundamental differences in each one, and that directly affects choice. To help you decide which better fits your infrastructure management needs, this post compares AWS CloudFormation and Terraform key parameters, such as state management, modularity, language.

Opensource vs Proprietary

To begin with AWS is created by AWS for AWS. It cannot easily be used in any other cloud environment. Terraform, on the other hand, which was created by Hashicorp, as an opensource solution. It is platform agnostic—i.e. it can be used to provision and deploy infrastructure on any cloud, Azure, AWS, GCP…

This difference comes with all the benefits and drawbacks of each method of development. E.g. in the case of opensource: no restrictions on modifying source code, large community of programmers contributing, fast-fail-fast-fix, cost, etc. And vice-versa for proprietary code.

Thus CloudFormation can only be used to define and provision infrastructure components in AWS. (It uses a simple text file to securely automate this) so your applications can run seamlessly across all AWS regions and accounts. Since it is built for use on AWS, it comes at no added cost. You pay AWS only for the resources you use to run your applications.

Whereas, Terraform can be used on any cloud, including Azure, GCP, or AWS. it also integrates well with other third-party tools like Cloudflare. This means Terraform can be used to manage and run your entire infrastructure—across all your hosting environments and services/tools—rather than only the ones that come with a single provider.

State Management

Whether you opt for Terraform or AWS CloudFormation, you still need to monitor and manage your own resources, However, the way you do it differs, with both.

Terraform  by default saves the infra-state on the disk of the provisioning computer. It is also able to store the state on a remote site. In the latter case, it employs flexible versioning to sync the infrastructure development. Remote state store supports Amazon S3, but the onus to configure it is on the user. Terraform saves the state in a JSON file, which acts as a map that spells out how the resources should be configured. Unlike AWS CloudFormation, on Terraform you have to manage the state file yourself. So if another developer works on the same resource stack, you have to establish an SOP to manage the state yourself. There’s a very real possibility of losing files.

CloudFormation, in contrast, manages the state automatically. In additionally to automatically provisioning a stack of required AWS resources, it also monitors it consistently to check that it is maintaining the defined state/configuration. Users are able to detect drift on their entire infrastructure. Unlike in Terraform, where this has to be done manually.

 CloudFormation spares you the need to track the state manually, which minimizes the chance of losing files through human or machine error. You don’t need to keep track of your stack’s state on CloudFormation, as AWS does it for you. Another benefit is that the user or any other developer can easily make changes to the stack using the management console, GUI or CLI and apply the correct stack name. There is basically no need to manage the state.

Modularity

Infrastructure needs are fluid and a certain degree of flexibility is needed to address this, CloudFormation and Terraform, both do this—but in different ways

Terraform uses containers, known as modules, that combine resources that work together. The modules can be used to share common configurations. Given that Terraform is an opensource solution, the modules are often shared online, giving users the advantage of community knowledge. This is a big help when writing or checking configuration files for bugs.

Terraform’s modularity is its big advantage. Since it was built as a cloud agnostic solution, Terraform can incorporate any resource, including an AWS resource or a third-party resource. Terraform also provides native support for third-party modules

CloudFormation uses the concept of ‘nested stacks’ as modules. These are basically templates that act as building blocks, allowing export and import standard configurations into your infrastructure. However, bing proprietary in nature, CloudFormation doesn’t make it easy to provision non-AWS resources. That is not to say this is impossible; you can use the custom-resource feature available in CloudFormation. But it calls for customized templating ot bring in non-AWS services.

Configuration

Since the very basis for IaC is automating configuration of resources, this is an important differentiator for both Terraform and CloudFormation, but the difference is and choice depends on the user’s preference/familiarity.

Terraform uses a a modular user-defined approach to fetch and compute specific data for use in a Terraform configuration. This allows users to use information created outside of Terraform for resource updation or provisioning.

CloudFormation uses parameters for configuration. A maximum of 60 parameters may be used per template, and each one must have a unique ID. Further, the parameters must be supported by CloudFormation, provided at the stack’s runtime and declared and referenced within the temmplate.

Language & Syntax

This can be a big one—or not—since it depends on the user’s personal comfort level with a given style of syntax.

Both CloudFormation and Terraform use declarative language—i.e. when you only need to specify outcome and leave the manner of creation to the program. As opposed to imperative language, where each step is defined in detail. Rather like a how-to video on youtube. Terraform uses JSON and HCL—Hashicorp’s own coding language. CloudFormation supports JSON, too, as well as YAML.

Terraform’s syntax is simple, and has been described as minimalist, by contrast, CloudFormation’s syntax is verbose.

Another difference is that terraform’s configuration language allows it to be repeated easily; for instance, if you needed to create 3 EC2 instances, with Terraform, you simply uses an account parameter and specify ‘Count = 3’. In CloudFormation, you would need to repeat the code thrice to create the same instance three times.

Graphic User Interface

Like language and syntax, preference for a user interface can be subjective, but CloudFormation scores high here, not only for the user-friendly design of its GUI but for the fact that it comes at no added cost—you only need to pay for the resources you provision. CloudFormation’s GUI is well designed and easy to use. It allows users to select or design a template, you can drag and drop and the code will be automatically generated. You can also convert JSOn to YAML. And it’s all available at no extra cost.

Terraform’s GUI, on the other hand, can only if used if you purchase an enterprise licence, which can be costly for smaller organizations.

In Conclusion

At the end of the day it comes down to individual situations. An organization that is using AWS exclusively for its cloud needs, will definitely find CloudFormation more convenient. Enterprises that have 3rd party infra or service dependencies would be better off with Terraform’s cloud agnostic approach. Comfort with a particular language/syntax or GUI familiarity should also be considered.

Whatever decision you make, remember to factor in future needs as well. While your current infrastructure will definitely impact your choice, you should also look at the long term implications of both IaC toolsets.

Need more help in deciding? Give us a call, our experts will be happy to help.