4 ms·

> Four years ago I hand-wrote a nested for loop - four levels deep, tagging subnets across regions and availability zones in another AWS account - and it took m

> Four years ago I hand-wrote a nested for loop - four levels deep, tagging subnets across regions and availability zones in another AWS account - and it took me about an hour to get the syntax right I do believe this kind of engineer requires AI. I also hope I don't have to work in the same teams as them. Seasoning teaches you to make changes in other parts of the codebase rather than do this kind of data mangling on local variables, which is incredibly hard to troubleshoot and very brittle - not to mention it's a nightmare to read back and understand.

bigstrat2003 2mo ago
Another shameful quote from the article: > Kubernetes made server management easy enough that we stopped building our own node images at all - we just use whatever the cloud provider hands us, an AWS AMI built for us, no questions asked. This dude is just bad at his job.
- stackskipton 2mo ago
  SRE here, why would you create your own node images for Kubernetes Nodes? Unless they deliver some weird kernel that would cause containers not to run, there is no reason not to take cloud provider image. If you need something extra on the nodes, 99% of the time, DaemonSets will do the job.
  - tomrod 2mo ago
    In many spaces, higher security requirements.
arjie 2mo ago
It is Terraform’s configuration language. Locals mean something specific : non-exported variables. Constructing the map or whatever prior to plan phase is pretty idiomatic. Note the key in the map is a string concatenation. Not something you would do elsewhere but a constraint of that framework.
- cassianoleal 2mo ago
  I've been using Terraform since it came out. I know what it is.
  - SOLAR_FIELDS 2mo ago
    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 2mo 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 2mo 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.
chanux 2mo ago
I would not be quick to judge the person without knowing - the kind of work environment they were in - the quality of the existing code base

bigstrat2003 2mo ago

Another shameful quote from the article: > Kubernetes made server management easy enough that we stopped building our own node images at all - we just use whatever the cloud provider hands us, an AWS AMI built for us, no questions asked. This dude is just bad at his job.

stackskipton 2mo ago
SRE here, why would you create your own node images for Kubernetes Nodes? Unless they deliver some weird kernel that would cause containers not to run, there is no reason not to take cloud provider image. If you need something extra on the nodes, 99% of the time, DaemonSets will do the job.
- tomrod 2mo ago
  In many spaces, higher security requirements.

arjie 2mo ago

It is Terraform’s configuration language. Locals mean something specific : non-exported variables. Constructing the map or whatever prior to plan phase is pretty idiomatic. Note the key in the map is a string concatenation. Not something you would do elsewhere but a constraint of that framework.

cassianoleal 2mo ago
I've been using Terraform since it came out. I know what it is.
- SOLAR_FIELDS 2mo ago
  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 2mo 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 2mo 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.

chanux 2mo ago

I would not be quick to judge the person without knowing - the kind of work environment they were in - the quality of the existing code base