Recently, Terraform dropped an interesting new extension to their Terraform toolchain: the Terraform CDK. The new CDK allows you to write Terraform using TypeScript and Python — neat! But is the CDK as good as it seems?
I wanted to jump in to uncover the truth and understand whether writing Terraform in TypeScript really is the future, or whether it’s just another fad.
By the end of this article you’ll understand what the Terraform CDK is, how it works, and ultimately help answer the question: should you use it?
Before we jump into the details of the CDK, and what it can bring to the table, it makes sense to take a brief step back to look at what the world of Terraform was like just a month ago before the announcement of the CDK.
Anyone who starts using Terraform will soon come into contact with Terraform’s language, HCL (Hashicorp Configuration Language). But, incase you’re new to Terraform and HCL, let’s do some recap.
Terraform In HCL
HCL is a language created by Hashicorp, which was built as a more expressive language than JSON, yet more restrictive than your typical programming language, to be more fitting to the ops and configuration world.
Naturally though, by introducing a new language, HCL brings its own nuances, ideas and a learning curve. After using HCL for quite some time, personally, I’d argue that it’s not particularly complicated as far as languages go.
Yet, the big problem with HCL is indeed the mental hurdle. HCL looks complicated, and it looks foreign. If you’re coming to the ops world entirely new, adding another language to the pile can just increase how daunting the task is.
And that’s where the CDK comes in…
What Is The Terraform CDK?
The Terraform CDK is a wrapper around traditional Terraform which allows you to write Terraform code, in a different language. Currently that’s TypeScript and Python, but in the future there may well be more supported languages.
Terraform Written In The CDK
How it works In technical terms is: you write Terraform as TypeScript (or Python) which is compiled to result in a JSON output. This JSON output is readable by Terraform, and you can then use your typical Terraform plan, apply, etc workflows using this JSON file as your infrastructure definition. Simple.
But for those who have been following the infrastructure as code world, you might look at this announcement and think: “Hasn’t this whole ‘infrastructure as code written in a regular language’ been done before? And you’d be right…
Other Multi-Language IaC Tools
The idea of infrastructure as code written in typical programming languages is definitely not a new idea. Since infrastructure as code’s inception, engineers will have been dreaming of a full stack written in a single language.
The AWS CDK, for instance, is an existing tool which allows you to write CloudFormation infrastructure as code in ‘regular’ programming languages (the Terraform CDK uses the same underlying tech). But, the big downside with the AWS CDK itself is that it’s AWS focussed.
Yet, there are other projects, that are not only AWS, which attempt the whole ‘write any language infrastructure as code’ thing, and probably the most noteworthy of those tools is is Pulumi.
Pulumi is a tool that is (maybe was) growing in popularity as a competitor to Terraform, touting its one key selling point: you can write Pulumi code in many different languages. Pulumi are still listing multi-language this as their top differentiator from Terraform, so I guess that page now needs to be revised.
Pulumi Vs Terraform
But, I don’t believe the CDK announcement comes because of some perceived threat from Pulumi. I believe that it’s just a natural next step for Hashicorp to take with Terraform, making the tool even more ubiquitous than it already is.
Terraforms existing community is simply larger, and more mature than Pulumi, which allows Terraform to leverage “network effects” and grow its appeal.
It’s one thing to talk about the CDK when comparing it to other tools, but how does the CDK stand on its own, what is the CDK like as a tool?
Terraform CDK, The Good Parts
Aside from the other, hopefully more obvious, benefits, such as writing in a familiar language, having expressive language concepts like loops, conditionals, and so on. The CDK tool does have some appealing things inherent in it’s design.
The CDK Compiles into Terraform — One aspect I was very happy to see with the new CDK is how seamlessly it integrates back into regular Terraform tooling. By compiling a JSON that is read by Terraform, migrating from existing Terraform stacks into the CDK would be a relatively low pain journey.
Terraform CDK JSON
Using AWS constructs — The CDK leans heavily on AWS open source, such as JSII and constructs for it’s functionality. These seem to be well supported projects, and look to be a great foundation for the new CDK tool.
And what about the downsides to the CDK?
Terraform CDK, The (Not So) Good Parts
The downsides to the CDK are where things get interesting to me. The tool works mostly as you’d expect, so really the crux of the question: “Should you use the Terraform CDK?” lies in your assessment of these not so good parts.
Now, of course, the CDK is in early days, so some of these ‘not so good parts’ could indeed get smoothed out over the long term. But regardless, we’re presented with some fairly sharp edges that are worth pondering.
Added Complexity — Terraform conceptually is seemingly simple, but at times it can seem overly fiddly and complex, and I don’t think the CDK helps in this regard. With the CDK comes an influx of configurations. The CDK compilation step adds yet another point in the process for things to go wrong, where you can get tied up in knots of configuration hell. I mean, a look at the amount of config that is required in order to run the CDK and you’ll see what I mean.
CDK Folder Structure
Lack Of Examples — The Terraform community is built around (the original) HCL method of writing Terraform, which introduces added friction when using the CDK and writing anything other than HCL. Reading the official docs, copying between projects and searching error messages on the internet are now a little bit made difficult for you if you use the CDK.
Terraform Docs In HCL
Module Interoperability — It seems the CDK will support regular Terraform modules, for code sharing. But it does remain to be seen if module sharing can be reversed. Can a CDK project publish a module which is then consumed by HCL? If you’d have to learn HCL to write and share a module, that mostly defeats the point of using the CDK in the first place.
So, Is The CDK The Future?
Despite what we’ve talked about today, especially some of the ‘not so good parts’ of the CDK, we should remind ourselves that it’s still early days for the CDK. The CDK is currently in alpha, and will undoubtably go through more iterations and come out the other side well-rounded.
And this brings us to our original question: Should you use the Terraform CDK? My short answer would be: yes. Use the CDK in some non-production projects, play around with it, write up your experiences, give feedback and experiment.
But the long answer is: we’ll have to see how the CDK progresses. I think the success of the CDK will lie in how strongly the community, and Hashicorp get behind the CDK, how quickly and how well they update the docs, and help out with documenting all the inevitable error scenarios.
Hopefully, just hopefully, the CDK could be the beginning of a bridge in the gap between application development and infrastructure, and maybe it could be as game-changing as the release of Node.JS in bringing together a full stack technology in a common language.
And on that note, that’s everything for today, until next time..
Speak soon Cloud Native friends.
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022