121–130 of 140 posts
Sad to see it go. The philosophy of CDK has been to offer a shared ecosystem between IaC, backend code and frontend code, allowing to share configuration, data structures and libraries between all of them. It has made development more unified and have less redundancy and manual work. Personally I don't want to repeat some stuff in a special Terraform language, if I can find a way to manage the whole application in Ty…
Damn, what are the best alternatives here? For pure AWS I guess CDK directly is okay, but locks you in.
Sad to see it go. The philosophy of CDK has been to offer a shared ecosystem between IaC, backend code and frontend code, allowing to share configuration, data structures and libraries between all of them. It has made development more unified and have less redundancy and manual work. Personally I don't want to repeat some stuff in a special Terraform language, if I can find a way to manage the whole application in Ty…
Pulumi
Earlier quoted context omitted.
They used to have their employees sign songs praising the company... Granted, that was in the 1930s or something, but still.
I remember it being a part of the movie Pirates of Silicon Valley and thought it couldn’t be true. But apparently it was. https://youtu.be/VyQEbLx6AEY?si=CwhqHQEdFGCsE33l
Earlier quoted context omitted.
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 co…
> reasonably large Anyway you shouldn't have too many resources in a single Terraform workspace, for performance reasons. The real issues with Terraform come when you start to want to orchestrate different workspaces triggering each other, and trying to write that orchestration language, which itself would be declarative. Terraform built a Stacks feature, but support is Terraform Cloud-only. OpenTofu has issues in th…
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.
Earlier quoted context omitted.
I have absolutely nothing good to say about Pulumi. Stay far, far away.
Please expand on your experiences, because I've had great luck with Pulumi at my company since October 2021. No engineer liked HCL, our demographic was engineers who were familiar with programming languages who wanted to self service basic infrastructure (AWS SecretsManager, IRSA roles, Databricks Service Principals, etc). We were pretty easily able to shim in a RunAtlantis inspired system that displayed previews tha…
One example:
You can't really build custom TS providers for AWS resources.
Why?
Because this feature is built using the compilation magic that makes inline lambdas work.
But the compilation step omits the AWS SDKs since these are present in a lambda anyways. So you can't use the AWS SDK in custom providers.
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.
And you don't get the annoying array form for the resulting resource with the `enabled` syntax, right? EDIT: Oh just realized the sibling asked the same, but the doc doesn't state that clearly, although it seems to me that the doc implies that yeah, it doesn't use the array form anymore.
Earlier quoted context omitted.
> reasonably large Anyway you shouldn't have too many resources in a single Terraform workspace, for performance reasons. The real issues with Terraform come when you start to want to orchestrate different workspaces triggering each other, and trying to write that orchestration language, which itself would be declarative. Terraform built a Stacks feature, but support is Terraform Cloud-only. OpenTofu has issues in th…
I'd argue the real issue with Terraform is that workspace orchestration is necessary in the first place. If they addressed the performance issues with large workspaces, then we wouldn't need to split up workspaces and Terraform could just orchestrate changes naturally.
You split the workspace into smaller workspaces precisely to tell Terraform that you haven't made any changes to the networking layer, so don't bother trying to refresh the status of the networking layer to see if any changes are needed, it's not relevant when you're trying to scale up your Kubernetes cluster or whatever.
As an alternative is anyone considering https://sst.dev/ (which uses Pulumi under the hood)? We use it at work and I’ve been quite happy with it
It’s not an alternative at all. Terraform CDK is basically TypeScript transpired to HCL. You can codegen TypeScript bindings for any provider. And then write normal TypeScript.
transpiled to JSON