Hey Azure and Google Cloud - we need the AWS CDK from you too!

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

Many people rather warmly welcomed the announcement of AWS CDK. I see it as an evolution towards better IaC.

As Seth Vargo put it in his talk: not only infrastructure code should be treated as a first-class citizen in our projects.

What do we need?

The current state of the art is as follows: if you are using multiple cloud providers or many 3rd parties in a single project, in most cases, the only way to automate is either to use Terraform with necessary providers or to reinvent the wheel with your creations. I do not have to explain why the latter is inconvenient, to put it mildly.

If you have written a sizeable piece of Terraform code definitions, you know it is a very leaky abstraction. All terms relevant to a given cloud provider are soaking into the IaC definitions.

There is no way to create a solid (pun intended) abstraction in such an environment. Unless we will get the expressiveness of a regular programming language, only the sky is the limit.

However, at the moment, this is not feasible anyway, as just one cloud provider can define the IaC with the use of regular programming language.

But, what if other cloud providers would adopt this approach? How can it help?

Why? The Case of Pulumi

If you haven’t heard about Pulumi, go check it out. To put it simply: it is the same great idea to use a standard programming language to define infrastructure as code that precedes the AWS CDK.

And it supports multiple clouds. How may you ask? Yeah, here is the catch: it uses Terraform behind the scenes.

You can read here why using Terraform is rarely a good idea, IMHO. This case aches even more - especially that you lack rollback, and it surfaces pretty often to the top with error messages and leaky abstractions.

If it could leverage AWS CDK and corresponding SDKs from Google Cloud and Microsoft Azure, it would be more pleasant to work with. It would have more features (that would not be available the other way, e.g., rollback) and a better feeling. In such a case, we would not have an impedance mismatch because we would use SDKs directly.

Danger! Danger!

Most of the benefits were described above, and they are pretty easy to imagine. However, this may also cause some problems.

First and foremost: if you would like to unify multiple cloud providers and their services, you will have the lowest common denominator. If you expect to have just virtual machines, it can be a perfectly acceptable thing. However, in most cases, you are castrating the service provider, and you are ending up with a situation where nobody is satisfied (neither you nor the service provider).

Secondly: you may introduce significant accidental complexity to support multiple clouds. This can be partially solved by creating an open standard, but we know how those initiatives often end up.

Call To Action

I know that after reading the last section, you may be hesitant about the whole idea of introducing the same mechanism by the other cloud providers. Still, I think that potential benefits outweigh the potential issues, so:

Dear Decisionmakers from Google Cloud and Microsoft Azure, I would like to ask you for a favor:

Please consider adding a mechanism similar to AWS CDK to your IaC capabilities and libraries.

I pretty please, as we would like to get rid of the leaky abstractions.

Update (02.2021)

So it looks like we have some movement! However, it’s mostly done by the AWS, Hashicorp, and community.

So we have more layers of abstractions in the form of two new tools inspired by and which are using AWS CDK:

cdktf, which is Cloud Development Kit for Terraform.
cdk8s, which is Cloud Development Kit for Kubernetes.

Additionally, something moved (with the community effort) on the Microsoft Azure side. Yetics and Andreas Heumaier are creating armkit, which is a similar tool for Azure Resource Manager (which is an AWS CloudFormation equivalent in Azure). Andreas presented the idea during the CDK Day 2020: