Pulumi Launches Package Registry to Ease Infrastructure Automation

Infrastructure automation software provider Pulumi has announced a company-branded package registry to provide a central place for Pulumi users to find its integration packages.

This is mostly about being a directory to make search and discovery easier, rather than a central repository of the actual packages (like a container registry like Docker Hub or code repository like GitHub or GitLab). The packages themselves will continue to be available via language-specific package managers like PyPI, npm, or NuGet.

It seems mostly geared around making it easier for customers to locate high-quality integrations with the infrastructure components they’re already using, and to gauge the strength of the Pulumi ecosystem. The success of an automation tool like Pulumi depends on how easy it is to get it working in your environment, and how well it supports the components you’re already using. By showcasing the breadth of partnerships and support that Pulumi already has, it’s signalling that it’s a serious option to people who are considering automation for the first time, or perhaps looking to move away from an existing system that has become too cumbersome.

In speaking with customers over the past week, this “switching” category seems to be growing. There are plenty of people who have deployed earlier mechanisms (custom bash scripts, Ansible, Puppet, Chef) who are finding what they already have to be somewhat unwieldy, especially when dealing with the continuous change and explosion of components that comes with Kubernetes and cloud-native style development.

There are also a lot of infrastructure people only just now coming to the infrastructure-as-code automation game. They are arriving with a much better appreciation for what software can do compared to previous manual, CLI and GUI-only methods. Doing everything by hand is far less acceptable now than it used to be, and this is creating pressure on admins to learn how to write software, at least a little bit. In fact, their lack of affinity for software helps Pulumi, because these admins don’t want to become deep experts in software engineering practices. They have stuff to do.

The automated generation of cross-language support due to Pulumi’s schema-based package definitions is a massive boon to adoption as well. Admins that have chosen a preferred language don’t have time to learn another one just to make some piece of automation software work. I shouldn’t need to be proficient in Python, Go, Javascript and C# just to automate my infrastructure stack. And with Pulumi, they don’t have to. Different people can just use the language they’re already comfortable in, and that the rest of their team already understands, and Pulumi can automatically translate a package to work with people who code primarily in a different language.

How well this works in practice remains to be seen, but the tight constraints that Pulumi requires make this a far more tractable problem than a general-purpose language cross-compiler or software generator. The code can be serviceable enough for what it needs to do without as much effort, and that’s exactly what this audience needs. This is a pragmatic, get-things-done crowd for the most part, and ivory-tower elegance isn’t something they’ve ever really done before and aren’t about to start now.

It has never been easier to automate the tedious toil of infrastructure operations, and past me is pretty jealous of how much easier it is today. Those of you who haven’t had to wrestle tcl/tk and expect scripts to bludgeon dozens of Cisco switches into submission don’t know how easy you have it.

I hope we never have to experience those dark days again.