Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of Terraform CDK

github.com

Post reply on HN
Print view View original

71–80 of 140 posts

Re: The future of Terraform CDK

#71

Post by lijok »

crimsonnoodle58 wrote: post #61
lijok wrote: post #56

Earlier quoted context omitted.

Getting too clever with an imperative language in what is inherently a declarative domain, is an idea bad enough that they invented a whole new language to avoid you doing it. But some lessons have to be learned the hard way I guess

Yet said language continues to add imperative-inspired constructs to make up for its limitations.. The end result is still declarative, your just using an imperative language to keep your IaC DRY.

If you have the expertise and restraint to not go off the rails, I agree, imperative is more powerful. That plan does not survive teams of sizes over 2 in the majority of cases.

Re: The future of Terraform CDK

#72

Post by cholantesh »

stackskipton wrote: post #35
cholantesh wrote: post #24

Earlier quoted context omitted.

Yeah I'm struggling to see the value here.

The value for TFCDK was Developers don't have to learn another language, they can just continue to use existing language they already know. Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.

I ought to have phrased it I guess as "I don't agree with the value proposition", mainly because of the downside you point out. This seems superior to Pulumi, though, in that the abstraction is (was) at least owned by Hashicorp so there was less likelihood of it falling out of date and giving you footguns.

Re: The future of Terraform CDK

#73

Post by resonious »

mfornasa wrote: post #10
GardenLetter27 wrote: post #6

Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.

Probably Pulumi

I'll be honest Pulumi is pretty cool but I'm a little worried by how high on the stack it is. I wonder if the same thing won't happen to them that's happening to CDKTF here.

Terraform is ugly but it works well enough for me and seems ingrained enough to be durable to this kind of thing (i.e. I bet for sure the community would pick it up (I wish I could say that I'm part of that community but I can't say I use it quite that often))

Re: The future of Terraform CDK

#74

Post by joeduffy »

zer0-c00l wrote: post #7

This is a bummer. I don't particularly like Pulumi but use it anyways because for my use cases being able to write actual code is really impactful. Sucks to see fewer options in that space

[Pulumi founder here] Sorry to hear you don't particularly like Pulumi---any/all feedback welcome. If nothing else, we do listen and we do try to get better. -Joe

Re: The future of Terraform CDK

#75

Post by coenhyde »

stackskipton wrote: post #35
cholantesh wrote: post #24

Earlier quoted context omitted.

Yeah I'm struggling to see the value here.

The value for TFCDK was Developers don't have to learn another language, they can just continue to use existing language they already know. Downsides are doing infrastructure in a programming language was always problematic unless developer was skilled at Ops which most who used TFCDK were not.

That might have been the promise but never the real value. As you say in practice the engineer needs to know ops & terraform along side their language of choice.

The real value of cdktf was more dynamic infrastructure provisioning while still having the plan / apply pattern.

Re: The future of Terraform CDK

#76

Post by borisbanjo »

CDKTF works beautifully, all the complains here seem to be from salty devops who got pissed the developers wanted something more powerful than the garbage HCL with its even more garbage module system.

CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.

Re: The future of Terraform CDK

#77

Post by dastbe »

lijok wrote: post #56
crimsonnoodle58 wrote: post #51

Earlier quoted context omitted.

Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.

Getting too clever with an imperative language in what is inherently a declarative domain, is an idea bad enough that they invented a whole new language to avoid you doing it. But some lessons have to be learned the hard way I guess

They invented a language to avoid you imperatively updating infrastructure, but that's not what CDKTF does; it just makes it easier to materialize that declarative output.

It also makes it easier to reason about that output as you can avoid awkward iteration in your declarative spec.

Re: The future of Terraform CDK

#78

Post by everforward »

lijok wrote: post #56
crimsonnoodle58 wrote: post #51

Earlier quoted context omitted.

Being able to inherit from Ingress and add a parameter of say public=True/False and then it change annotations, middleware, etc and then being able to re-use that across 100s of stacks is very powerful. DRY is not something HCL is good at.

Getting too clever with an imperative language in what is inherently a declarative domain, is an idea bad enough that they invented a whole new language to avoid you doing it. But some lessons have to be learned the hard way I guess

The problem is they did an exceptionally poor job at designing their language. A reasonably large Terraform codebase is almost universally hard to read for one of two reasons: it's either unexpressive (read: verbose to the point it's hard to read) or modularized but hard to read because it's fragmented into a bajillion reusable modules.

SQL is also declarative, but incredibly expressive. A thousand character query contains enough complexity that it's hard to reason about. A thousand characters of Terraform will barely stand up a CRUD app on AWS.

Designing a language from first principles for this was a mistake. HCL is awful; they should have gone the Starlark route and made a stripped-down version of an existing language instead of making their own language from scratch. This feels like the worst of both worlds. The language is practically imperative, but it has its own syntax that isn't useful outside of this one single domain.

Re: The future of Terraform CDK

#79

Post by willio58 »

packetlost wrote: post #39
vbernat wrote: post #2

It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame. I did try Pulumi a while back, but the compatibility with Terraform modules was not great, so I've switched to CDKTF, which can handle unmodified modules. Dunno if I'll switch back to Pulumi or just use OpenTofu directly.

I have absolutely nothing good to say about Pulumi. Stay far, far away.

My experience with Pulumi is you can write bad pulumi code and good pulumi code and just like everything else, it's easy to end up in a codebase where one poor soul was tasked with writing it all and they didn't do the best job with it.

Re: The future of Terraform CDK

#80

Post by nijave »

borisbanjo wrote: post #76

CDKTF works beautifully, all the complains here seem to be from salty devops who got pissed the developers wanted something more powerful than the garbage HCL with its even more garbage module system. CDKTF stacks are great and the construct pattern gives you modularization without all the baggage.

I kind of like it but I always found it kind of clunky how it's ultimately just generating JSON/HCL anyway. For instance, you can't data source then use code to transform and send it to a resource since it has to transpile first.

That also means you end up with things like the language's native JSON not doing what you expect and having to use a special Terraform function call.

Post reply on HN