When working mainly on AWS, CloudFormation is an obvious choice for automating the setup and maintenance of your infrastructure and making it reproducible.
In short the tool to use for the topic of Infrastructure as Code (IaC). CloudFormation is powerful and there are a lot of resources out there to get started. Nevertheless we opted for Terraform as our choice of IaC tool.
Good decision making should start with looking at what you have, the team and the business requirements and goals. Often we as humans tend to look at our field of expertise and forget our surroundings we operate in. Exactly these surroundings are vital to the success of any project. There is no ‘one size fits all’ solution out there, as we live in a world where innovation is driving us and change is constant. This article is not intended to make choices for you but give you insights on why we choose Terraform in the situation we are in and how we work with it.
“The world is not golf, and most of it isn’t even tennis. As Robin Hogarth put it, much of the world is “Martian tennis.” You can see the players on a court with balls and rackets, but nobody has shared the rules. It is up to you to derive them, and they are subject to change without notice.”
David Epstein, Range: Why Generalists Triumph in a Specialized World
Modularity
AWS is a great choice when it comes to flexibility in setting up an infrastructure fitting your business’s needs. I often hear people talk about: “It takes a huge amount of expertise to work with AWS”, which is true, but it is also one of the biggest advantages of working with AWS. With expertise you are not limited to opinionated architectures, but you have the freedom to architect based on project and company specific needs. This leads in my experience to IT infrastructures which in the long run are more robust and a lot more flexible when executed well. Certainly AWS is not free of opinionated approaches, but as an architect who has worked with all major cloud platforms I can confidently say that for us it hits the right balance.
You might think “What does flexibility of the cloud provider have to do with the IaC tool to choose?”. I would argue quite a lot. Flexibility brings a lot of responsibility. Any business wants to move as fast as possible and still have the best quality of service. To get to that point each team needs to develop best practices which enable them to achieve these goals. Balancing flexibility and innovation with ready to use best practices is key. To achieve this balance Terraform uses composable modules.
Modularity is one of the strong points of Terraform. With modules it is possible to package common best practices in your company for reuse and have control over the configuration of a specific resource or set of resources to be used in a consistent way. With exposing the things which might be configured and keeping static configuration away from the module user, developers have direct guidelines how to use these modules. Driving it even further this can also lead to Terraform being the enabler to position infrastructure as a product in your company.
Tagging for example is a topic often overlooked when beginning to work with AWS.
The goal with tagging is to group resources based on parameters defined in your company. This helps from billing over maintenance to keep your accounts clean. For example a good rule is to put an ”application” tag with the name of the application the resource belongs to. Every developer is now responsible to make sure that every AWS resource created has that tag. With one it might work, but with several different things like environment, business unit etc. it gets more and more complicated and time consuming for developers to always remember the exact spelling and check that really all tags are present. One solution might be to use AWS Config to check tagging conventions automatically, which is a good idea, but doesn’t take the burden away from a developer.
With Terraform modules you can write a tag module with required parameters, with the purpose of creating a consistent tag set across your infrastructure.
This module defines as the output the tag set and for any resource adding tags becomes as simple as adding the tag output. If a required configuration is not passed to the module, it will throw an error and Terraform plan or apply phase cannot be executed.
Additionally the community already provides a lot of good modules to get started and adapt them to your needs. Only through this great community Terraform has gained the attention over the last years and is used from small to big enterprises.
Readability & Maintainability
HashiCorp also did quite well on the aspect of readability and the related topic of maintainability. They developed their own description language called HCL.
They describe it themselves as: “HCL attempts to strike a compromise between generic serialization formats such as JSON and configuration formats built around full programming languages such as Ruby. HCL syntax is designed to be easily read and written by humans, and allows declarative logic to permit its use in more complex applications.”
Even though it is another language to learn, it brings quite some powerful concepts to configuration code, which are quite unreadable if added to json or yaml, like loops, conditions etc., but removes a lot of boilerplate code seen if infrastructure configuration is done through usage of common purpose programming languages.
Context Switches
Because Terraform was built to be a readable, easy to understand tool, it also does well in a major area for any company working for multiple customers. In our line of business we have to work on multiple projects at the same time. It is essential for us to be able to get quickly into different projects. This is obviously not only possible by using Terraform, but with good coding guidelines also defining the structure of any Terraform project.
To get started with this topic check out and stay tuned for another article on how we work with Terraform on a day to day basis.
