These “Cloud Development Kits” are used for defining and provisioning cloud infrastructure resources using familiar programming languages including TypeScript, Python, Java and Go. In AWS, CDK is offered in addition to AWS SDK for various languages.
What they share: all three use the constructs programming model (object-oriented code → declarative infra).
What they target:
As far as history goes, it seems AWS CDK was first, then cdk8s, and finally CDKTF. I remember the hype about CDKTF a few years ago.
cdk synth
The different CDK tools each have their own CLI, however some commands are similar and related. For example cdk synth.
Turn constructs-based code → declarative output for the downstream engine.
| Tool | Command | Produces | Next step |
|---|---|---|---|
| AWS CDK | cdk synth (alias: cdk synthesize) |
CloudFormation template(s) | cdk deploy |
| cdk8s | cdk8s synth |
Kubernetes Manifests | kubectl apply -f dist/ |
| CDKTF | cdktf synth |
Terraform JSON | cdktf plan / cdktf deploy |
| Stage | AWS CDK | cdk8s | CDKTF |
|---|---|---|---|
| Init | cdk init app --language ts |
cdk8s init typescript-app |
cdktf init --template=typescript |
| Bootstrap / State | cdk bootstrap |
(none) | Configure TF backend (state) |
| Synthesize | cdk synth |
cdk8s synth |
cdktf synth |
| Preview | cdk diff |
kubectl diff -f dist/ |
cdktf plan |
| Deploy | cdk deploy |
kubectl apply -f dist/ |
cdktf deploy |
| Destroy | cdk destroy |
kubectl delete -f dist/ |
cdktf destroy |
Construct Hub helps developers find open-source construct libraries for use with AWS CDK, CDK8s, CDKTF and other construct-based tools.
| Language | AWS CDK | CDKTF | cdk8s |
|---|---|---|---|
| TypeScript | ✓ | ✓ | ✓ |
| JavaScript | ✓ | ✓ | |
| Python | ✓ | ✓ | ✓ |
| Java | ✓ | ✓ | ✓ |
| C# | ✓ | ✓ | |
| Go | ✓ | ✓ | ✓ |
The most used IaC language remains HCL, using Terraform or OpenTofu.
HCL syntax is designed to be easily read and written by humans, and allows declarative logic to permit its use in more complex applications.
HCL is declarative, compared to traditional programming languages which are imperative. HCL is a good fit for provisioning IaC, however some find it limiting. While solutions like Terragrunt address some of Terraform’s limitations, some wished for the flexibility of a full programming language. This was what led to the birth of HCL.
CDKTF still uses Terraform providers under the hood, and synthesizes to valid Teraform JSON.
At my client, I wanted to use OpenTofu for IaC. However, I was told that AWS CloudFormation is what’s already used internally at the client.
For my current use-case, my IaC mainly consists of an EC2 instance configured for use as a Bitbucket Runner. I decided to use AWS CDK for this use case, as it works with AWS CloudFormation but is more flexible than the JSON syntax that CFN uses.
Converting my working OpenTofu HCL code to AWS CDK TypeScript code was frustrating and made me curse AWS multiple times. However, I eventually got it working and functionally equivalent to what I already had working with OpenTofu.
I personally don’t find much value in using a “real” programming language for IaC. I believe Terraform owes a lot of success to the simple, imperative nature of HCL, and in some ways succeeded because of its limitations and not despite them.
My experiences with Pulumi and AWS CDK show me that if not being careful, the IaC could turn into spaghetti code. Of course, the potential for spaghetti code exists for HCL as well, especially when attempting to overcome some of its limitations. However, I believe for many of the common use-cases of IaC, the imperative design fits better and should be used unless there is a specific need for a “real” programming language.
Assuming I get the choice, I wouldn’t willingly use AWS CDK again. I have tried many IaC tools. Terraform, Ansible, OpenTofu, Terragrunt and Pulumi. Out of all ones I tried, AWS CDK was by far the most confusing.
I was initially interested in CDKTF, but it seems it has gained very little traction compared to Terraform or OpenTofu:
I was also concerned that CDKTF might not work well with OpenTofu. It seems it does currently work even if it’s not officially supported, but might break in the future: Port cdktf to OpenTofu · Issue #601 · opentofu/opentofu · GitHub
I believe that CDKTF is now an afterthought for HashiCorp, compared to Terraform. Development for CDKTF is not completely abandoned, but based on recent activity development seems slow and mainly focuses on fixes and dependency updates, rather than major new features.
I haven’t found a compelling reason to use this either. I’m not sure where exactly it fits into the Kubernetes manifest landscape between KYAML, Helm Charts, Kustomizations, CUE/HCL and GitOps solutions (mainly Argo CD and Flux CD).
Not technically CDK but is similar in many ways. Supports TypeScript, JavaScript, Python, Go, C#, Java and YAML. Last year, Pulumi introduced support for any Terraform Provider, With that, I believe Pulumi can serve as a solid replacement for CDKTF (not a drop-in replacement, but can be functionally equivalent). Unlike HashiCorp, which seems to treat CDKTF as an afterthought, Pulumi (the company) is primarily focused on Pulumi IaC. pulumi/pulumi is open-source under the Apache-2.0 license, though Pulumi as a company also offers paid solutions (such as Pulumi Cloud).
If I had to choose between CDKTF and Pulumi, I would lean towards Pulumi.
Photo by Abraham Barrera on Unsplash.
]]>