• Let's make Cloud ☁️
  • Posts
  • Let's make Cloud #68: Infrastructure as Code Needs a Rethink, Why the AWS CDK won the war (inside my head), It’s Time to Retire Terraform

Let's make Cloud #68: Infrastructure as Code Needs a Rethink, Why the AWS CDK won the war (inside my head), It’s Time to Retire Terraform

Infrastructure as Code Needs a Rethink, Why the AWS CDK won the war (inside my head), It’s Time to Retire Terraform

Hello CloudMakers!

I've noticed a rise in articles discussing moving away from Terraform, the popular infrastructure as code tool. Many of you readers are avid Terraform users (including myself). So I've put together this special newsletter issue featuring three articles on this topic. The goal is not to promote any one view, but to spark thoughts on the future of infrastructure as code by looking at different perspectives.

So, today we shall see:

  • Infrastructure as Code Needs a Rethink

  • Why the AWS CDK won the war (inside my head)

  • It’s Time to Retire Terraform


Infrastructure as Code Needs a Rethink

In this thought-provoking article, Ben Goodman critically examines the current state of infrastructure as code (IaC) tools like Terraform and argues that a fundamental rethink is needed. While acknowledging the immense value IaC has brought in terms of velocity, stability, and auditability of cloud infrastructure, Goodman contends that these tools directly reflect the underlying complexity of cloud platforms back to developers.

He highlights the numerous considerations and configurations required even for deploying a relatively simple stateful containerized application, from selecting the appropriate compute service to configuring networking, storage, and security settings. Goodman points out that while mature organizations may provide internal modules to abstract some of this complexity, this approach has limitations in scalability, multi-cloud support, and maintenance overhead.

Ultimately, Goodman argues that the current IaC model is fundamentally reactive, requiring significant effort from DevOps teams to catch and resolve issues after the fact. He envisions a future where IaC tools present developers with opinionated, secure, and cost-effective building blocks, abstracting away provider-specific details while enforcing best practices by default.

Why the AWS CDK won the war (inside my head)

In this article, the author dives deep into the merits of the AWS Cloud Development Kit (CDK) and why it has emerged as their preferred infrastructure as code (IaC) tool, especially for AWS workloads: if you're already committed to the AWS ecosystem, the CDK offers compelling advantages.

One of the key strengths highlighted is the ability to modify the CDK's source code with ease, leveraging familiar programming languages like TypeScript. The article also praises the CDK's ability to work around CloudFormation limitations through custom resources and direct API calls when needed.

A significant focus is placed on the CDK's approach to automatic rollbacks, which helps prevent broken deployments from impacting production infrastructure. Additionally, the built-in IAM helpers and the central role of Lambda functions and event-driven architectures within the CDK ecosystem are lauded.

The article also explores the benefits of testing snapshots, which can help catch unexpected changes and ensure consistency across different environments.

It’s Time to Retire Terraform

The article makes a case for retiring the popular infrastructure as code tool Terraform, citing several limitations and challenges associated with its use. The author acknowledges Terraform's role in popularizing IaC but argues that its shortcomings are becoming increasingly apparent.

One of the main criticisms is the lack of consistent patterns and conventions across Terraform configurations, leading to bespoke structures that can be difficult to maintain and collaborate on. The article also highlights challenges in managing multiple environments, handling drift, and the complexities of HashiCorp Configuration Language (HCL).

Larssen argues that Terraform's "cloud agnostic" nature is overstated, as each cloud provider still requires deep understanding of its nuances. Additionally, the article raises concerns about collaboration, permissions management, and the administrative overhead associated with Terraform.

The author also touches on the recent licensing changes by HashiCorp, which have led to community fragmentation and the emergence of forks like OpenTofu, adding uncertainty to Terraform's future.

Thank you for reading my newsletter!

If you liked it, please invite your friends to subscribe!

If you were forwarded this newsletter and liked it, you can subscribe for free here:

Have you read an article you liked and want to share it? Send it to me and you might see it published in this newsletter!

Interested in old issues? You can find them here!