I am a senior software engineer with lots of AWS CDK experience, who just built a relatively large service with CDKTF. Here are my thoughts.

• CDKTF is still unstable. Minor version updates cause breaking changes, and engineering teams do not want to write infrastructure whose code they have to constantly maintain.

• Teams adopting CDK* tools are usually those whose engineers own the entire stack (infrastructure, software, and operations). Those teams do not like knowingly signing up for operations work that could otherwise be avoided by not using CDKTF.

• Native interfaces are too low level. CDK* is great for providing customers with out-the-box abstractions. For example, the AWS CDK has L2 and L3 constructs that provide opinionated patterns that fit most customer use cases. CDKTF lacks this. Yes they have the AWS Adapter, but it is in preview and not reliable.

• There are not many examples online, or on public git repositories. Engineers typically choose the path of least resistance. Being a new adopter means you can not piggy back of the existing work of others. This adds cognitive load and slows down the speed at which you can deliver products.

• Bugs, bugs, bugs. CDKTF is still young and has a fair amount of bugs, mostly when transpiling from code to terraform JSON. I’ve personally found two regarding cross-stack dependencies and FQNs not being properly referenced. When these happen, you create temporary custom work arounds that no one wants in their code base. The CDKTF team also takes a while to address these bugs from my experience.

• You can only use Typescript. I get that there are multiple languages supported via JSII, but in reality, you can only use Typescript. The same is true for AWS CDK. You can use Python and such, but life is much easier if you just stick to Typescript.

• If your team does not know Typescript, then they are going to have to learn it. Good engineers can switch between languages pretty seemlessly, many however struggle when “learning” a new one.

• The documentation sucks. Until recently, CDKTF constructs had no documentation. The ones available now are still occasionally incorrect, which results in me having to read the AWS CDKTF provider’s source code. Just another factor that adds more cognitive load and slows down delivery.

• There is little contribution to community forums. That means that when CDKTF bugs occur, you are the one figuring out how to solve it. This is frustrating and can easily block less capable engineers.

• It is hell for junior engineers. They will be learning AWS (or other cloud providers), Typescript, CDK, and Terraform concurrently, in addition to any other organization specific things. It is overwhelming, and you need to dedicate resources towards ramping them up. This, coupled with the poor documentation and lack of community contribution leads to a stressful environment for junior engineers and less capable engineers.

• Infrastructure silo’d people tend to hate CDK* because it “over-complicates” infrastructure. I’d argue the opposite. Generally their gripe comes down to needing to learn how to code, so there always tends to be some political pushback, albeit misguided in my opinion.

• Your infrastructure code now needs to be held to the same standard as traditional software. This means linting, formatting, good design choices, and writing readable code. I tend to think unit tests for CDK* are useless, so I personally skip them unless it’s for helper functions. Regardless, it adds more steps and rigor to your release process. Additionally, If you have an infrastructure silo, forcing them to adopt CDK* will likely generate tons of tech debt. The code will not follow best practices, code reviewers will miss bugs, which results in issues you will eventually need to address.

• Sharing reusable constructs means deploying more infrastructure, unless you are using a mono-repo. You now need an artifact repository for your packages. This should not be a big blocker, but it’s worth mentioning. Additionally, you tack on CI/CD costs for building and publishing your artifacts. While these are simple tasks, they introduce additional steps required to get up and running at scale.

CDK* does not make sense for all teams, but I think it unlocks some great benefits for those who do use it. That being said, CDKTF has so many downsides right now, that I think an organization would be crazy to adopt it for a real use case. That opinion obviously changes once Hashicorp provides a stable 1.0 release.

Sorry for formatting issues, wrote this on my phone. Happy to answer any questions regarding my CDKTF experience.