IaC and the Rise of CloudFormation

Since it first came into existence, the cloud has gone through several major evolutions, but one service has remained constant. IaC. IaC has and remains a core implementation solution on AWS. It took away the costly, error-prone manual system of creating infrastructure from scratch and allowed developers to automate the process.

And the tool that was used to enable that automation was CloudFormation. Built by AWS for AWS, CloudFormation, which was first released in 2011, allowed developers to write simple template files to build infrastructure as needed to run their web applications. It is still one of the safest ways to create, manage, modify and delete resources in your infrastructure. It enables robust state management, and can, as of date, even let you know how your deployment will run—before you actually deploy.

CloudFormation templates included different attributes and configuration values for various resources, all entered in a reusable and repeatable format. The languages CloudFormation supports are JSON & YAML. The only problem is that these are verbose and clunky. And these files are hard to share in a meaningfully scalable way with multiple teams across the enterprise. A new solution was needed. And that was CDK.

CDK—AWS’s Gamechanger

CDK, or Cloud Development Kit, to give it its full name, was released in 2019. It solved the language/syntax issue inherent in CloudFormation, by supporting popular Programming Languages such as Java, JS, Python, and TypeScript. For developers this is a huge advantage as developers can write using the same code to manage their infrastructure as with the rest of their stack. It also opened the doors to tools like autocomplete, compute time warnings, and control flow statements. This is shorter, cleaner and altogether better solution than writing YAML & JSON configuration files. Making CDK is the natural entry point for developers to build AWS Cloud-native applications.

That is not to say that CloudFormation and CDK are mutually exclusive. Under the hood, CloudFormation runs CDK. CDK basically takes the code you write and synthesizes it to CloudFormation. There is a common notion that CloudFormation is the assembly language of AWS. Possibly, because so many AWS tools are built on CloudFormation, but that’s makes it all the more important to understand CloudFormation and how it could affect decisions in higher level use of CDK.

Constructs

One of the most powerful features that CDK offers is Constructs. An improvement on CloudFormation’s Modules, Constructs are resource templates that developers can use ‘as is’ or they can modify them to create customised ones. Constructs can be distributed across the organization freely and in a scalable manner.

Terraform

Built by Hashicorp in collaboration with the larger developer community, Terraform is an open source IaC management tool that allows the user to manage multi-cloud environments, including AWS. This is its biggest advantage over AWS CloudFormation and CDK that can only be used in AWS environments.

Unlike AWS CloudFormation and CDK, Terraform uses the Hashicorp’s homegrown language HCL.  Like YAML & JSON which are supported by CloudFormation, HCL too is a declarative language, but not as verbose as JSON & YAML. Unlike CDK, Terraform does not support programming languages like TypeScript, Python, etc.

Terraform also loses out to AWS CloudFormation and CDK where State Management is concerned, as it doesn’t manage the state automatically nor does it manage it. Instead it saves the state on the user’s memory in a JSON file—unless you opt for an expensive enterprise licence, in which case you have the option of saving the file remotely. Another area where Terraform is palpably weak is in the matter or Rollbacks. Unlike both AWS CDK and Cloudformation, Terraform does not support rollbacks.

Which one’s right for you?

The answer is still: it depends. If you’re mostly using simple solutions, like Serverless, with minimal dependencies, CloudFormation or CDK will serve you well enough. This is also true if you intend to keep you infrastructure exclusively on AWS. However, if you use a mutli-cloud environment, or see this as a future possibility, Terraform’s platform agnostic nature offers a definite advantage