4

I'm with a dilema here about which SE site to ask this question so please help me out if it should be somewhere else.

I've been looking into Infrastructure as Code solutions.

Didn't like Terraform too much. The lack of intellisense makes discoberability harder than programmers have been used to.

I've been considering ARM templates. I like it that the templates are made available as we create resources in the portal but it seems way less readable and harder to maintain afterwards.

Then I found out Pulumi and love their idea compared to Terraform. The way I see it, they're approach is also declarative like the above options but we can use decent programming languages to get the job done.

The for loops is a must.

Cool, I like that! But since we like using C# (or other alternatives), then why don't we SDKs to manage our infrastructure as code?

Pulumi has compared themselves with cloud SKDs by positioning their solution as much safer advocating that, if we just use a cloud SDK ourselves, then our solution wouldn't be that reliable.

To what extent is this really true, I wonder?

Last year, I wrote some libraries that used Azure service bus queues/topics. There were several integration tests that would run in parallel and I needed to isolate them by creating new queues/topics and used Microsoft.Azure.ServiceBus.Management.ManagementClient to do this.

It really didn't seem like I had to learn anything at all.

Going to the point now. Not discarding Pulumi's innovation which I think is great:

Will Pulumi's really add that much benefit compared to using Azure SDKs?

What's been your experience with it?

Fabio Milheiro
  • 8,100
  • 17
  • 57
  • 96

1 Answers1

8

A Pulumi developer here, so I'm definitely biased. I suspect the SO community may find your question violating some of the guidance, but I hope my answer survives :)

One upside of using Pulumi is that you get access to multiple providers with consistent developer experience. You may be using exclusively Azure, but you might at some point start combining it with things like building and publishing Docker images, deploying Kubernetes applications, or Datadog dashboards. All can be done from the same program or solution.

Now, the biggest difference with imperative SDKs is the notion of desired-state configuration. A Pulumi program describes the graph of resources and dependencies between them (what), not the steps to provision them (how). When you have an environment that lives for months and years, there's a big difference between evolving a single definition with baby steps and applying incremental changes (Pulumi) and writing a bunch of update scripts/programs to bring each environment to the new state (SDK).

How do you maintain multiple environments that may be similar but still different? (production vs staging vs test vs dev) How do you make sure that your short-lived infra that you created for nightly tests reflects the reality of production? What happens when an SDK program fails in the middle - can you retry running it again or will it create duplicate resources/fail with another error? How do you get a simple overview of changes over time in git? Concurrency control? Change history?

All the things above are baked into Pulumi and require manual consideration with a cloud SDK.

Mikhail Shilkov
  • 34,128
  • 3
  • 68
  • 107