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

61–70 of 140 posts

Re: The future of Terraform CDK

#61

Post by crimsonnoodle58 »

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

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.

Re: The future of Terraform CDK

#62

Post by weakfish »

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.

Why? I’ve had nothing but good experiences, but I don’t run it and the team that does is extremely competent

Re: The future of Terraform CDK

#63

Post by cube2222 »

joombaga wrote: post #57
cube2222 wrote: post #44

Earlier quoted context omitted.

You can just switch from `count = 1` to `enabled = true` (or vice-versa, works back-and-forth) for a resource and tofu will automatically move it next time you apply. It's pretty seamless.

That's cool! We'll still need to change all of the references to `resource[0]`, right? Or does tofu obviate that need as well?

I’m not sure I understand. You refer to the conditional resource fields normally - without list indices. You just have to make sure the object isn’t null.

There’s some samples in the docs[0] on safe access patterns!

[0]: https://opentofu.org/docs/language/meta-arguments/enabled/

Re: The future of Terraform CDK

#64

Post by raw_anon_1111 »

ryandvm wrote: post #29
tapoxi wrote: post #13

Earlier quoted context omitted.

I went with CDK, I'm locked into AWS already and it means my major dependency for IaC is my cloud vendor and not a third party. If I really need to migrate off of AWS at some point I'll throw an LLM at it.

Exactly. It's just so much cleaner to do it in the Cloud provider's native tooling. The impedance mismatch from Cloud-agnostic abstractions always just makes thing shitty enough that in the long run you spend more time dealing with weird edge cases. Besides, actual full-scale Cloud migrations are exceedingly rare.

I always hated this meme. Using Terraform no more makes you “cloud agnostic” than using Python to script AWS services and calling boto3 than using bash and calling the AWS CLI.

Re: The future of Terraform CDK

#65

Post by pretext-1 »

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

Re: The future of Terraform CDK

#66

Post by pizza234 »

lijok wrote: post #32
crimsonnoodle58 wrote: post #27

This is particularly frustrating as I've spent the last year writing many thousands of lines of CDKTF Python. HCL just does not have the modularity and expressiveness that Python, or other languages CDKTF supports. I guess I'll spend another year migrating to Pulumi now..

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

That's very subjective. Concepts like iterations are inevitable, and they don't look great in a declarative language like HCL.

I also find refactorings considerably harder in a declarative language, since configurations have a rigid structure.

Re: The future of Terraform CDK

#67

Post by preisschild »

mfornasa wrote: post #46
lillecarl wrote: post #33

Earlier quoted context omitted.

This is why infrastructure people are conservative by nature, it's so damn much gruntwork to migrate without downtime

And it happens while we are all very enthusiastically dedicated to migrating off Kubernetes ingress-nginx. Just as planned.

As an Infrastructure Engineer who used it: I blame people who didnt help fund/maintain it (including ourselves)

Re: The future of Terraform CDK

#69

Post by Duologic »

leetrout wrote: post #14
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

The often excluded option is dynamically generating JSON and feeding that to TF instead of HCL. You can combine it with tools like Dhall or my personal preference Jsonnet instead of imperative languages for an interesting experience for reusable pieces outside of module concepts.

Any particular libraries you use to generate TF-JSON from jsonnet?

I wrote a generator a little while ago that can create jsonnet libraries from the TF schemas: https://github.com/Duologic/soysonnet

Example lib here: https://github.com/Duologic/soysonnet-aws

I only needed it for AWS so I didn't spend more time on it.

Re: The future of Terraform CDK

#70

Post by huddo121 »

jjice wrote: post #5
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.

> It's odd to always say "Hashicorp, an IBM company". Looks like they want to assign blame. All their branding does this now, including the HashiCorp logo on their website [0]. There's gotta be a name for this specific branding pattern, but I don't know it. [0] https://www.hashicorp.com/en/blog/products/terraform

Metastatized branding
Post reply on HN