Terraform is dead; Long live Pulumi? | Hacker News Reader

Terraform is dead; Long live Pulumi?

matduggan.com

40 pointstodsacerdoti29 comments

Want an advice from a pro? Stick with Cloudformation (CFN). Split stuff smartly between stacks. Use Outputs export/import. This is default IaaC way in AWS. I would not touch anything else, rather insist on full rewrite. Reuse templates using Parameters. Stack can be rolled-back, checked for drift, checked for changes before changes and so on.

CFN has the least LOC between them all and is easy to create in your text editor.

Just don’t use nested stacks :) oh, and multi-cloud is an urban legend, myth.

Well, this works only for AWS. For Azure, there's Bicep (which is just francy wrapper), but I need more than just AWS - I terraform GitHub, Cloudflare, DataDog, Opsgenie, etc. Terraform is not dead, Pulumi is way too commercial; I believe Terraform fork is imminent - the core team of HashiCorp was stuck for years and this needs to get out of their grip, which was focused only on monetizing the overly expensive TFC!

For example, dynamic providers has been the hugest pain! They don't care to fix it, because their foundation is so flaky, it requires tons of work. In the hands of the community, which doesn't care about making TFC catch up with Scalr, Env0, and the numerous other cheaper and mostly better alternatives, this will be accomplished way more easily.

I think terraform had been forked

Multi-cloud is definitely not an urban myth; I've worked with several customers who are actually doing it moderately successfully.

IaaC code would be totally different, not the same, as Terraform sells it.

Nah, cdk is way better imo.

CDK defaults are too default, and you still have CFN in the end, which you have to view and approve anyway.

Yeah after working with cloudformation for so long I really despise working with anything else. Terraform isn’t bad but it’s still much more verbose than cloudformation

We're not using terraform for multicloud but to have the same tech stack. Also the terraform documentation for the aws provider is just magnitudes easier to understand than the cloud formation docu. And in some cases more correct.

Our deployments are triggered with bash scripts and this way we can use the best parts of each cloud provider, all with terraform.

Still debating internally what this new license means for us.

A lot of this seems to come down to pricing. Don’t get me wrong, I agree the pricing is predatory. But if it’s that big a deal and you use AWS, just use the CDK. At least you’ll get state management with AWS.

And it literally costs you zero, no matter how many resources you have.

(Of course you can’t use this with other clouds, but TF was never really multi-cloud to begin with)

If it's only the pricing of the SASS backend which is holding you back because you wouldn't get enough benefit from seeing and searching all your stacks in one place, then just use the free backends. E.g. point it at an s3 bucket and it'll probably not even register on your cloud bill.

I personally used the free AWS S3 and Azure Storage backends for years in a large enterprise with great success (mainly due to avoiding internal procurement issues).

It's dirt cheap to back Terraform CLI state with S3 and DynamoDB.

You certainly can do that with TF open source. But YOU are still managing that state.

TFC and CFN do that for you.

I haven't played with Pulumi in a long while, because we decided that for hiring reasons we'd hold our nose and use the aggressively stupid terraform because at least it's known stupid

But I just fired up a recent version of Pulumi and can say that there is "no long live Pulumi" in its current state because they aped terraform so much it falls prey to the exact same stupidity as terraform, only now featuring their own bugs <https://github.com/pulumi/pulumi-aws-native/issues/108>

  $ pulumi new aws-native-go
  $ grep NewBucket main.go
          bucket, err := s3.NewBucket(ctx, "existing-bucket-name", nil)
  $ aws s3api list-buckets --query 'Buckets[*].Name' | grep existing-bucket-name
    "existing-bucket-name",
  $ pulumi preview 
  @ previewing update....
   +  aws-native:s3:Bucket existing-bucket-name create

so: (1) I see, you required that I give you live AWS credentials, but you didn't use them for shit (2) this is not legacy terraform behavior this is using their own provider so they are not beholden to the incredibly misguided decisions Hashicorp made

You can retort "but muh state file!!1" all you want, if I $(pulumi import 'aws-native:s3:Bucket' existing-bucket-name existing-bucket-name) and then run $(pulumi preview) it for damn sure uses any credentials to interrogate the resource so let's just skip the pretense that one needs a state file to straight-face check proposed changes. Asking the user to learn the crazy import syntax for every resource across every provider just to do the work of a computer running a HEAD request against an API is stupid

Or, if one wants to take the terraform approach of hurp durp I dunno if any resources exist, then don't require live credentials during the plan phase so that everyone is on exactly the same page about what will and won't happen for each phase

I'd say the argument is flawed. If you move to Pulumi, eventually you will have all the same problems you have with Terraform, except now it's written in a complex language instead of HCL, which is easy to read, well documented and well suited to the infrastructure problem set. HCL and Terraform are also well supported in VSCode these days.

I would also say that the "set and forget" nature of terraform and versioning is fine, since it tends to just work at old versions and is usually forward compatible (since about the .14->1.0 split).

Now I am a hopeless TF stan but I am a bit concerned about the license change as well. Not so much for the FOSS crusader angle, but that the backlash may destroy a great tool ecosystem for devops/platform/SRE teams.

this is absolutely not the experience we have when customers migrate to Pulumi, and I spend all day helping users undergo that transition.

I keep hearing that. Meanwhile our pulumi project has been ongoing for a year whereas new engineers can bootstrap with terraform in a day and submit useful changes immediately. I guess I’d say I’m cautiously optimistic but not holding my breath.

I wonder what on earth they are doing.

Regardless of how you fall in the Pulumi Vs Terraform preference scale, Pulumi is pretty damn simple and shouldn't take any time to get your infrastructure working in it.

I wouldn't agree with that. I was heavily working on a fairly straightforward infrastructure a year ago and encountered many issues in Pulumi either not supporting a feature or having to work around a bug in Pulumi. It worked, and it was nice when it did and a great DX, but when it fell apart it was quite a burden to figure out what to fix/workaround. Our infrastructure was lambda+CloudFront+S3 and a route based LB with RDS. Nothing crazy.

Yes, I'm sure the Pulumi team has updated to include those features (I can't remember what but if needed I can go find the infra code since the startup went kaput) and fix some of those bugs but they're a small dog chasing a racecar and may never catch up.

I think one of the virtues of Terraform is precisely being more limited than a full programming language. The temptation to add abstraction overhead can be too much for some teams.

That would imply that their entire codebase is a mess rather than an issue with Pulumi.

Not necessarily. I know great programmers who don't really understand infrastructure. If you assign people who know the project and the language well but haven't been bitten by sysadmin/ops concerns they could make a mess of things thinking their common sense applies everywhere where they can write code.

take with a grain of salt, I only have minimal experience with both, but I really like the fact that pulumi is code over terraform config. Keeps me in the same toolchain, no need for extra plugins, etc.

> Terraform often starts with dev stage and prod as different workspaces.

> At this point the environments are completely isolated state files with no mixing,

But then

> Now you and your team realize that Terraform can destroy the entire company if you make a mistake,

Contradictory and cherry-picking.

I don't get the uproar with the licence change, seems to change nothing unless you host on a Terraform Cloud competitor that uses Terraform (how many are there?)

Literally just switched all my homelab deployment stuff from ansible to terraform. Sigh.

For homelab stuff Terraform/Terrafork will probably be OK for some time. The current TF version will get security updates until the end of the year and I expect others will keep it going after that.

In the medium term I'd expect incompatibilities and fragmentation in the ecosystem to crop up.

Sometimes I think Ansible could go down the same path if IBM/Red Hat decided to monetise it. All of these ecosystems run by a single company are fragile. Counter-examples are Linux and Kubernetes which both have many contributing companies with competing interests.

Why? this is a serious question, i work at a place where we use both and i would love to standardize on ansible rather then terraform even though i hate yaml and significant whitespaces.

Terraform especially kind of feels like something that's demand far to much hand wrangling every time i set up a new instance(as few of our instances is 100% identical in config), for what it's promising.

For the task at hand - deploying VMs/LCXs in different configurations terraform is inherently better suited.

The ansible way worked too, but required doing custom logic against the proxmox api.

This was an interesting article.

As someone who's used Terraform for, gosh, at least seven years now (!!!) and has also dabbled with Pulumi, I agree with the complaints (especially regarding Hashi's licensing decision and their cloud offering) but disagree that open-source Terraform doesn't scale and that Pulumi is a better alternative.

A bulk of the authors argument lies in the following:

- Built-in testing deficiencies (I.e. Terragrunt providing some semblance of component testing that Terraform doesn't offer, and terraform plan/validate not guaranteeing passing tests post apply) - Poor modularity leading to high DRY, and - HCL not being a Real Programming Language™

These aren't new grievances. I think I've seen the "HCL is BS" take pretty much since I've started using Terraform, for example.

Ultimately, the issue is that Terraform is only meant to be good at creating resources in an unpredictable environment (a cloud provider) that you can't control. At all.

You can tell Terraform to apply against localstack (a mock instance of AWS you can run on your Mac), but AWS changes their APIs _constantly_ and error boundaries are essentially infinitely large. If you're serious about testing your infrastructure code, even considering the most common set of error states will lead to a significant number of (very slow!) tests.

You can easily apply the wrong state to an incorrect environment and "destroy your company" (great argument for a strong automated backup/restore workflow and ephemeral infrastructure, btw), but is it Terraform's job to prevent foot-gunning yourself in this way? I'd say no.

Regardless, I've seen some very large companies with definitely webscale levels of infrastructure enjoy lots of success managing all of that with Terraform open-source just fine. To that end, I'd say Terraform scales just fine.

In fact, I'd say Pulumi scales less well than Terraform does, in the average case.

I can teach a sysadmin with 20yrs of experience that was told to "do the DevOps now" HCL very quickly. If I, instead, said "okay, so we're going to manage our infrastructure with Pulumi and Python, and to do that, we'll need venv, pytest, pip, etc," they'll just straight up retire.

And that's before you get the 20-line long stack trace (with a bunch of frames that are within Pulumi's context) that basically vomits whatever bullshit Azure came up with this time at me.

Or trying to use Pulumi with something other than Python, Node or Golang. (Most enterprise devs write Java and C# and many of them have extensive build/release tooling custom-fit for these languages.)

Reply on news.ycombinator.com