Re-thinking developer experience • Product @Gitpod 🍊 Helping folks get their start in cloud • @openupthecloud ☁️ AWS Community Builder 🛠 Replies in GIFS 😃
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.
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
Re-thinking developer experience • Product @Gitpod 🍊 Helping folks get their start in cloud • @openupthecloud ☁️ AWS Community Builder 🛠 Replies in GIFS 😃
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.
Hey Lou, thanks for your questions!
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)
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
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
Here's a take on native Terraform modules: dev.to/skorfmann/a-terraform-cdk-c...
Hey @skorfmann ich habe endlich ein Udemy kurs erstellt auf deutsch für CDK. Hier ist der Link: udemy.com/course/terraform-with-py...
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.