On DevOps — 10. Infrastructure as Code — Introduction to CloudFormation, AWS CDK, EKSCTL, and AWS SAM

Some cloud, at some Fjord in Norway

In my last article, I talked in depth about Terraform about how it works, some advantages and disadvantages, and best practices. If you haven’t read it yet, here’s the link to it:

On DevOps — 9. Infrastructure as Code — Clean Code, Terraform Introduction, and Best Practices

Given the benefits and disadvantages of Terraform, it could be a go-to option for many people who want to get started managing their cloud infrastructure as code. However, there are certain cases that you might want to consider other options, and let’s go over them one by one.

CloudFormation

CloudFormation is AWS’s answer to Infrastructure as code. It was launched in 2011, way earlier than Terraform, and over the years, it has become an indispensable tool for many AWS customers. You can define a template once, then re-use it to provision your AWS resources.

Syntax

At the beginning of its lifecycle, JSON is the only supported format, and let’s face it, JSON isn’t easy to read, although the official website says that it is a lightweight data-interchange format easy for humans to read and write, especially if you have a relatively large file (in the case of a CloudFormation template you usually do).

In my opinion, JSON format is mainly designed for machines to parse and generate and exchange data, not for humans to read.

It was not until 2016 that AWS introduced YAML into CloudFormation. Before 2016, I personally wouldn’t consider writing JSON to manage my infrastructure at all because it’s not manageable.

YAML, on the other hand, although is hated by many people as well (have a look here, I don’t want to get into this topic of “why YAML is bad”), I’ll have to admit that it is relatively more human-readable compared to JSON because at least it was designed to be human-readable.

Readability

Although the syntax affects readability greatly, there is another major topic that…