Hacker News new | ask | show | jobs
by zoltrain 2256 days ago
So I've been trying out Pulumi at the new company I've just started working at and I can say the experience so far has been pretty awesome. This coming from a pre-version 1 user of terraform (when pretty much the only support was the AWS provider). For me HCL was never the killer feature of Terraform, I personally think it was the resource abstraction and providers that made it the best choice at the time. Chef/Ansible runs were always dangerous because as most of us will know from hard learnt lessons, "what you see isn't necessarily what you get". Having a DAG, tracking dependencies between resources, and getting a "this is what you have, this is what you'll get" when you apply a change is the core of what makes terraform great... but this isn't the language, I'd actually argue HCL is where most of it's problems were. The hacks one had to make before HCL 2.0 to get any type of reuse were to be frank, awful. They were also non-obvious, so you had to either pass the knowledge on in your team like a "sage" which isn't scalable for smaller/midsize teams, or let people hit those walls and waste more collective time. Writing languages is hard, and it took Hashicorp years to get it "mostly" right. Though the ergonomics of HCL I would still say aren't very nice or very developer friendly.

Now to Pulumi's merits, if you dive into it's architecture you'll find it's actually users from terraform providers under the hood (very well tested code bases). So it will do things like build a DAG, track dependencies, and give you a diff before you apply anything. From what I can tell it's just changed how you interact with the terraform internals (I'm sure it's more complicated than this, but this is my simple understanding of it). Sure you can get code ordering problems, like any imperative language but it doesn't make it any more unsafe to run as you're protected by the same plan/apply type setup as Terraform. You can also rely on the same language specific quality controls you already rely on. Things like unit tests, integration tests, code coverage, IDE integration etc. Personally I think a better use of time is teaching team members about the infrastructure fundamentals who have an interest in learning them, over getting them to also split focus on a language they will only use in one situation.