3 ms·

Any opinion on Pulumi?

by nine_k 9mo ago

gouggoug 9mo ago
Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF) Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates a resources based on the current time of day...). With infrastructure, you want predictability and reproducibility. You want to focus more on writing _what_ your infra should look like, less _how_ to get there.
- popalchemist 9mo ago
  yes. IaC is a misnomer. IaC implementations should have a spec (some kind of document) as the source of truth; not code.
- kstrauser 9mo ago
  Thanks for saving me the trouble of writing exactly that. I want my IaC to be roughly as Turing complete as JSOJ. It’s sooo tempting to say “if only I could write this part with a for loop…” and down that path lies madness. There are things I think Terraform could do to improve its declarative specs without violating the spirit. Yet, I still prefer it as-is to any imperative alternatives.
- vanviegen 9mo ago
  > Particularly, they allow you to write code whose output is unpredictable Is that an easy mistake to make and a hard one to recover from, in your experience? The way you have to bend over backwards in Terraform just to instantiate a thing multiple times based on some data really annoys me..
  - gouggoug 9mo ago
    > Is that an easy mistake to make and a hard one to recover from, in your experience? If you're alone in a codebase? Probably not. In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes. In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase. Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...
    - juffasdfwa 9mo ago
      > but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere... I don't think this is true anymore. Junior devs of today seem to be black pilled on OOP.
      - gouggoug 9mo ago
        Let my geriatric self rephrase this for you and make the point more obvious: "[...] who just discovered [insert latest design pattern trend of your choice] and insists on trying it everywhere"
  - franktankbank 9mo ago
    Agreed, I'm fine with a declarative format in one file as long as I can control the imperative bits on which it depends.
- nothrabannosir 9mo ago
  Couldn't disagree more. I have written both TF and then CDKTF extensively (!), and I am absolutely never going back to raw TF. TF vs CDKTF isn't declarative vs imperative, it's "anemic untyped slow feedback mess" vs "strong typesystem, expressive builtins and LSP". You can build things in CDKTF that are humanly intractable in raw TF and it requires far less discipline, not more, to keep it from becoming an unmaintainable mess. Having a typechecker for your providers is a "cannot unsee" experience. As is being able to use for loops and defining functions. That being said, would I have preferred a CDKTF in Haskell, or a typed Nix dialect? Hell yes. CDKTF was awful, it was just the least bad thing around. Just like TF itself, in a way. But I have little problems with HCL as a compilation target. Rich ecosystem and the abstractions seem sensible. Maybe that's Stockholm syndrome? Ironically, CDKTF has made me stop hating TF :) Now that Hashicorp put the kibosh on CDKTF though, the question is: where next...
  - Too 9mo ago
    This does not match my experience. Terraform validate will check for types and you have great IDE support with refactor, find usages, resource documentation and everything else you might expect. You can of course build a monster of untyped dictionaries but that’s true for almost any language. Do you have examples of something else that the validation step does not find?
    - nothrabannosir 9mo ago
      I never had this integrated with an editor but maybe I didn’t try hard enough. With CDKTF, a stock typescript IDE automatically has tab complete for every provider you want. That + being able to use functions, variables, loops, arrays, and structs for composition made it a completely different experience. If those things all end up coming to terraform I’m all ears. For now it seemed more like a compilation target.
- juffasdfwa 9mo ago
  The imperative trite just comes off as geriatric. There are better arguments you can use here which you have shared below. One of which I agree with.
- __turbobrew__ 9mo ago
  > for example, it'd be easy to write code that creates a resources based on the current time of day Some languages make that impossible to do, for example starlark.
x3n0ph3n3 9mo ago
My opinion is there are not enough good software developers doing DevOps, and HCL is simple enough and can have pretty good guardrails on it. My biggest concern is people shooting themselves in the foot because the static analysis tools available for HCL don't work with Pulumi.
- SlightlyLeftPad 9mo ago
  It’s an unfortunate truth that good software developers aren’t crazy enough to want to do it.
orthecreedence 9mo ago
Pulumi is superior to Terraform for my use cases. It's actually Infrastructure as Code. Terraform pretends to be, but uses a horrible config language that tries to skirt the line between programming language and config spec, and skirts it horribly. Reorganizing modules is a huge pain. I dreaded using Terraform and I spin things up and down in Pulumi all day. No contest. Granted, I'm a programmer, have been for a long time, so using programming tools is a no brainer for me. If someone wants to manage infra but doesn't have programming skills, then learning the Terraform config language is a great idea. Just kidding, it's going to be just as confusing and obnoxious as learning the basic skills you need in python/js to get up and running with Pulumi.
- kstrauser 9mo ago
  I disagree with that. I think it’s satisfying to find a way to express my intent in HCL, and I don’t think I could do it as well without a strong programming background.
AIorNot 9mo ago
We used it at my last startup and I loved it but im a dev not devops guy I loved reading code
sandorscribbles 9mo ago
manage the infrastructure with infrastructure tools - manage the application with application tools. they are not the same thing. you do not need to change the oil on your cars seats...drivetrains and interiors are different worlds joining together to achieve the goal of moving humans around.
awoimbee 9mo ago
I was the sole DevOps at my company for a long time, the team is now bigger. I used terraform for AWS and pulumi for K8S (terraform was too restrictive). IMO pulumi is a huge gain of productivity when you know what you're doing. Cons: * It's plagued by bugs and the pulumi-kubernetes provider is not getting enough attention from the pulumi team (they're always working on compatibility with yet another language instead of focusing on one thing) * You end up with your very specific/personal codebase instead of having a generic/standard thing Still, no regrets, I saved so much time thanks to pulumi! With a bigger team: * Oboarding people takes more time * You end up with code quality issues. Most "DevOps" people aren't devs, sadly.

Any opinion on Pulumi?

by nine_k 9mo ago

Any opinion on Pulumi?

Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF) Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates a resources based on the current time of day...). With infrastructure, you want predictability and reproducibility. You want to focus more on writing _what_ your infra should look like, less _how_ to get there.

popalchemist 9mo ago
yes. IaC is a misnomer. IaC implementations should have a spec (some kind of document) as the source of truth; not code.
kstrauser 9mo ago
Thanks for saving me the trouble of writing exactly that. I want my IaC to be roughly as Turing complete as JSOJ. It’s sooo tempting to say “if only I could write this part with a for loop…” and down that path lies madness. There are things I think Terraform could do to improve its declarative specs without violating the spirit. Yet, I still prefer it as-is to any imperative alternatives.
vanviegen 9mo ago
> Particularly, they allow you to write code whose output is unpredictable Is that an easy mistake to make and a hard one to recover from, in your experience? The way you have to bend over backwards in Terraform just to instantiate a thing multiple times based on some data really annoys me..
- gouggoug 9mo ago
  > Is that an easy mistake to make and a hard one to recover from, in your experience? If you're alone in a codebase? Probably not. In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes. In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase. Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...
  - juffasdfwa 9mo ago
    > but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere... I don't think this is true anymore. Junior devs of today seem to be black pilled on OOP.
    - gouggoug 9mo ago
      Let my geriatric self rephrase this for you and make the point more obvious: "[...] who just discovered [insert latest design pattern trend of your choice] and insists on trying it everywhere"
- franktankbank 9mo ago
  Agreed, I'm fine with a declarative format in one file as long as I can control the imperative bits on which it depends.
nothrabannosir 9mo ago
Couldn't disagree more. I have written both TF and then CDKTF extensively (!), and I am absolutely never going back to raw TF. TF vs CDKTF isn't declarative vs imperative, it's "anemic untyped slow feedback mess" vs "strong typesystem, expressive builtins and LSP". You can build things in CDKTF that are humanly intractable in raw TF and it requires far less discipline, not more, to keep it from becoming an unmaintainable mess. Having a typechecker for your providers is a "cannot unsee" experience. As is being able to use for loops and defining functions. That being said, would I have preferred a CDKTF in Haskell, or a typed Nix dialect? Hell yes. CDKTF was awful, it was just the least bad thing around. Just like TF itself, in a way. But I have little problems with HCL as a compilation target. Rich ecosystem and the abstractions seem sensible. Maybe that's Stockholm syndrome? Ironically, CDKTF has made me stop hating TF :) Now that Hashicorp put the kibosh on CDKTF though, the question is: where next...
- Too 9mo ago
  This does not match my experience. Terraform validate will check for types and you have great IDE support with refactor, find usages, resource documentation and everything else you might expect. You can of course build a monster of untyped dictionaries but that’s true for almost any language. Do you have examples of something else that the validation step does not find?
  - nothrabannosir 9mo ago
    I never had this integrated with an editor but maybe I didn’t try hard enough. With CDKTF, a stock typescript IDE automatically has tab complete for every provider you want. That + being able to use functions, variables, loops, arrays, and structs for composition made it a completely different experience. If those things all end up coming to terraform I’m all ears. For now it seemed more like a compilation target.
juffasdfwa 9mo ago
The imperative trite just comes off as geriatric. There are better arguments you can use here which you have shared below. One of which I agree with.
__turbobrew__ 9mo ago
> for example, it'd be easy to write code that creates a resources based on the current time of day Some languages make that impossible to do, for example starlark.

x3n0ph3n3 9mo ago

My opinion is there are not enough good software developers doing DevOps, and HCL is simple enough and can have pretty good guardrails on it. My biggest concern is people shooting themselves in the foot because the static analysis tools available for HCL don't work with Pulumi.

SlightlyLeftPad 9mo ago
It’s an unfortunate truth that good software developers aren’t crazy enough to want to do it.

orthecreedence 9mo ago

Pulumi is superior to Terraform for my use cases. It's actually Infrastructure as Code. Terraform pretends to be, but uses a horrible config language that tries to skirt the line between programming language and config spec, and skirts it horribly. Reorganizing modules is a huge pain. I dreaded using Terraform and I spin things up and down in Pulumi all day. No contest. Granted, I'm a programmer, have been for a long time, so using programming tools is a no brainer for me. If someone wants to manage infra but doesn't have programming skills, then learning the Terraform config language is a great idea. Just kidding, it's going to be just as confusing and obnoxious as learning the basic skills you need in python/js to get up and running with Pulumi.

kstrauser 9mo ago
I disagree with that. I think it’s satisfying to find a way to express my intent in HCL, and I don’t think I could do it as well without a strong programming background.

AIorNot 9mo ago

We used it at my last startup and I loved it but im a dev not devops guy I loved reading code

sandorscribbles 9mo ago

manage the infrastructure with infrastructure tools - manage the application with application tools. they are not the same thing. you do not need to change the oil on your cars seats...drivetrains and interiors are different worlds joining together to achieve the goal of moving humans around.

awoimbee 9mo ago

I was the sole DevOps at my company for a long time, the team is now bigger. I used terraform for AWS and pulumi for K8S (terraform was too restrictive). IMO pulumi is a huge gain of productivity when you know what you're doing. Cons: * It's plagued by bugs and the pulumi-kubernetes provider is not getting enough attention from the pulumi team (they're always working on compatibility with yet another language instead of focusing on one thing) * You end up with your very specific/personal codebase instead of having a generic/standard thing Still, no regrets, I saved so much time thanks to pulumi! With a bigger team: * Oboarding people takes more time * You end up with code quality issues. Most "DevOps" people aren't devs, sadly.