3 ms·

That hasn’t been my experience; quite the reverse. Programmatic IaC made it a lot easier to: - turn our inventory DB into a IaC deployment for a hybrid cloud

That hasn’t been my experience; quite the reverse. Programmatic IaC made it a lot easier to: - turn our inventory DB into a IaC deployment for a hybrid cloud that needed IOT shadows per datacenter device - shard our data processing pipelines to localized data centers so we can respect data protection laws - automatically compiling infrastructure definitions directly from programs, to run as “cloud binaries” What do you imagine the challenges at scale are?

verdverm 4y ago
The main issues with multilingual, imperative infra is sharing between teams who use different languages and building tooling for the stack. Another issue is understanding how the config / infra is assembled in high pressure situations like outages. All of those things you mention have been done for a long time before pulumi or re-imperative infra. OG DevOps was largely imperative until TF came out. There was a reason for the switch. Not that I don't have complaints about TF, but I would never go back to the imperative days I'm personally moving to CUE and outputting tf.json files until I have time to investigate crossplane. Want to see if their state management, permissions, and reconciliation is better by building on the k8s API S
- zmgsabst 4y ago
  > Another issue is understanding how the config / infra is assembled in high pressure situations like outages. My experience is that this is strictly easier in a full programming language than TF, due to debugging tools. > OG DevOps was largely imperative until TF came out. There was a reason for the switch. There’s also a reason for the switch back: I’ve had to maintain those declarative templates at scale and they’re ghastly. I would much, much rather deal with an actual programming language any time. I would never go back to the TF days.
  - verdverm 4y ago
    > My experience is that this is strictly easier in a full programming language than TF, due to debugging tools. Is that with code you have written? At scale, you are SRE'n something someone else wrote, because no one can be on call 24/7 I've never had to really debug TF in an outage, the tools have been logmon & requires visibility across the stack, from infra to applications > There’s also a reason for the switch back I suspect this is more about everything old being new again, TF having a few rough edges, and DevOps people wanting to feel like they are programming. Their are better places to spend programming effort in the DevOps / sre job
    - zmgsabst 4y ago
      > At scale, you are SRE'n something someone else wrote, because no one can be on call 24/7 My teams had dedicated on-calls; we were platform teams for other teams. So — perhaps it makes a difference if you’re talking about that situation? > DevOps people wanting to feel like they are programming. Their are better places to spend programming effort in the DevOps / sre job Yawn. You’re implying bad morals because someone has a different view than you — and such ad hominems are inappropriate. You also clearly are ignoring the experience of the many, many people migrating this way — purely out of hand. Maybe that’s why you don’t understand: you’re too stuck up.
      - verdverm 4y ago
        you sink to exaggerated and derogatory statements when someone makes points you disagree with what does that say about you?
        zmgsabst 4y ago
        Uh — did you get our posts confused? > DevOps people wanting to feel like they are programming […] > you sink to exaggerated and derogatory statements when someone makes points you disagree with > what does that say about you?
        verdverm 4y ago
        I am one of these people. DevOps practitioners openly talk about feeling like yaml engineers and wanting to do more traditional programming. It is no secret nor derogatory, rather a reflection and expressed desire of many practitioners. However there are better places where we can write code than in undoing the progress of declarative infrastructure. You again show your assumptions and misplaced ridicule

verdverm 4y ago

The main issues with multilingual, imperative infra is sharing between teams who use different languages and building tooling for the stack. Another issue is understanding how the config / infra is assembled in high pressure situations like outages. All of those things you mention have been done for a long time before pulumi or re-imperative infra. OG DevOps was largely imperative until TF came out. There was a reason for the switch. Not that I don't have complaints about TF, but I would never go back to the imperative days I'm personally moving to CUE and outputting tf.json files until I have time to investigate crossplane. Want to see if their state management, permissions, and reconciliation is better by building on the k8s API S

zmgsabst 4y ago
> Another issue is understanding how the config / infra is assembled in high pressure situations like outages. My experience is that this is strictly easier in a full programming language than TF, due to debugging tools. > OG DevOps was largely imperative until TF came out. There was a reason for the switch. There’s also a reason for the switch back: I’ve had to maintain those declarative templates at scale and they’re ghastly. I would much, much rather deal with an actual programming language any time. I would never go back to the TF days.
- verdverm 4y ago
  > My experience is that this is strictly easier in a full programming language than TF, due to debugging tools. Is that with code you have written? At scale, you are SRE'n something someone else wrote, because no one can be on call 24/7 I've never had to really debug TF in an outage, the tools have been logmon & requires visibility across the stack, from infra to applications > There’s also a reason for the switch back I suspect this is more about everything old being new again, TF having a few rough edges, and DevOps people wanting to feel like they are programming. Their are better places to spend programming effort in the DevOps / sre job
  - zmgsabst 4y ago
    > At scale, you are SRE'n something someone else wrote, because no one can be on call 24/7 My teams had dedicated on-calls; we were platform teams for other teams. So — perhaps it makes a difference if you’re talking about that situation? > DevOps people wanting to feel like they are programming. Their are better places to spend programming effort in the DevOps / sre job Yawn. You’re implying bad morals because someone has a different view than you — and such ad hominems are inappropriate. You also clearly are ignoring the experience of the many, many people migrating this way — purely out of hand. Maybe that’s why you don’t understand: you’re too stuck up.
    - verdverm 4y ago
      you sink to exaggerated and derogatory statements when someone makes points you disagree with what does that say about you?
      - zmgsabst 4y ago
        Uh — did you get our posts confused? > DevOps people wanting to feel like they are programming […] > you sink to exaggerated and derogatory statements when someone makes points you disagree with > what does that say about you?
        verdverm 4y ago
        I am one of these people. DevOps practitioners openly talk about feeling like yaml engineers and wanting to do more traditional programming. It is no secret nor derogatory, rather a reflection and expressed desire of many practitioners. However there are better places where we can write code than in undoing the progress of declarative infrastructure. You again show your assumptions and misplaced ridicule