AWS CDK? Why not Terraform?

6 min read, last updated on 2020-12-13

Sigh. If I had a penny every single time, I proposed AWS CloudFormation or AWS CDK for the infrastructure as code solution, and I received pushback in the form of a question: why not Terraform instead? I’d have a significant amount of metal scraps in my wallet.

Good arguments rarely support this pushback, and it’s wrong on so many levels, so please allow me to tackle this bit by bit.

Origin of the statement “Terraform is a sensible default”

This statement predates the example I want to show, but I will still use it as an example because it clearly shows how far it went.

Above, you can see that handwritten AWS CloudFormation is marked as a HOLD technique. For those of you who are not familiar with the categories - Thoughtworks is classifying specific solutions, tools, and techniques with labels ADOPT, TRIAL, ASSES, and HOLD. As you’ve probably deduced, the last one says to proceed with caution when using it.

Honestly: inside this paragraph, there is plenty of arguments against AWS CloudFormation, and they have a point there. However, that reflects only the more familiar voices of the community.

Here is the problem with this reasoning in a broader context: when you choose infrastructure as code solution, many experts say like a mantra that you need a tool that is an OSS one because you will be increasing your vendor lock-in without tat.

However, it’s hard to be mad at Thoughtworks as they did not say that. Yet, their report reflects just a fraction of the community, which stopped at the first available solution that provides an alternative for the least essential problems: DSL syntax (referred to as shortfalls of CloudFormation) and imaginative danger of the vendor lock-in.

When I am starting a discussion with the claim about vendor lock-in’s imaginative danger, many people actually push back again and begin to talk about why it’s so wrong to use a tool for infrastructure as code provided by your cloud provider.

Well, this motivation it’s a fallacy, so allow me to explain why.

Leaky abstractions are the wrong answer to a vendor lock-in problem

Let me explain what kinds of lock-in we face. For that, I will use a fantastic essay from Gregor Hohpe: Don’t get locked up into avoiding lock-in.

He defines a great list of various shades of lock-in:

• Vendor Lock-in.
• Product Lock-in.
• Version lock-in.
• Architecture lock-in.
• Platform lock-in.
• Skills lock-in.
• Legal lock-in.
• Mental Lock-in.

So it’s not a binary choice. It’s more like risk management and cost-benefit analysis. Additionally, he puts very elegantly that pursuing a crusade against one type of lock-in may create another one:

New Lock-ins: Avoiding one lock-in often comes at the expense of another one. For example, you may opt to avoid AWS CloudFormation and instead use Hashicorp’s Terraform or Pulumi, which both support multiple cloud providers. However, now you are locked into another product from an additional vendor and need to figure out whether that’s okay for you.

Gregor Hohpe about new lock-ins that arise from obsessively removing another one.

So why I think Terraform is a leaky abstraction in such a case? All of you who wrote a little bit of Terraform know that it does not provide an abstraction layer for the AWS, Azure, or Google Cloud. It does that deliberately, as you should embrace all aspects when using cloud - not extract a common denominator from the services delivered by the cloud provider. And the author of this essay elegantly points this out as well:

When calculating the cost of avoiding lock-in, an architect should make a quick run down this list to avoid blind spots. Also, be aware that attempts at avoiding lock-in can be leaky, very much like leaky abstractions. For example, Terraform is a fine tool, but its scripts use many vendor-specific constructs. Implementation details thus “leak” through, rendering the switching cost from one cloud to another decidedly non-zero.

Gregor Hohpe about leaky abstractions and why in the context of avoiding platform/vendor lock-in, it may be a wrong choice.

Unique Selling Points of AWS CDK

Okay, so as we left behind the misguided arguments about Terraform, let’s talk about places when you should consider AWS CDK as it will be the right solution:

• It provides a very gentle way of introducing topics of infrastructure as code to the developers. This way is more natural for the developers and exposes a natural bridge to them, so it will be easier to encourage them into more DevOps culture responsibilities.
• It removes shortfalls of AWS CloudFormation related to syntax, reusability, and modularity. Better flexibility in the experienced and aware hands gives more power and expressiveness, which is a great asset.
• You still want to use AWS CloudFormation because you like certain guarantees not provided by the other tools (e.g., safe rollback).
• With the rise of Serverless applications and architectures, this will be a great alternative to the Serverless Framework and the others.
• It looks like AWS wants to invest more heavily in it, as it is creating more bridges, like the one for Kubernetes (cdk8s).
• There is even a dedicated bridge between AWS CDK and Terraform blessed by the Hashicorp (cdktf).

When not to use AWS CDK?

I think that is often the most missed section is such kind of articles. Many of us, engineers, are guilty of drinking the kool-aid and focusing on just one side of the problem. It’s a mistake because tools are rarely a solution that gives terrific ROI.

Side note: If you are interested in this topic, I strongly encourage you to read an essay from Fred P. Brooks titled No Silver Bullet - Essence and Accident in Software Engineering about accidental and essential complexity, and hopefully, you will understand my point about pointless hope put into many tools.

That’s why I have prepared a list (which is not exhaustive, I would love to learn more about your misguided approach to AWS CDK and lessons known from it) that may be a useful heuristic when to avoid this tool:

• It’s not a great tool if your environment is focused on multi-cloud, or you heavily depend on multiple providers (e.g., some parts of the infrastructure are on the AWS, but domains and CDN are somewhere else). In this case, Terraform is a more appropriate tool.
• It’s hard to divide your applications and company structure into independent teams that should manage their applications end-to-end. This may severely complicate the whole approach to embracing AWS CDK in the most-effective way.

Summary

I hope this article will help you to not copy this misguided argument about Terraform. If that will convert from that path at least person, I will be more than happy. There will be fewer sighs and metal scraps in my pockets. 😂