Hacker News Reader

Comment by SirensOfTitan | Hacker News Reader

I don’t really think IaC is there yet, as someone who has used terraform (and now pulumi) in production for some time.

My biggest gripe is that the feedback loop is fairly slow: planning often predicts valid config that fails in deployment. It doesn’t help that the process of planning is really slow (see https://github.com/pulumi/pulumi/issues/8872 it can take minutes for pulumi to plan changes if using azblob backend) with little incentive for teams like pulumi to investigate or fix unless you use their cloud. I get that pulumi is in the business of promoting their own cloud, but there are few (if any im aware of) IaC solutions not intrinsically tied to for-profit SaaS because it’s incredibly labor intensive to build consistent interfaces to several constantly changing cloud providers.

View on HN

out of curiosity, how did you like pulumi compared to terraform? I'm starting to hear about it more often

As someone starting with terraform literally this weekend, why did you move away?

Asking my engineers to learn a completely new DSL (HCL) with its own quirks to change infrastructure felt like it ran against the spirit of IaC. If they were tweaking infrastructure every day, that’d be one thing, but it’s fairly hard to commit a language to your long term memory when you’re interacting with it only on occasion.

You can do Terraform in Java. Or Python. Or... https://www.terraform.io/cdktf

CDK is reasonably new thing for terraform.

A lot of us have cut our teeth on previous major version of terraform DSL, when it was even less capable than it is now (no maps, no for each, etc.) and it wasn't that uncommon to be told to generate terraform JSON directly to work around DSL shortcomings, generating essentially all of the provider objects yourself.

If you have common changes like adding a new queue or storage bucket, you can pull the details out into yaml or json and have Terraform loop over them. As a (potentially) added bonus, you can have different Terraform projects point to the same yaml--used to do this for maintaining subnets

Terraform as a language is a bit clunky and feels not quite complete. For example, to accomplish if/else logic, you have to hack something like: `count = var.is_foo ? 1 : 0`

More than the language syntax, getting any response from the hashicorp team on their official providers is like rolling the dice. If your bug or feature pr is a bit on the fringes and not in their sights, it can sit for months/years without traction or even a non-automated response. With just the aws provider, there are over 3000 issues and nearly 400 open PRs. That team is understaffed or mismanaged. It has gotten marginally better over the last year or so, but generally speaking, Hashicorp doesn’t seem to care while they’re pouring all efforts into their own cloud. 1. https://github.com/hashicorp/terraform-provider-aws/issues/1... 2. https://github.com/hashicorp/terraform-provider-aws/issues/6... 3. https://github.com/hashicorp/terraform-provider-aws/issues?q...

Terraform is amazing and is also very thin. It’s amazing to be able to commit your infrastructure to source control, but it’s nothing without effective well-maintained APIs that can be driven by Terraform providers.

I’ve built custom Terraform providers to map to custom APIs, and the experience was just fantastic. I’ve also used scripts with AWS resources that were a chore to use because the underlying API was a trash fire.

Specifically with respect to Terraform the language, the uniform adoption of functional programming concepts would be nice— right now providers expose varying ways of dealing with sets of resources in more or less confusing and incompatible ways (count, and the various times that you cannot use count).

So the problems with TF are twofold: the language is not quite consistent, and the ecosystem depends entirely on the quality of contributed providers and/or the module shims built on top of poor providers.

It can be easy to get frustrated during IaC development, but an absolute relief when you can rock deployments confidently.

I think that terraform etc. are largely the wrong way of doing it. I think NixOS (or just the Nix package manager) is the right way of doing it but the Nix ecosystem has it's own separate set of issues. Mostly these are around (lack of) documentation making it impenetrable to get on board with.

On the other hand, my feeling is that as your problems become harder and harder (your infrastructure gets more complex) Nix is exactly the same amount of hard as it was, but the other tools begin to struggle more and more. Sometimes that's from a performance point of view (the plan speed issue you're talking about), sometimes it's because edge cases of unexpected results begin to creep in.

I use nix on my personal machines, and I think I agree, but the nix tooling has a lot to be desired. A well-implemented language server would be enough to drive things forward: I’m constantly unsure as to what types various variables are, or what kind of flags or options I can set in derivations.

Nix is wonderful, and very difficult.

But, if you're talking about IaC, you need to more precisely talk about NixOps and how that compares to tools like Terraform or Pulumi. -- Overall, Nix isn't really aimed at solving IaC for cloud resources.

Reply on news.ycombinator.com