A couple of days after releasing it into the wild on GitHub, Terraform rival Pulumi has officially made version 2.0 available, replete with improvements on testing, CI/CD, and policy handling, among other things.
With many using a major release to get breaking changes in, the Pulumi team decided to go against that trend because it wanted to adhere to its compatibility promise, company CEO Joe Duffy told DevClass.
Since version 1.0 only landed in September 2019, it isn’t too surprising that the improvements included aren’t as profound as some would expect from a major version bump, which is not to say they aren’t of interest.
According to Duffy, Pulumi has “been really focused on end to end scenarios with cloud infrastructure we find our customers with” for v2.0, which is why continuous delivery and infrastructure policies have been a major part of the new version.
Another aspect that is supposed to help with that is better support when migrating or including old infrastructure into a new setup. “Let’s say you’ve got your networking stack in Terraform and you want to build up a bunch of new stuff around that and maybe you’re gonna come back later [to] import that, but now isn’t the right time,” Duffy offered as an example. Pulumi is now supposed to “allow you to coexist with that” and also “import existing infrastructure no matter how it was provisioned” by pointing and clicking in the console, so all subsequent changes are then done with Pulumi. And if a user thinks it’s time to make the switch, there are also conversion tools for that.
To get a complete infra pipeline up and running, Pulumi now has integrations with a number of CI/CD vendors and source control providers. This is meant to help users to get more insight into their infra history and offer views that “sort of like GitHub” helps users keep on track with every change ever made to their setup.
Other than that, the 2.0 release comes with additional testing prowess and new policy as code framework CrossGuard. It “lets you define policies using real languages and then apply those policies at deployment-time” and is meant to help keep security and compliance mistakes at a minimum.
With all of these enhancements in place, Duffy is positive more people will see Pulumi’s appeal as an infrastructure as code offering. “The basic workflow is that you’re going to use real languages, share and reuse abstractions, use your favourite tools like your favourite IDE, then provision and deliver either using our CLI or some of the CI/CD integrations we’ve got and then test them secure[ly] using our SaaS where you can audit every change that ever happened. You can manage complex environments, enforce policies, and really have the governance you need for your organisation.”
Having those consistent workflows helps to set up a standardised approach across clouds, though Duffy makes sure to point out that his company doesn’t “try to extract over what makes each of the clouds great.” He added: “We really want to make sure that when you’re on AWS, you’ve got the full power of AWS and you can take advantage of that.”
His mention of AWS in particular could be down to Pulumi not being the only option in the infrastructure as code space, with Terraform being its best known competitor, or AWS CloudFormation if the focus is more on cloud computing. Opinions diverge on which (Pulumi vs Terraform) to best use, as they are pretty similar when it comes to core functionalities. Pulumi however seems to go for an all-in-one approach lately. It for example now comes with secret management included and while HashiCorp offers Vault for that, it tends to keep the tools separate, so users are free to pick and mix.
Asked about why they are drawn to Pulumi, users mainly cite the variety of supported languages. While HashiCorp’s Terraform mainly allows definitions in its homebrew configuration language HCL and JSON, Pulumi lets users choose between Python, Node.js, Go, and .NET Core languages for that.
Duffy sees this as the perfect way to give different teams in an organisation common ground. “I think, to a lot of folks, adopting the cloud is difficult. And it leads to these organisational silos where the dev side of the house uses one set of language and tools and the infrastructure side of the house uses a different set of languages and tools.”
“Every cloud has its own different stack,” he added, which to him means a lot of copying and pasting without really getting what it is about. This in turn leads to teams not being able to adopt new tech as quickly as they’d like. “Furthermore, it’s more of an afterthought for a lot of developers.”
To make the most of advancements such as containers and serverless, however, Duffy feels it has to be deeply integrated into app building and the ability to use known tools helps with that. Thanks to abstractions and other language features, it also makes for more comprehensive infrastructure code (if you know the language), which is something anyone who ever took a look at a more complex CloudFormation script surely can appreciate.