‍

Using Infrastructure as Code (IaC) is a no-brainer when working with cloud development. For many years I have used Terraform for this purpose, the most widely adopted tool for IaC. But Terraform is not the only option in the open source community (and questionably still open source!?).

This article is geared to you that already is familiar with IaC, maybe using terraform today, or considering changing IaC tool.

There are cloud specific tools like AWS CDK (or using AWS Cloudformation directly), Azure ARM, Microsoft Bicep and Google Cloud Deployment Manager. Terraform is cloud agnostic, and there are alternatives for that also. For example Serverless Framework which is specialised for serverless services, or even Ansible which was created well before the rise of cloud vendors.

Pulumi is the new kid on the block, a cloud agnostic alternative for writing IaC. The main reason I find Pulumi exciting is that it supports multiple programming languages, like python! Now I’ve finally given it a try.

Main takeaways — TOC

In this article I share my three main takeaways after having set it up in three separate projects.

1. Using a SDK — it’s so nice to use a real programming language 🙌
2. Logical vs physical name — auto-naming is smart 🏷️
3. Switching state backends is awkward 😬

‍

‍

The three takeaways

Here are my three main takeaways after having setup Pulumi in three (smaller) projects with GCP, using python.

‍

Using a SDK 🙌

It is so nice to be able to use a familiar programming language when specifying resources, in my case python. I can use my linting tool of choice (ruff), and I simply install the Pulumi python dependencies the way I like (using poetry).

At a first glance, we are definitely writing more code with Pulumi than with Terraform. This is because Pulumi uses classes for everything.

In the battle of typed vs untyped, a typed language will always be the winner in the world of IaC.

‍

‍

It took me months to fully grasp the Terraform syntax, HashiCorp Configuration Language (HCL). You structure your Terraform code in file directories, resulting in different Terraform modules. Apart from that, you can separate your configurations any way you want, which results in varying code structures. And often mayhem.

There are helpful tools for creating more coherent terraform code in your project such as pre-commit-terraform, or even wrapper tools such as terragrunt. But even with these tools you will often get feedback of incorrect code first after running your first terraform plan command. None of these compare to the intuitive ease of using a programming language (and SDK).

Being able to use a real programming language that you know, with all the linting and formatting tools that you are already familiar with, is just great!

‍

Logical vs physical name — auto-naming is smart 🏷️

By default Pulumi creates a unique name for your resources inside the cloud provider that you’re deploying to.

When creating any resource with Pulumi, you provide a logical name. This is used by Pulumi to identify that specific resource, even when the physical resource might change (or even get replaced). The physical name is the actual name of the resource inside the cloud provider.

Pulumi uses this logical name and a random suffix to create a unique resource name for the resource; the physical name. This serves two great purposes:

1. Stacks for the same project can be deployed to the same cloud environment, avoiding name collision.
2. Allows Pulumi to do zero-downtime resource updates. Due to the way some cloud providers work, certain updates require replacing resources rather than updating them in place. By default, Pulumi creates replacements first, then updates the existing references to them, and finally deletes the old resources.

‍

‍

For example, when creating a GCP Cloud Run instance providing the name hello-world, Pulumi will create add a random suffix so that the actual Cloud Run instance in my GCP project might be called hello-world-d7c2fa0.

Both mentioned purposes are good, but I think the first one is especially great. This is a feature that I have incorporated into my terraform modules, for example to allow PR deployments in my dev cloud projects. It’s nice that Pulumi supports this out-of-the-box.

‍

Switching state backends is awkward 😬

I like to keep my IaC state close to the source, i.e. I want the state for a given stack to be stored in the same cloud which the state represents. Some benefits are:

• not accidentally interacting with another environments state
• easily locating your current environment’s state

Pulumi has opted for a different route. By default Pulumi is designed to store all your project’s different stack states in the same location.

I always store my dev IaC state in a bucket inside the same cloud project that my dev IaC is deploying to. Similarly, I store my prod IaC state in a bucket inside the same cloud project that my prod IaC is deploying to. When using terraform and GCP, this is easily configurable by providing a tf.backend file containing the name of the bucket wherein the state is stored.

‍

‍

Pulumi is clearly designed to primarily be used together with Pulumi Cloud, a platform for managing all your different projects and stacks in the same place. When switching between dev and prod, I need to run the command pulumi login gs://<bucket-containing-state> (reusing the behaviour when interacting with the payed version, i.e. Pulumi Cloud). In other words I cannot dynamically specify my backend by e.g. pointing to a specific file like I do in Terraform. Instead I have to explicitly login, passing the backend location (my bucket) as an argument.

‍

Conclusion

The end goal is the same, create infrastructure with code, and both Terraform and Pulumi succeed with this. However, I cannot help to feel that it is a lot more easy and fun to write IaC with Pulumi than with Terraform! This is because I get an immediate feedback (linting) on my IaC since I’m writing in a real programming language, not a custom json/yaml syntax (HCL).

Terraform is more widely adopted by the DevOps community, and is great for smaller projects. In bigger projects you will quickly get lost in multiple (nested) ever-growing mutating Terraform modules, which can be a real headache when debugging and onboarding new team members. Being able to stick to the best practice code structure of your programming language of choice for Pulumi will make larger IaC projects so much easier ⭐️.

My Pulumi journey has just started, and I have likely not yet discovered the best features, nor all the annoying quirks. Put bluntly — Pulumi feels more modern and future-proof. I will use Pulumi for my future projects!

‍

Bonus Pulumi impressions & thoughts

Apart from my three main takeaways that are mentioned above, these are some other initial thoughts I had.

• The Pulumi cli is nicer to work with! It provides a colourful (pink) and less verbose output that is easier to get an overview of. Interactively it can also provide more details 👍.
• When interacting with Pulumi, you’re required to provide a secret passphrase . The reasoning is that you’re likely working with sensitive infrastructure and data. In my opinion, this should be opt-in 👎.
• When using python, Pulumi creates a venv by default. I like that Pulumi nudges developers to use virtual environments (even though I opted to use poetry to manage the Pulumi dependencies instead 🙃).
• Initially I find the Pulumi concept of projects and stacks to be a little unintuitive. Likely this is just since I’m so indoctrinated in how Terraform is structured. It does however better mirror the structure of aws (also the syntax of the aws CDK) 😶.
• Running the command pulumi stack graph will export a .dot dependency graph. Nice 🤝.
• On August 10th 2023, Hashicorp changed their open-source licence to BSL v1.1 license. Maybe this is indeed the time to move away from Terraform? Thankfully the open-source community is great; OpenTofu was born. Contributors have forked Terraform from the latest open-source version, with the ambition to keep the Terraform truly open source.

‍