Xienta

View Original

Why We Choose Pulumi for Modern Cloud Deployments

Deploying applications to any cloud platform in a repeatable and reliable way is not a trivial task. That is why cloud providers like Microsoft Azure have management tools like “Azure Resource Management” templates (ARM templates) or more recently Bicep templates. These tools fall into the infrastructure as code (IaC) category that assist teams in developing the infrastructure in declarative ways. There are many third party solutions as well, most prominently Hashicorp’s terraform, and Pulumi. On the surface, both seem similar, but are actually quite different. Both are open-source, both can be used “for free”, both have immense community and cloud provider support. So why do we like Pulumi so much?

Is Pulumi Really Declarative?

The main reason why we enjoy recommending Pulumi to organisations is that, in fact, Pulumi is not declarative. Where with Azure’s ARM Templates / Bicep and terraform one has to learn a proprietary language, JSON / Bicep DSL, and HCL (Hashicorp Configuration Language), with Pulumi that is not the case. Pulumi, even though declarative under the covers, exposes its functionality via imperative languages. If you are familiar with Node.js (JavaScript, TypeScript), Python, C#/F#/VB or Go, then you already know how to write Pulumi. All you need to know is import the Pulumi modules/packages into your code and you are ready to go. All your existing investments into tooling and team know-how applies 100% and the only thing you need to now focus on is building a great cloud infrastructure, and not “how do I write a for loop in JSON?”.

Why Pulumi over Cloud Native?

Does it not make more sense to use the cloud provider’s solution? The answer here is a bit more complicated. For a very long time cloud-based applications were only deployed into one cloud platform and using the cloud provider’s native solution would get the job done. Over time however, this changed, and I am not talking about deploying a single application to Azure, AWS and GCP. I am talking about an application that has Azure based infrastructure, needs to create resources in Azure Active Directory, be onboarded to Datadog for monitoring and PagerDuty for the Ops team. See, no multi-cloud, but more than just deploying cloud infrastructure. ARM templates would stop after the first requirement. Pulumi can do all of this, in one go, using provider-specific packages available on their managed registry. No more custom scripting or manual steps pre and post deployment.

Day-0 Support for Azure

Pulumi also recently changed their approach to building their packages for Azure and AWS. Where previously Pulumi leveraged the existing terraform code base to build their AWS and Azure packages (as described here), this has now changed to Pulumi using Microsoft’s and AWS’s native API specifications to build their own native Pulumi packages. This results in much faster support for new features or services by Pulumi as they do not need to wait for terraform to release their new version before Pulumi can build and release theirs. In fact, Pulumi now found themselves in situations where they picked up changes from Microsoft API releases that even Microsoft Azure’s PowerShell modules had not picked up by then. Customers can be assured that if Microsoft released a new feature that Pulumi will support it in no time.

Migrate to Pulumi

In cases where organisations have already started building infrastructure or applications using different IaC tools there are simple ways to migrate ARM templates, AWS CloudFormation or terraform over to Pulumi using migration tools developed by Pulumi. This is unique to Pulumi and its converters that make adoption super simple.