Choosing the right tools is one of the most common challenges that DevOps engineers face in their daily work. In today's entrance, we will focus on comparing the two most popular infrastructure management tools on AWS – the native CloudFormation and the open-source Terraform. Both allow you to automate the processes related to defining the infrastructure configuration in accordance with the Infrastructure as Code methodology. How do they rank against each other? Let's check it out!

Infrastructure as Code - the modern approach to infrastructure management

Let's start with explaining the basics, i.e. what are CloudFormation and Terraform basically used for and why they are (or at least should be) indispensable tools in the tech stack of every DevOps engineer dealing with a more complex cloud project. Less technical people sometimes mistakenly assume that migrating to the cloud means completely eliminating operational costs associated with infrastructure management. Meanwhile, the cloud application's service infrastructure also needs to be set up - and it can be a task as laborious as manually configuring physical servers. To automate repetitive tasks, DevOps specialists use the Infrastructure as Code (IaC) methodology, which allows you to define service configurations in the form of configuration forms.

The dilemma regarding the selection of tools or methods for setting up the cloud is a challenge faced by many DevOps engineers interested in Infrastructure as Code. There are a lot of tools, and the knowledge available on the Internet is even wider - so how do you manoeuvre in this mass of information? At Rumble Fish we meet such challenges and offer DevOps specialists comprehensive course enriching their knowledge and skills. Under the watchful eye of experienced mentors, you will learn all the secrets of cloud orchestration and more. In our tool comparison, the technology expert is Marcin - our Tech Lead.

Beyond automation - the advantages of IaC

In addition to the obvious benefit of saving time related to the automation of certain processes, the use of infrastructure as a code has a number of other advantages. Configuration files can act as documentation, and if written correctly, they can be run anywhere - in a public or private cloud, or on your own server. The communication in the team is also significantly more transparent - any changes in the infrastructure configuration files can be easily traced, which allows us to identify possible configuration errors faster. IaC also allows you to return to any previous version of the code in the repository, which allows you to seamlessly switch between individual versions.

Setting up IaC can be extremely complicated, therefore the selection of appropriate tools, tailored to our needs and capabilities, is vital. Let's take a closer look at the most popular cloud infrastructure management solutions.

AWS CloudFormation vs. Terraform - what to choose?

In our analysis, we will take into account a number of the most important factors affecting the capabilities of the two compared tools. We will also look at the ease of work, flexibility and the level of security that each of them provides. Let's get started!

The supplier and the language

CloudFormation is a tool created and maintained by Amazon, so its focus is on orchestrating the AWS cloud resources. Terraform enables cooperation with many suppliers and technologies, which at the very outset makes it more flexible than the competitor. CloudFormation is a proprietary solution, so it doesn’t offer the possibility of submitting pull requests, which means that we are, in a way, stuck with Amazon. This provider, obviously, offers the appropriate support, as long as we have purchased the appropriate support plan. In the case of Terraform, an open-source tool, a thriving community is available, and anyone willing can contribute, report bugs and requests.

In terms of the supported language - CloudFormation gives you the ability to create in YAML, which is a great help when you hand write the code, with this language you do it faster. Terraform, on the other hand, supports its own language called HCL (HashiCorp Configuration Language), which includes all JSON functionalities, can be compiled into JSON, and additionally, has several built-in abstractions, such as loops or conditional statements. Thanks to this, with the help of HCL, we can create configurations more expressively, intentionally.

The tools

To start working on Terraform, it’s necessary to download the TF binaries and plugins that will allow us to connect to the selected cloud, database or other resource that we want to manage from the TF level. Therefore, it’s the DevOps engineer who’s responsible for versioning and managing individual suppliers. In the case of CloudFormation, this problem is solved automatically - because the CF is built into AWS, you don’t need any additional tools to start the configuration. You may find AWS CLI (Command Line Interface) useful, but it’s optional.

The parameterization

In Terraform, parameterization has a basic scope - we can define variables and assign them some value. The TF also offers us the possibility to validate and define optional parameters. The same is offered by CloudFormation, but additionally, it enables integration with the AWS services. - For example, we can specify that a given parameter is an SSH key to the instance, and the CF itself will propose one of the available keys that we have on the account. It’s a very useful, intelligent solution that makes configuration extremely easy - says Marcin, our Tech Lead.

The solutions sharing

This aspect is particularly important for the beginning DevOps specialists or people who are just starting their adventure with Infrastructure as Code. The ease of sharing developed solutions or tracing the logic of the code is something that will be appreciated by everyone who is learning to manage the IaC. What does it look like when it comes to the tools we’ve analyzed? Terraform is much more “strict” in this respect, and the entry threshold is higher. In TF, we work with modules, the idea of which is that with the help of code, we can generate entire sets of components tied together (both resources and other TF modules). Each module has both input parameters and outputs (for example VPC id from the VPC generated in the module). Modules can be stored locally (as a separate directory in an existing repository), as a separate Git repository path, or in the Terraform Registry where public modules are usually kept. In CloudFormation, things are completely different - modularization is about creating the so-called Nested Stacks, i.e. nested stacks, stored by default on S3. In CloudFormation, things are completely different - modularization is about creating so-called Nested Stacks, i.e. nested stacks, stored by default on S3. We can share such a stack - if, for example, we publish an article, we can create a "Launch Stack" button, which will automatically take us to the appropriate stack and allow us to trace its logic and structure. Such transparency is something that beginner users of CloudFormation appreciate very much. However, these are not all the options that AWS gives us in this regard. Another one is AWS Service Catalog, which allows you to create a whole list of products within a given organization. In this case, the product is a specific CloudFormation form, which we can configure to create a lambda, API gateway, we will define all the required permissions, and then use the Service Catalog to share it to our developers. Such prepared, proven and tested form can be easily found and used without worrying if it will work. This solution works well in large projects or organizations, because it safely allows you to delegate powers to individual team members.

The rollback

The rollback is the possibility of withdrawing the introduced changes, which is extremely important when we want to be sure of implementations in production. In Terraform, rollbacks aren’t supported, which doesn't mean they are impossible to make. A way to get around this limitation is to use, for example, the Git Revert, which returns the environment to the previous commit. The infrastructure person reverts the code back to a previous version (e.g. using Git) and then has to apply it. The downside of this solution is that it’s done by hand, and may fail for many reasons. CloudFormation, on the other hand, tries to roll back the changes if the update fails.

The multiple AWS accounts support

Terraform supports all major cloud providers and allows you to define multiple accounts in various configurations. Unfortunately, this has to be done manually. CloudFormation, despite limiting itself to servicing only AWS, has many advantages here. In terms of the Amazon cloud, it allows integration with the AWS Control Tower and AWS Landing Zone, which help in managing an environment consisting of multiple AWS accounts. -These tools check the infrastructure configuration in terms of best practices, and they collect all security-related events on a selected security account. For newly created accounts, they automatically apply the selected form, which greatly improves project management, especially the large ones. Another interesting CF solution is StackSets, which allows you to implement one form for many AWS accounts - says Marcin, who uses AWS resources and tools on a daily basis in his work at Rumble Fish.

The changes planning

In CloudFormation, we work with forms and the stack created on their basis, locking is on the part of AWS. In Terraform,  the code versioning is in Git, we also have a shared state that can be accessed by many people. In addition, TF offers the possibility of targeting - if we work in a large environment consisting of hundreds of resources, we can improve and speed up work by targeting only one of them. Thanks to this, we don’t have to wait long for the status to be refreshed and we get almost immediate feedback regarding the changes made.

Both CF and TF have the option to take a look at what will actually be changed. In CloudFormation, this service is called ChangeSets and it works for all resources except the NestedSets (we can't see what's going to happen in nested modules). When it comes to Terraform, we get a scheme that includes all the changes that will arise in the modified environment. We can see absolutely anything, as transparency in Terraform is definitely greater.

The result of the clash - CloudFormation or Terraform

As it frequently happens, it’s difficult to clearly indicate the winner of the clash in this case - both CloudFormation and Terraform have their strengths and weaknesses; and the choice of a particular tool should be based on the specifics of each project. Terraform is a more flexible solution, it allows you to control almost every element of the environment. The price we pay for such a high degree of control is the complexity of the tool. TF is definitely more difficult to learn if you are new to DevOps. This difficulty, naturally, decreases with the acquired experience; and people who’ve been working with Terraform for a long time, highly appreciate its rich possibilities and flexibility. CloudFormation, on the other hand, makes it much simpler to share solutions, learning is far easier, and the possibility of integration with various AWS resources is impressive.

Of course, the key factor when choosing between CF and TF is the type of resources we will use - if our infrastructure is multicloud from many suppliers, it’s better to choose Terraform; while if we use the AWS cloud - CloudFormation gives us a lot more possibilities.

REFERENCES:

1. AWS CloudFormation Website 

2. Terraform Website

3. CloudFormation vs Terraform by Cloud Native Computing Foundation

4. Terraform vs CloudFormation by SysOps/DevOps Polska (available in Polish)