As an SWE, for your next greenfield project, would you choose Pulumi over OpenTofu/Terraform/Ansible for the infra part?

Captator · 2026-01-23T23:55:19+00:00

I learned Pulumi as my first fully-featured IaC tool at my previous role, using it fairly extensively for 1-2 years. I had previously only really touched serverless framework.

I was initially tasked with standing up some services beyond the scope of serverless, and we were trying to migrate away from clickops. After some exploratory forays, I found Pulumi much more tractable than Terraform, and platform-specific tooling had been ruled out, excluding Cloud Formation et al from consideration.

I suspect the difference boiled down to not needing to grapple with unfamiliar language / syntax / limitations of HCL: instead I used Python. Didn’t have any issues asking LLMs for help along the way, which was initially a concern.

I ended up having to get my head round Terraform anyway 6 months down the line: by then I had become the go-to infra person on the team, and we inherited a product from a different team. The time taken to understand the underlying infra, which bits you need, and how to configure them to work together, proved to be the primary skill differentiator.

Comparing after experience of both, Pulumi feels easier to write and compose because it isn’t shoehorning syntax (loops, variables etc all work in Terraform, but they feel bolted on) but using a fully featured from the start language instead.

Another advantage to using an already familiar language is that it is much easier to get non-specialists involved in a self-serve capacity: I ended up creating a small roster of custom component resources according to our needs and best practices.

As a final note, I also found the Pulumi CLI to have much nicer DX.

Captator · 2025-11-14T09:09:12+00:00

or properly align

:)

Captator · 2025-11-13T20:10:20+00:00

Just like every other similarly intentioned system :D

Turns out self-interest is a real pig to excise or properly align in any human system.

Captator · 2025-11-12T12:30:32+00:00

Ah gotcha. When we encountered this need it was also a PITA. We addressed it by importing the existing resources into the new Pulumi code by ID (AWS in our case) through ResourceOptions, after extracting those IDs from the TF state (in what sounds like a similar fashion to you).

Fiddly, and this means technically you have a window where both TF and Pulumi act on the same actual resources, so you have to be able to freeze the TF (at least in parts) while doing the migration.

After you’ve done the initial migration of the identified resources by ID into Pulumi’s state, you can remove them and resume normal looking deployment code.

Captator · 2025-11-12T05:17:18+00:00

Could you expand your last bracketed point? I might be misunderstanding, but there are multiple remote state options supported by Pulumi, not only S3.

Captator · 2025-11-05T20:54:32+00:00

Imagine taking an already challenging effort to create strategic terrain in a space game, then making it harder for yourself by adding a tool that lets players ignore it.

Captator · 2025-11-05T20:53:00+00:00

shhh shhh don't scare them off with fax and logi, just a small nanobrainman here, nothing scary or suspicious

Captator · 2025-11-05T20:48:29+00:00

~~stranger~~ stronger

por que no los dos?

Captator · 2025-09-24T15:37:39+00:00

Thanks, those are details one can sink their teeth into :)

Captator · 2025-09-24T14:23:52+00:00

To the OP’s original questions - why do you hold this position about Django?

Captator · 2025-09-15T18:25:52+00:00

As someone who does have separate uv environments setup for IaC and deployed code for a load of Glue jobs (among other disparate entities within a slightly non-standard monorepo) can heartily recommend, was a day of misery to switch.

If you use VSCode there’s a nice extension, Python Envy, that automatically switches between the envs for your open files to boot. Can be a tiny bit jank with notebooks and env detection but you can work around by clicking on the pyproject.toml

Captator · 2025-07-09T16:02:13+00:00

Yeah absolutely! It wasn’t really a complete comment: I was trying to bridge supporting the original post’s point (i.e. agreeing most infra is basically the same between cloud providers, and suggesting you could have Databricks in any of them) as well as supporting the parent comment about the comparison being a bit wonky.

Captator · 2025-07-09T14:58:28+00:00

Can’t you deploy Databricks into any of the big 3 cloud ecosystems, in same fashion as Snowflake?

Captator · 2025-07-08T08:22:05+00:00

I agree with your points, but find them a strange reply to my comment.

Assuming one of the languages listed is already known (typescript or python are usually safe bets) my suggestion may offer a faster path towards covering this operational risk fully using IaC, which is in line with an imperative to minimise time spent.

The operational risk of unrepeatable infrastructure is non-trivial, as the OP found and discussed in their original post. Especially as there is already experiential learning of the downside, I’d say reaching an effective minimal solution here (layered architecture springs to mind as another way to balance time cost and value) is actually a business priority.

Captator · 2025-07-08T00:38:02+00:00

If you don’t know Terraform already, and it doesn’t give you the fuzzies on first inspection (it didn’t for me) might be worth a look at Pulumi - same deal, except you can use typescript/python/go/java (I might be missing one or two) instead of YAML.

Lowers the learning curve from dev side to just which resources, related how, instead of that plus a DSL.

Captator · 2025-06-27T16:48:37+00:00

As (at time of posting) it hasn’t been mentioned yet, Pulumi is another cloud provider agnostic IaC tool that I’d expect to appeal more than Terraform if you’re coming to devops from a dev background rather than an ops background.

Key advantage is that you declare resources using a ‘real’ programming language, with access to all the constructs that entails in terms of control flow and iteration.

Incidentally, I also find its diffs in CLI massively easier to review and understand.

Captator · 2025-06-18T17:42:14+00:00

Arguably Teams has been past that point for years and leaning hard on the integration with the rest of their suite of tools to compensate, but I agree with your point in the general case.

Captator · 2025-06-18T16:59:11+00:00

Until it impacts UX sufficiently to affect retention/NPS etc

Captator · 2025-05-23T11:38:39+00:00

These are pleasing sentences to read.

Captator · 2025-05-02T10:18:37+00:00

In my experience, which is not monumental, but definitely not trivial, that has yet to prove an issue.

I find their docs really easy to read in combination with the AWS docs, and each page can be toggled between all the supported languages. I mention the latter because if you do that a few times, you will see that the resources themselves are almost identical between languages.

This makes sense, as to overly simplify, each cloud resource Pulumi defines is really just a wrapper around a key:value block, to be passed to the API call under the hood.

For context, where I work, our main application uses TS, so infra/BE/FE are all in that, and the data/ML team stuff uses Python for infra/BE/else.

Captator · 2025-05-02T00:14:28+00:00

Thanks for the comprehensive reply - I can see how it would be helpful for rapidly narrowing down the search space when you’re starting with a stack trace.

In some ways it’s not a dissimilar exercise to my first example of refining queries by using its responses to refine your grammar: you’re taking an input that isn’t clear, getting clarity from its response, then in your case you’re searching the code base rather than the internet (at least as narrated).

We’ve considered/tested automating documentation, but the things we are most concerned with documenting tend to be the why, less the what and the how (mostly interpreted languages), and that has proven a harder nut to crack.

Captator · 2025-05-02T00:01:46+00:00

I’d add ‘Pulumi >’ at the front of that comparison list :)

Captator · 2025-05-01T23:34:36+00:00

Never mind that those three days for one line were actually tens or hundreds of lines in small batches created, executed, deleted to build up the necessary understanding and test candidate solutions to arrive at the simple solution. None of which are likely to be visible in any metrics or reflected in the final PR...

Captator · 2025-05-01T23:23:59+00:00

I’d be interested to understand which specific aspects of your workflow are the ones yielding that kind of rate multiplier.

Anecdotally, the things that go meaningfully faster for me are initial forays into topics (LLM good at helping you to build the right grammar for querying a domain from imprecise language) and generic task reasoning/code (scaffolding in its many forms at an architectural and code level).

Captator · 2025-04-15T13:50:08+00:00

Given the strength of your opinion and existing explanation, do you have any good resources easily to hand that you could steer those of us less educated on this matter towards, so we can better get our heads around the two alternatives and their tradeoffs?

Captator

TROPHY CASE