I Don't Get CDK | ✉️ #48

Illustration for "MKDEV DISPATCH #48" featuring a smiling man holding a cat, with the phrase "I DON'T GET CDK," paper plane doodle, and a background of paper planes and a two-tone split of purple and orange.

Hey! 👋

The other day, once again, I evaluated using AWS CDK for one of the projects. Once again, I didn’t get the idea of it. In this intro, I want to share with you my issues with this tool, and ask for your thoughts to help me understand in which scenario CDK would be a better choice than Terraform.

In general, I love the idea to define the infrastructure with the “normal” programming language (and have long advocated that the path of Chef is superior to the path of Puppet). I love it because of the use cases it unlocks: we can write services, that can power different internal APIs to provision resources in a standard and secure way while hiding all the complexity behind powerful abstractions. Service Catalog and Developer Portal tools can be built very nicely, if the backend code could provision infrastructure without shelling out to Terraform or AWS CLIs. This is where CDK could really shine, and this is where it’s totally helpless, to my surprise.

As of writing, even though you can write your infrastructure code in Python, TypeScript, Java etc, you can’t programmatically execute this code. Pulumi gets it right offering Automation feature. CDK, somehow, is not capable of doing this. You will find plenty of GitHub issues, with various hacks - such as invoking internal libraries of CDK in your own code, or shelling out to CDK CLI from your code. Writing your infra in Python loses its appeal if you can’t run this code like you run any other code.

Without programmatic execution, CDK seems to be just another way to define your infrastructure code, this time using a more familiar programming language. This assumes, that infrastructure engineering are good developers (which they absolutely must be, but in so many cases they aren’t) - or that developers are handling infrastructure (and this assumes that developers found and spent a lot of time to become good experts in infrastructure, which is more often not the case). YAML and HCL are not as powerful as Typescript, but at least they are small and simple enough for both infrastructure and application engineering teams to learn and use (and both are still not that simple and often confuse people). And in case of Terraform, there is a rich collection of great community modules that abstract away some of the complexity - I am not aware of anything like this for CDK, you’d have to build libraries with all the boilerplate yourself.

Not being usable for truly powerful platform engineering use cases, and not suiting really well neither of infra and application audiences, CDK comes with another big disadvantage - CloudFormation. At the end of the day, no matter how pretty your CDK code is, all of it will be converted to a CloudFormation stack, horrible as any CloudFormation stack out there. And nothing in CDK seems to save an engineer from the usual horrors of using CloudFormation.

There is, of course, Terraform CDK, still no GA, but getting there. In this case, last argument doesn’t apply, but the other two still do.

If CDK could be run programmatically and power APIs, or provide simpler developer-focused abstractions (like AWS SAM or AWS Copilot), or at least exist on it’s own without the mess of CloudFormation, I would at least consider using it in a greenfield environment.

But maybe I am just missing something, thus the microphone goes to you - perhaps you can tell about the use cases where CDK is superior to Terraform.

What We've Shared

DevOps Accents #40: Cloud Gaming and Google Stadia. Let’s talk about cloud gaming possibilities of today and remember Google Stadia. Our guest this time is David Wynn, Principal Solution Architect from Edge Delta. Join him, Leo and Pablo for a discussion of the problems cloud gaming faces now and the possible future for this experience:

And on the website:

How to encrypt disks in GCP? Explore disk encryption in GCP with Pablo Inigo Sanchez! Learn about using Key Management Service (KMS) for Google-managed, customer-managed, and customer-supplied encryption keys. Secure your cloud data effortlessly!
How to back up GKE Clusters? Explore the robust features of GKE backups for containerized applications: a scalable, reliable solution for disaster recovery, data protection, and compliance, ensuring quick recovery and consistent data integrity across clusters.

What We've Discovered

ulid: Specification for ulid - data format that aims to solve many of the issues UUIDs have.
How we migrated from AWS to GCP with minimal downtime: A fascinating migration, whether PostgresML figured many tricky parts of moving terabytes of data between cloud providers. You would be surprised, that the issues they encountered had nothing to do with AWS or GCP, but rather with low-level processes, like buffering, networking and compression of disk space used.
Anomaly Alerting in Prometheus: A walkthrough of using Anomaly Detection for alerting in Prometheus.
Optimizing Amazon Simple Queue Service (SQS) for speed and scale: AWS shares details about some internal optimizations they did this year for SQS, resulting in smaller footprint and lower latencies.
Using short lived postgres servers for testing: Great tips on quickly creating short lived database servers, either locally or in Kubernetes.

A random reminder

In the email version below this random reminder you can find your personal link for the mkdev dispatch Referral Program! Use it to share the dispatch with friends and co-workers and get little gifts from us :)

The 49th mkdev dispatch will arrive on Friday, July 19th. See you next time!