4 ms·

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

by GardenLetter27 10mo ago

scruff3y 10mo ago
Just use Terraform?
- deleted 10mo ago
  [deleted]
- cholantesh 10mo ago
  Yeah I'm struggling to see the value here.
  - stackskipton 10mo ago
    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.
    - cholantesh 10mo ago
      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.
    - coenhyde 10mo ago
      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.
- rendaw 10mo ago
  The value of CDK was always that it allowed you to write in a fully orthogonal language rather than the poor pseudo-language of hcl. When writing stacks you need normal language features: loops, yes, but also if statements, reuse (functions), being able to do stuff like complex string parsing and re-formatting, etc etc. HCL supports loops, modules can be kind-of used as functions with lots of footguns, there are awful hacks for some other things, and some stuff just couldn't be done.
sshine 10mo ago
Terranix? ;-)
- madjam002 10mo ago
  Not gonna lie Terranix has been working great for us, all our configuration is in Nix files anyway so it's so easy to just pass stuff in rather than using Tf variables etc
- lillecarl 10mo ago
  Yes, the NixOS module system is so much more composable than the TF one
mfornasa 10mo ago
Probably Pulumi
- resonious 10mo ago
  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-thc 10mo ago
    > I wonder if the same thing won't happen to them that's happening to CDKTF here. This is clearly a business decision rather than technical. Pulumi is meant to be semi-automated (in generating the bridges) so perhaps is slightly better off in maintenance.
srmatto 10mo ago
If you want maximal complexity use Crossplane. :P
tapoxi 10mo ago
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.
- ryandvm 10mo ago
  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.
  - emoII 10mo ago
    Terraform is not an abstraction on top of multiple cloud providers, you work with aws, azure etc explicitly. It is , however, agnostic in the sense that you can provision aws, azure, gcp, etc resources within the same iac project
  - raw_anon_1111 10mo ago
    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.
  - thayne 10mo ago
    AWS's native tooling is Cloudformation, and CDK is actually just a wrapper around that that generates cloudformation code (as CDKTF is a wrapper for terraform). And I like to avoid cloudformation as much as possible.
  - GuinansEyebrows 10mo ago
    writing HCL is so much more enjoyable than writing CF, even if HCL is fairly verbose (hey, it's not as bad as XML!). CF feels like a series of PM requirements dutifully codified with no dogfooding whereas HCL/TF feels like a tool that was developed by people who actually wanted to use it.
tetha 10mo ago
Hm, we have a few very repetitive terraform projects to setup structured infrastructure clusters. For those, we just use ansible with a bunch of templating to generate a configurable, HCL-based terraform module and version that. It's a bit of an "Caveman solve problem with rock" approach, but for very regular projects it's great. A new cluster is some group vars, larger changes to the structures can be easily reviewed - and if you really really have to, you can also just modify the generated code by hand to fix something your generation code can't deal with right now.
rendaw 10mo ago
I made https://github.com/andrewbaxter/terrars https://github.com/andrewbaxter/terrars ! It's great! You get more benefits if you're in a Rust project (obviously) but it has some things that make it a good alternative anywhere: - More accurate types/type safety than the CDK (for static feedback on required parameters, etc) - No CLI required - just plain Rust (provider definitions can be published as normal rust packages so you don't have to generate them yourselves, and I've published a bunch of common ones - docker, aws, etc) - Simpler: Terraform CDK had this crazy flow where it (go code) generated typescript code then used some transpiler to generate target language code. The output wasn't pretty, and there were bugs. Your project directory would get filled with boilerplate generated files. It generates tf json files and has a fairly safe way for handling variable interpolation and escapes - I haven't hit any weird bugs with it.
theknarf 10mo ago
Normal Terraform, Pulumi or OpenTofu
- rweichler 10mo ago
  As a complete noob to the space, as an individual, who doesn't care about being "hireable" or whatever, which one has the highest ROI? OpenTofu?
exidy 10mo ago
> but locks you in Not picking on you personally but having had this conversation many times over many years with many clients I find it confounding. Oftentimes TF itself was heavily promoted as a way of "avoiding lock in". Well guess what? Now you're locked-in to IBM, whose motivations may not be perfectly aligned to you goals of simply and efficiently using your cloud provider of choice to deliver your business outcomes. What we refer to as lock-in is simply an expression of risk, with one axis being the cost of getting off $solution and the other being the likelihood of needing to do so. Having stepped through this exercise a few times, the cost of rewriting your e.g. AWS API Gateway + Lambda + SQS + RDS + CloudWatch etc architecture invariably vastly dwarfed the cost of changing the IaC language it is expressed in. Anytime you feel the urge to overbuild on a cloud provider's services, stop, and do a really rigorous cost/benefit analysis. If you truly have unique drivers the data should tell the story.

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

scruff3y 10mo ago

Just use Terraform?

deleted 10mo ago
[deleted]
cholantesh 10mo ago
Yeah I'm struggling to see the value here.
- stackskipton 10mo ago
  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.
  - cholantesh 10mo ago
    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.
  - coenhyde 10mo ago
    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.
rendaw 10mo ago
The value of CDK was always that it allowed you to write in a fully orthogonal language rather than the poor pseudo-language of hcl. When writing stacks you need normal language features: loops, yes, but also if statements, reuse (functions), being able to do stuff like complex string parsing and re-formatting, etc etc. HCL supports loops, modules can be kind-of used as functions with lots of footguns, there are awful hacks for some other things, and some stuff just couldn't be done.

sshine 10mo ago

Terranix? ;-)

madjam002 10mo ago
Not gonna lie Terranix has been working great for us, all our configuration is in Nix files anyway so it's so easy to just pass stuff in rather than using Tf variables etc
lillecarl 10mo ago
Yes, the NixOS module system is so much more composable than the TF one

mfornasa 10mo ago

Probably Pulumi

resonious 10mo ago
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-thc 10mo ago
  > I wonder if the same thing won't happen to them that's happening to CDKTF here. This is clearly a business decision rather than technical. Pulumi is meant to be semi-automated (in generating the bridges) so perhaps is slightly better off in maintenance.

srmatto 10mo ago

If you want maximal complexity use Crossplane. :P

tapoxi 10mo ago

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.

ryandvm 10mo ago
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.
- emoII 10mo ago
  Terraform is not an abstraction on top of multiple cloud providers, you work with aws, azure etc explicitly. It is , however, agnostic in the sense that you can provision aws, azure, gcp, etc resources within the same iac project
- raw_anon_1111 10mo ago
  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.
- thayne 10mo ago
  AWS's native tooling is Cloudformation, and CDK is actually just a wrapper around that that generates cloudformation code (as CDKTF is a wrapper for terraform). And I like to avoid cloudformation as much as possible.
- GuinansEyebrows 10mo ago
  writing HCL is so much more enjoyable than writing CF, even if HCL is fairly verbose (hey, it's not as bad as XML!). CF feels like a series of PM requirements dutifully codified with no dogfooding whereas HCL/TF feels like a tool that was developed by people who actually wanted to use it.

tetha 10mo ago

Hm, we have a few very repetitive terraform projects to setup structured infrastructure clusters. For those, we just use ansible with a bunch of templating to generate a configurable, HCL-based terraform module and version that. It's a bit of an "Caveman solve problem with rock" approach, but for very regular projects it's great. A new cluster is some group vars, larger changes to the structures can be easily reviewed - and if you really really have to, you can also just modify the generated code by hand to fix something your generation code can't deal with right now.

rendaw 10mo ago

I made https://github.com/andrewbaxter/terrars https://github.com/andrewbaxter/terrars ! It's great! You get more benefits if you're in a Rust project (obviously) but it has some things that make it a good alternative anywhere: - More accurate types/type safety than the CDK (for static feedback on required parameters, etc) - No CLI required - just plain Rust (provider definitions can be published as normal rust packages so you don't have to generate them yourselves, and I've published a bunch of common ones - docker, aws, etc) - Simpler: Terraform CDK had this crazy flow where it (go code) generated typescript code then used some transpiler to generate target language code. The output wasn't pretty, and there were bugs. Your project directory would get filled with boilerplate generated files. It generates tf json files and has a fairly safe way for handling variable interpolation and escapes - I haven't hit any weird bugs with it.

theknarf 10mo ago

Normal Terraform, Pulumi or OpenTofu

rweichler 10mo ago
As a complete noob to the space, as an individual, who doesn't care about being "hireable" or whatever, which one has the highest ROI? OpenTofu?

exidy 10mo ago

> but locks you in Not picking on you personally but having had this conversation many times over many years with many clients I find it confounding. Oftentimes TF itself was heavily promoted as a way of "avoiding lock in". Well guess what? Now you're locked-in to IBM, whose motivations may not be perfectly aligned to you goals of simply and efficiently using your cloud provider of choice to deliver your business outcomes. What we refer to as lock-in is simply an expression of risk, with one axis being the cost of getting off $solution and the other being the likelihood of needing to do so. Having stepped through this exercise a few times, the cost of rewriting your e.g. AWS API Gateway + Lambda + SQS + RDS + CloudWatch etc architecture invariably vastly dwarfed the cost of changing the IaC language it is expressed in. Anytime you feel the urge to overbuild on a cloud provider's services, stop, and do a really rigorous cost/benefit analysis. If you truly have unique drivers the data should tell the story.