I'm curious how many people migrated from Terraform, and are starting to consider going back to Terraform? I'm really starting to miss the constraints of the Terraform DSL, and can't decide if we're implementing Pulumi in an unmanagable/unsustainable way, or if we're trying to use it for solving the wrong problems.

FWIW, I use both in my day-to-day work and find that Pulumi makes it a lot easier to create components/modules, work with inputs from files, and create resources through iteration (e.g., "Create an IAM binding for each of the following accounts."). Curious to hear about the issues you see 🙂

The lack of opinions, and that Pulumi as a product feels like a marketing tool to drive people towards solutions which are prohibitively expensive for small companies like ours. Part of it is that we're probably using it wrong. I was torn as to how much should be automated via Pulumi vs how much should be shell scripts in CI/CD. All of a sudden I'm managing about 10k lines of code for a service factory to manage ~100 different ECS tasks, and now I'm thinking it's time to give up on IAC for everything that isn't strictly cloud infrastructure, and go with SAM tools inside of our CICD, or migrate into K8s.

Hmm. Lots to unpack there 😉 These days, I try to keep my CI workflows as slim as possible. Ideally, they are just calling a sequence of commands that I could also run elsewhere. At the same time, I try to stick to as few tools as possible for each infrastructure layer. Using Pulumi or Terraform for just the base infrastructure and deploying on top with Helm or SAM or some vendor CLI can work well in my experience, but only if you're super strict about keeping layers separate.

Well I've learned to hate Typescript significantly. Python/ would have been a much betterchoice, but we went TS due to a (now abandoned initiative) to rewrite all of our Java apps in TS. If we stick with Pulumi I'll move all of our components / factories back to a monorepo, and I'm considering dumping the factories together and just using Crosswalk with the acceptance that eventually every stack will be divergent. The cognitive load will still reduce significantly. Terraform's ecosystem of modules is definitely much more mature. It also has much more reliable support for BitBucket's SDK, whereas I've had to fork and maintain my own version of pulumi-bitbucket as it is abandonware. Pulumi really needs to write and maintain their own bitbucket provider.

What are the pain points you see with TypeScript? I've used Pulumi with both Python and TypeScript and I don't see a big difference in the work that I do. You can use every Terraform provider with Pulumi (

pulumi package add terraform-provider

) and I believe it's also possible to use TF modules, but I don't have first-hand experience with that yet.

Maybe I'm doing something wrong via bitbucket. I'm using the basically abandoned DrFaust provider with my fork of the abandoned wrapper via:

pulumi package gen-sdk terraform-provider drfaust92/bitbucket 2.47.0 --language nodejs

It was so unreliable I went back to manually all of our bitbucket repos. Saved me a few hours per month.

I think you will have an easier time with "pulumi package add terraform-provider $YOUR_TF_PROVIDER". But of course, this can be at most as good as the source TF provider.

Maybe. At this time it's the second lowest item on my 300+ ticket backlog. My employer .. sucks, but with this job market, beggars can't be choosers.

As @modern-zebra-45309 wrote, you should give the ATP (Any Terraform provider) a try, so you could use the more TF provider for bitbucket. The ATP is a game changer for me as I can leverage the TF provider ecosystem more. If you find the time, give it a go and let us know how it went.

Migrated many years ago. Never once considered trying anything else -- nothing else has the same support for creating unit-testable reusable infra-code. Only recently found out about Terraform Test (not Terratest, which has been around a lot longer), so I really ought to try that.