Live data from Hacker News

The future of Terraform CDK

github.com

81–90 of 140 posts

Re: The future of Terraform CDK

#81
post #71

Earlier quoted context omitted.

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.

But it's not even imperative. Your code runs, declares all its resources up front and then normal terraform runs on it. With cdktf you can even have it output the HCL.

At the point where we are templating Terraform files we've already lost the plot. You might as well get to use a real programming language.

Re: The future of Terraform CDK

#82
post #32

Earlier quoted context omitted.

The lack of expressiveness of HCL is the point and what makes it so good

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.

That is... not a good idea at all imo. It's very, very easy to over-DRY infrastructure config and it sounds like you're well past that point.

Re: The future of Terraform CDK

#84
post #56

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

I have used Terraform, Puppet, Helm, and Ansible (although that's not strictly declarative), and all of them ran into problems in real-world use cases that needed common imperative language features to solve.

Not only does grafting this functionality onto a language after-the-fact inevitably result in a usability nightmare, it also gets in the way of enabling developer self-service for these tools.

When a developer used to the features and functionality of full-featured language sees something ridiculous like Terraform's `count` parameter being overloaded as a conditional (because Terraform's HCL wasn't designed with conditional logic support, even though every tool in this class has always needed it), they go JoePesciWhatTheFuckIsThisPieceOfShit.mp4 at it, and just kick it over to Ops (or whoever gets saddled with grunt work) to deal with.

I'm seeing the team I'm working with going down that same road with Helm right now. It's just layers of templating YAML, and in addition to looking completely ugly and having no real support for introspection (so in order to see what the Helm chart actually does, you essentially have to compile it first), it has such a steep learning curve that no one other than the person that come up with this approach wants to even touch it, even though enabling developer self-service was an explicit goal of our Kubernetes efforts. It's absolutely maddening.

Re: The future of Terraform CDK

#85
post #32

Earlier quoted context omitted.

The lack of expressiveness of HCL is the point and what makes it so good

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.

Make a module

Re: The future of Terraform CDK

#87

That’s a real shame. It seems like Pulumi is the only alternative for internal DSLs for IaaC? I always found HCL to be quite terrible, slowly becoming less painful, but not really refactoring-friendly. Terraform CDK had promise as a blessed infrastructure-as-actual-code solution from the official maintainer of Terraform, so easier to sell internally rather than something from a new vendor like Pulumi. I feel sorry fo…

Kubernetes has a few things, including cdk8s. Yoke looks promising too.

[dead]

Re: The future of Terraform CDK

#88
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.

It’s how Red Hat identifies themselves too

It's common when corps buy large enough companies that they don't want to kill the original brand. That's why you get hotels like "(something) by Hilton".

Re: The future of Terraform CDK

#89
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 was recently working for a company which got acquired by IBM and we had to do it too. It’s an IBM thing. I bet most people at HashiCorp hate it, at least that was the case for us.

Makes IBM look really bad. Do they also force people to bow when the CEO of IBM enters the room, and address them as sir or your highness?

Re: The future of Terraform CDK

#90

Earlier quoted context omitted.

I was recently working for a company which got acquired by IBM and we had to do it too. It’s an IBM thing. I bet most people at HashiCorp hate it, at least that was the case for us.

Makes IBM look really bad. Do they also force people to bow when the CEO of IBM enters the room, and address them as sir or your highness?

They used to have their employees sign songs praising the company...

Granted, that was in the 1930s or something, but still.

Post reply on HN