DEV Community

Cover image for The Journey from Terrastack to Terraform CDK
Sebastian Korfmann
Sebastian Korfmann

Posted on

The Journey from Terrastack to Terraform CDK

The initial version of Terrastack was built over the course of a few days in March 2020. It was built around the same concepts as the AWS CDK and shared a similar vision: Leveraging imperative programming languages such as Typescript, Python, Java and C# to build out infrastructure with the Terraform engine.

While my intention with the prototype was to raise awareness and get support for further development, I didn’t anticipate pushing at an open door.

Fast forward four months, the successor of Terrastack - the Terraform CDK - got launched as a joint effort by Hashicorp, the AWS CDK team and me :) It turned out that Hashicorp and the AWS CDK team started to work together on the exact same idea long before I published Terrastack. They reached out to me and I’m still very grateful for the opportunity to join the ongoing project as an independent contributor.

GitHub logo hashicorp / terraform-cdk

Define infrastructure resources using programming constructs and provision them using HashiCorp Terraform

npm version PyPI version NuGet version Maven Central homebrew

CDK for Terraform

Cloud Development Kit for Terraform (CDKTF) allows you to use familiar programming languages to define cloud infrastructure and provision it through HashiCorp Terraform. This gives you access to the entire Terraform ecosystem without learning HashiCorp Configuration Language (HCL) and lets you leverage the power of your existing toolchain for testing, dependency management, etc.

We currently support TypeScript, Python, Java, C#, and Go.

terraform platform

CDKTF includes two packages:

  • cdktf-cli - A CLI that allows users to run commands to initialize, import, and synthesize CDK for Terraform applications.
  • cdktf - A library for defining Terraform resources using programming constructs.

Get Started

Choose a language:

Hands-on: Try the tutorials in the CDK for Terraform collection on HashiCorp Learn.

Documentation

Refer to the CDKTF documentation for more detail about how to build and manage CDKTF applications, including:

The community preview of the Terraform CDK is considered an alpha version. There are lots of rough edges which we’ll iron out over the next few months. Nevertheless, the sentiment of the feedback has been quite positive so far. There are more than 600 stars on Github, a bunch of contributions to the Github repository and roughly 1500 downloads via NPM within one week after the launch. That’s fantastic and makes me excited about the future of the Terraform CDK.

Here’s a little real world example, which I migrated from Terrastack to Terraform CDK.

GitHub logo skorfmann / cdkweekly

Terraform CDK SSL Proxy for cdkweekly.com

Terraform CDK SSL Proxy for cdkweekly.com

The CDK Weekly newsletter is served by revue.co, which doesn't support SSL for custom domains.

This little workaround was initially built on top of Terrastack and got migrated to its successor Terraform CDK. It's the first real world example for the Terraform CDK and is running in production for a while now.

Setup

npm install
cdktf get

Deploy

cdktf deploy

That's where one of the Terraform CDK examples is stemming from.

Next Up:

  • Redirect naked domain -> www (probably including SSL via Cloudfront distribution)
  • Inject Google Analytics or something similar
  • Migrate state to Terraform Cloud



I’m currently working on yet another example, which will be a bit more elaborate and demonstrate a more complex use case.

When you’re interested to learn more about the Terraform CDK, here are some resources to get you started:

If you have feedback or feature requests, the Github repository is a good starting point. We try to follow up on newly created issues quickly. I’d love to hear from you.


ps: The actual first version of Terrastack dates back to the end of 2018 and was sort of Terragrunt on steroids powered by Typescript. I had lots of fun building that prototype back then together with Andreas Litt.

pps: If you're interested to keep up with what's happening in the CDK ecosystem, you should consider signing up to cdkweekly

Latest comments (6)

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️) • Edited

Hey Sebastian! Firstly, thanks a lot for the work on the CDK! It seems super promising and something I think the Terraform community has been thinking about / talking about for a while. After playing with the CDK for the last few days, I'm curious about a couple things, if I may...

1) Is there any indication from Hashicorp for them to invest in their website to have polyglot documentation and examples? This seems like a big sticking point initially since the entire community is on HCL. It seems like a lot of energy would have to go into converting the examples somehow.

2) Do you think the CDK is somewhat antithetical to the original ideas of HCL and the declarative nature of Terraform? It seems that hashicorp originally intended a simplistic, no frills configuration language, presumably to protect the declarative nature of the tool. Do you think adding additional abstractions and constructs possible in a full blown programming language pose a threat to the declarative model and the ability to "see" in configuration a reflection of your infrastructure (which might get buried in abstractions?) Or do you just see it as the developers responsibility to not let that get out of hand?

3) Are there any ideas on how module interoperability will work? Specifically between the CDK and regular HCL Terraform. It seems like Terraform modules will work with the CDK, but will it be possible for CDK modules to work with regular Terraform? I don't see how, but this seems like an interesting problem. This means that CDK users would be more likely end-consumers, and not module publishers (unless for other CDK users, i guess).

Again, thanks a lot for all your contributions! I look forward to playing around with the CDK more in future, too.

Collapse
 
skorfmann profile image
Sebastian Korfmann

Hey Lou, thanks for your questions!

1) Is there any indication from Hashicorp for them to invest in their website to have polyglot documentation and examples? This seems like a big sticking point initially since the entire community is on HCL. It seems like a lot of energy would have to go into converting the examples somehow.

All which this would require is a HCL/JSON -> Typescript converter (see cdk.tf/issues/232), and I know that the foundation for someting like this was built already. Once we've got Typescript, we could generate all other target languages as well with github.com/aws/jsii/tree/master/pa... (see also cdk.tf/issues/207)

2) Do you think the CDK is somewhat antithetical to the original ideas of HCL and the declarative nature of Terraform? It seems that hashicorp originally intended a simplistic, no frills configuration language, presumably to protect the declarative nature of the tool. Do you think adding additional abstractions and constructs possible in a full blown programming language pose a threat to the declarative model and the ability to "see" in configuration a reflection of your infrastructure (which might get buried in abstractions?) Or do you just see it as the developers responsibility to not let that get out of hand?

Personally, I see the Terraform CDK as a complementing tool for the Terraform ecosystem. It opens up new approaches to defining infrastructure, which likely attracts a different audience. And after all, the Terraform CDK still synthesizes to HCL compatible JSON (and perhaps HCL at some point cdk.tf/issues/225).

If you're interested in an official answer to this, you should head over to the discussion board at cdk.tf/discuss

3) Are there any ideas on how module interoperability will work? Specifically between the CDK and regular HCL Terraform. It seems like Terraform modules will work with the CDK, but will it be possible for CDK modules to work with regular Terraform? I don't see how, but this seems like an interesting problem. This means that CDK users would be more likely end-consumers, and not module publishers (unless for other CDK users, i guess).

That's a great question. Building a Construct library which is both usable as ckdtf package and Terraform module is totally possible. I'll create a little example

If the polyglot documenation and better module support is something you'd like to see, I'd like encourage you to create two issues in the Github repo cdk.tf/feature

Collapse
 
skorfmann profile image
Sebastian Korfmann

Here's a take on native Terraform modules: dev.to/skorfmann/a-terraform-cdk-c...

Thread Thread
 
jomach profile image
Jorge

Hey @skorfmann ich habe endlich ein Udemy kurs erstellt auf deutsch für CDK. Hier ist der Link: udemy.com/course/terraform-with-py...

Collapse
 
loujaybee profile image
Lou (🚀 Open Up The Cloud ☁️)

Thats amazing, thanks a lot for taking the time to respond!

I'll share this response with some colleagues, as these were questions we raised when discussing adopting the CDK and doing some thinking on it.

Collapse
 
yaldram profile image
Arsalan Ahmed Yaldram

Congratulations Sir and best of luck with your new role.