3 ms·

Yes, your post is more an indictment of Terraform itself, rather than the grandparent's usage of it. I've had pretty good luck with Crossplane, it has its wart

Yes, your post is more an indictment of Terraform itself, rather than the grandparent's usage of it. I've had pretty good luck with Crossplane, it has its warts, but it removes the lack of obviousness that accompanies Terraform. Unfortunately, reconciling state against infrastructure configuration seems to be a pretty tough problem to get right so no solution is amazing. But being as declarative as possible upfront and not obfuscating it behind a build time execution phase seems to help AI reason about it.

cassianoleal 1mo ago
I've looked into Crossplane, and I like a lot of things about it. Unfortunately when we spiked it, the providers we required were a major let down. In terms of these horrendous HCL constructs, I'm not going to pretend I haven't written them myself ever, but every single time it's self-inflicted and can be solved by redesigning the data types. As with any other tool and language, if you design your codebase for its weaknesses, you'll have a much better time.
- SOLAR_FIELDS 1mo ago
  Nowadays all providers are, or can be somewhat easily, just use Upjet to convert a Terraform provider. They walked away from the custom provider maintenance model awhile back due to its lack of scaling potential and loss of network effects from Terraform being the de-jure framework for infrastructure API's I will say that yes, quite a few of the providers are half assed and have bugs. Mostly around how reconciliation works, but also gaps in the provider in how it writes fields due to some Terraform idiosyncracy. I often end up having to ignore various fields in the yaml to prevent drift. But now you can wrap your own without too much effort. HCL itself definitely footguns you into it, it's perverse, because it's intended to be a mere configuration DSL and yet it has since its inception been square pegged into a round hole to do imperative language construct things that it was never designed for. Which is why you get insane practices like "never use an array to iterate over infrastructure in a loop, because removing an element forces a recreation of every resource after that loop because the position of the element in the array shifted to the left". These sort things are completely logical things you would do in a not insane framework (who doesn't use an array to loop over things in a normal software language?), but are a well-known landmine with HCL and Terraform. You could say it was a mistake to use a language like HCL for Terraform and I would agree. It's a half baked idea that became production way too fast. Reminds me of Javascript.
  - cassianoleal 1mo ago
    Good to know about Crossplane, thanks! I agree with your points around HCL. This is one of the reasons I liked Chef's DSL - it was Ruby. It was foolish to do too much Ruby stuff around the DSL, but if you kept it to the right amount it would help immensely, so the DSL never needed to be bent out of shape for each edge case and extra functionality. Leave iterations and conditionals to the languages that are good for it.

cassianoleal 1mo ago

I've looked into Crossplane, and I like a lot of things about it. Unfortunately when we spiked it, the providers we required were a major let down. In terms of these horrendous HCL constructs, I'm not going to pretend I haven't written them myself ever, but every single time it's self-inflicted and can be solved by redesigning the data types. As with any other tool and language, if you design your codebase for its weaknesses, you'll have a much better time.

SOLAR_FIELDS 1mo ago
Nowadays all providers are, or can be somewhat easily, just use Upjet to convert a Terraform provider. They walked away from the custom provider maintenance model awhile back due to its lack of scaling potential and loss of network effects from Terraform being the de-jure framework for infrastructure API's I will say that yes, quite a few of the providers are half assed and have bugs. Mostly around how reconciliation works, but also gaps in the provider in how it writes fields due to some Terraform idiosyncracy. I often end up having to ignore various fields in the yaml to prevent drift. But now you can wrap your own without too much effort. HCL itself definitely footguns you into it, it's perverse, because it's intended to be a mere configuration DSL and yet it has since its inception been square pegged into a round hole to do imperative language construct things that it was never designed for. Which is why you get insane practices like "never use an array to iterate over infrastructure in a loop, because removing an element forces a recreation of every resource after that loop because the position of the element in the array shifted to the left". These sort things are completely logical things you would do in a not insane framework (who doesn't use an array to loop over things in a normal software language?), but are a well-known landmine with HCL and Terraform. You could say it was a mistake to use a language like HCL for Terraform and I would agree. It's a half baked idea that became production way too fast. Reminds me of Javascript.
- cassianoleal 1mo ago
  Good to know about Crossplane, thanks! I agree with your points around HCL. This is one of the reasons I liked Chef's DSL - it was Ruby. It was foolish to do too much Ruby stuff around the DSL, but if you kept it to the right amount it would help immensely, so the DSL never needed to be bent out of shape for each edge case and extra functionality. Leave iterations and conditionals to the languages that are good for it.