Pulumi changed how I approach infrastructure and how I build web applications.
Pulumi is a tool for Infrastructure as Code, its selling point is that it uses a real programming language to describe infrastructure.
With Pulumi, you build cloud environments by specifying the resources you need and combining them together. Because Pulumi uses Typescript (or Python or any .NET language), you can create your own abstractions and use that to reduce the amount of code needed to describe your infrastructure. Pulumi is not limited to cloud resources, you can use it to describe Kubernetes resources. This means that you can use the same language to describe the resources outside the control of Kubernetes (the Kubernetes cluster itself, but also managed databases, and pub/sub queues) and the Kubernetes resources such as deployments, services, and even custom resources. Once you described what you need, the Pulumi engine will process your requirements and present you with a change plan, which you can accept and apply to your project. By default, Pulumi stores its state on the Pulumi Service backend. However, this behavior can be changed and you can store the state on the usual suspects (Amazon S3, Google Cloud Storage, Azure Blob Storage) or your local file system.
Infrastructure as Code is a way to encode your knowledge about infrastructure in code. This means that when you come back to a project months later, you can see at a glance what resources it uses and any non default settings. Because resources are linked to each other by their inputs and outputs, you can also see which resources are dependent on other resources. Pulumi even provides a web interface where you can visually see this dependency graph between resources.
Pulumi is not the only project that aims to describe infrastructure as code, the most prominent project is HashiCorp Terraform. There are some (many) differences between Terraform and Pulumi, and depending on your preferences you may like one or the other more (or none, IaC is not everyone’s thing!). The most noticeable difference is that Terraform uses its own Domain Specific Language (DSL) to describe resources, while Pulumi uses Typescript. The trade-off in using a general purpose language is that, while you gain in expressiveness, you introduce the ability to generate non-deterministic resource graphs, which will result in broken deployments. This is solved by using Pulumi provided libraries to generate, for example, pseudo random data.
Pulumi real killer feature is, however, being able to generate Kubernetes configuration directly together with the rest of infrastructure. This is a much superior approach than what is available for Terraform, which is using a separate tool to generate Kubernetes templates and deploying them.
Since discovering Pulumi I changed how I build applications completely, before that I was not sold on serverless since deploying the functions and managing the API gateway requires a lot of configuration. Pulumi makes this completely manageable, to make it even simpler they provide packages containing common abstractions used when building serverless applications.
After using Pulumi for just over one year it already changed how I approach building applications: I’m no longer reluctant to introduce dependencies on cloud resources since I know I can spin them up with a single command, and serverless has become my go-to tool when I need to create simple web services.