# Pulumi First Impressions

## Introduction

Professionally, I use a combination of Terraform and [Ansible][] for provisioning cloud infrastructure and application deployment. Every once in a while I like to look at new tools to see if they are offering something better that would entice me to switch. This time around I opted to take a look at Pulumi, a newer entry in the infrastructure-as-code category. Pulumi is similar to Terraform in that it maintains its own state, but is unique in that it uses existing programming languages like Python, Go and JavaScript/TypeScript instead of a custom language. With that in mind, here are my initial thoughts after working through the sample project in the documentation, and how it stacks up with Terraform.

## Working With Pulumi

### The Tooling

Pulumi ships in the form of a CLI tool written in Go, and a set of language interfaces for Python, Go, JavaScript/TypeScript, and C#. Similar to Terraform, it has apply and destroy commands that looks at the code and the state data to make changes to cloud infrastructure. It has a feature called stacks that functions similarly to the Terraform workspace feature. It is used to separate the differences between environments without adding crazy conditional logic to the code itself.

Unlike Terraform, the Pulumi CLI ships with a setup wizard and project scaffolding. Pulumi also has a best practices library of pre-defined components that can be used speed up development while adhering to good development standards. Unfortunately, at the time I write this, the library is only available for JavaScript/TypeScript projects, and only supports AWS. Pulumi states in the documentation that library will be ported to all supported languages eventually.

Pulumi is looking to make money by offering supporting services instead of charging for the tool itself. The primary service they are selling is state management. The CLI tool defaults to using their hosted state management service, but also supports self-hosted state management options including local files, and cloud storage options like S3. Their state service is designed for multi-user scenarios, and it is unclear if the same level of safety is built into the self-hosting options.

### The Language

The really interesting idea behind Pulumi is its use of popular programming languages instead a custom language or DSL. In theory, it should make it easier for development teams to adopt Pulumi since it uses a language they are already familiar with. For my tests, I used Python. Using a compiled language like Go or C# seems like overkill, and I prefer Python over JavaScript.

The Pulumi framework is designed to appear like a declarative language. You still have all the power and features of the target language, but it encourages you to keep your infrastructure definitions simple and straightforward. I generally like this concept, provided the development team can be disciplined in their use of the tool. Without proper discipline it would be easy to use the full programming language to make a complicated mess of the infrastructure definition that is difficult to maintain.

Using a “real” programming language is nice because it gives you access to the full line of frameworks and libraries for things like unit testing, feature flags, and linting. In a mainstream language these tools are typically mature and well-supported. Terraform does not have a unit testing framework, instead it relies on performing validation testing after infrastructure is provisioned. Using techniques like feature flags feels like a vicious hack in Terraform, but is very natural in other programming languages.

## The Verdict

I think Pulumi has a lot of potential, but is still somewhat immature. I would really like to see the best practices library made available in all languages, and for their to be equivalent libraries made available for other cloud providers. Pulumi supports all three of the major public cloud providers and a handful of other services, while Terraform has a more extensive list of supported providers for services beyond the most popular. I would also like to see some optional guard rails that would make it more difficult for developers to do the wrong thing when writing infrastructure code in their favorite language.

I do not see Pulumi replacing my current tool chain any time soon, but I will keep an eye on its progress as it matures. If it provides a big jump in productivity and/or capability over Terraform, I could see adopting this tool in the future.