Infrastructure Is Code and with Pulumi 2.0, so Is Architecture and Policy – InApps 2022

The idea behind the Pulumi platform is that developers, operations teams and especially DevOps are more productive when they build infrastructure using programming languages, development tools and development pipelines; not just because they’re familiar, but because they have rich tooling and powerful constructs and abstractions for creating software — and modern infrastructure is (mostly) software.

Software development is also about modular, reusable components that can be shared and distributed, using ecosystem tools like package managers, letting you compose resources into an architecture. With version 2.0 of Pulumi, teams can now reuse code, apply policies and do integration testing of infrastructure the same way they do for application development.

“The end-to-end lifecycle of how you operationalize infrastructure in your team spans a number of different facets, beyond provisioning,” Pulumi founder and CEO Joe Duffy told InApps. “How do you do continuous delivery in your organization, how do you have application and infrastructure code policy, and being able to enforce best practices around security, compliance, cost management and so on.”

There are more CI/CD integrations with the new version because while command-line interfaces are popular, “most people doing production are using like Spinnaker or Azure DevOps Pipelines or codefresh or one of these systems,” he notes.

That approach makes Pulumi a good fit for the GitOps model. “As you’re doing deployments to Pulumi, it’s almost like what you get for GitHub with git commits. You get the same thing for infrastructure changes where you can go you can see the diff; you can see who changed what when and it links back to the git commit that triggered this, the branch and the pull request. You can even integrate this into your pull request workflow so you can see annotated pull requests with what the infrastructure changes would be before you actually merge a change.”

“What Kubernetes is to your computing, Pulumi is to your approach to infrastructure delivery.” — Joe Duffy

This end-to-end visibility makes it easier to review infrastructure changes with colleagues before they’re applied because it’s easier to see what the effect will be. Creating tests as code is also part of that.

“Testing is actually turning out to be a really common area where you’ve got programming languages which allow you to do great automation and bring to bear lots of tools and test frameworks and applying that to do infrastructure testing. We’re seeing a lot of passion around different kinds of testing, whether it’s unit testing, integration testing with ephemeral environments or even advanced testing like fuzz testing. What happens if there is a network failure, what happens if one of my VMs just randomly dies?”

Composing Infrastructure From Common Components

Using code to deploy infrastructure doesn’t just make deployments repeatable: it makes them reproducible and reusable because the code describes not just an instance but an architecture.

“Using real programming languages means you have sharing and reuse and packages and you can build bigger things out of smaller things. A lot of teams are using that to really uplevel the way that they think about their architectures and cloud architectures and codifying those using programming language constructs. Now we’ve built a component model so you can create reusable components that are basically like Pulumi resources, but you’ve authored them yourself.”

Chart courtesy of Pulumi.

Packages fit in with the layered approach Pulumi uses to simplify building infrastructure across multiple providers: “Most of our major customers are having to deal with multicloud in one way or another,” he notes.

“We view it as a spectrum where at the bottom, we’ve got over 30 of these foundation providers and they’re just libraries, but for those who want to get full access to the full cloud we don’t get in your way; there’s no opinionation. Above that, we layer libraries that are for common patterns like creating a network in Azure or publishing to a private Docker registry in Amazon. Then on the top, we’ve got these best practice frameworks that really have the utmost productivity. But you get to pick at which point along the spectrum you want to program, you can even mix and match these things.”

About a third of customers are using Pulumi to manage Kubernetes, either the infrastructure or resources inside the cluster. “What Kubernetes is to your computing, Pulumi is to your approach to infrastructure delivery. When an organization is introducing Kubernetes into the mix, it changes so much that for the most part, teams are stepping back and rethinking the entire approach.”

But that doesn’t mean they’re only using Kubernetes.

“Even companies adopting Kubernetes, they’re still going to use, like AWS services, they’re going to use s3, they’re going to use RDS rather than hosting their own database inside Kubernetes, which would be overkill for most people overkill. They still have a few VMs in the mix. We’re not trying to abstract over the differences between different clouds, we’re not trying to hide what makes AWS great from you. We’re trying to embrace what makes each of the cloud providers great and just give you one consistent way of doing things.

Pulumi 2 also supports what Duffy calls ‘policy as code’ of using packages, which makes it useful for security engineers as well. “You can use your favorite language and you can author these policy packs like ‘make sure RDS is running MySQL version 5.7 or greater’ or ‘make sure my security groups don’t have Ingress rules open to the internet’.”

Policies work with the open source version of Pulumi but the enterprise edition has features to enforce policies across the organization, integrating with SAML SSO and identity systems like GitHub, Okta and Azure Active Directory for role-based controls. “If you want to say ‘my production stacks are different from my development stacks’ you can do that” with a policy,” he said. “Or if you want to say ‘my security engineers can apply policy packs but my developers have no control over what policies run, they just get run automatically when they do deployments,’ you can set up those roles in your organization separately.”

Consuming infrastructure and policy packages with Pulumi relies on the familiar development ecosystem. “If you’re using npm for your application packages, now you can use it for infrastructure packages. Or if you’re using Artifactory because you wanted that end-to-end signing process when you publish a new binary, now you can apply that to infrastructure ” and policy.

Questions of package identity and provenance are getting more scrutiny as part of the open source supply chain and Duffy notes that using existing package managers means Pulumi will inherit the solutions they adopt, but there are already extra safeguards for policy packages.

The company applies semantic versioning to “the policy code packages and part of the enterprise management is being able to apply specific versions of policy packs and knowing that those versions are signed and are coming from the right place. We have additional features in the roadmap to do additional signing for the checks themselves so that the policy that runs would have sort of a checksum that happens to make sure that the right policy actually ran at runtime.”

DevOps on Demand

Even with DevOps and Kubernetes as a common interface, there are still silos of developers and infrastructure operations in many organizations. That slows down cloud adoption and app modernization, Duffy says. “The reason teams are picking Pulumi is they want their developers to think about the cloud as a first-class thing when they’re building their software. They don’t want it to be an afterthought. They don’t want developers to go crank out features, then throw it over the wall and have the infrastructure team deal with it. They want to break down those walls.”

Using code to manage infrastructure, architecture, policy and testing means they can standardize on a single approach and turn that into an internal platform. “The infrastructure team can take their architectures and encode them in packages and then the security team can work with them to make sure that they’ve got the right policies in place, and then developers can come and be more self-service and know that they’re doing things the right way, that the security team has made sure that the policies are enforced in the right ways.”

In the past, the infrastructure team might have pre-packaged VMs for developers to spin up. Now they can be much more granular but will have patterns and policies. “A developer might say ‘give me a new microservice.’ What is a microservice? it’s a blueprint that the infrastructure team built that encapsulates all the messy details around networking and how you know how it does or does not use the Kubernetes API or a private Docker registry.”

More Languages Open Infrastructure to More Developers

Support for Python, Go, .Net and C# is more mature in Pulumi 2. “When we did .Net we got F# as well,” Duffy notes. “Doing infrastructure in a functional language is very natural because in a sense it’s declarative.”

PowerShell support is still a proof of concept that Pulumi plans to validate with some enterprise customers before adding it in a 2.1 release about a month after the launch of 2.0.

There have been a lot of requests to support Java (and almost as many for Scala support); that’s ‘on the horizon’ along with Ruby, Duffy says. “No commitment but almost certainly going to happen at some point.”

Full support for languages means working with the right tools and with the idiom of the language. That means things like being able to use an IDE debugger with a Python code. “As a startup, we don’t have to go crazy implementing plugins for all the different editors in the world: that just lights up and it just works. Tools you already know, whether that’s a linter or test framework, static analysis, code search, refactoring; all these things you know now apply to your infrastructure code.”

Adding new languages brings in new ecosystems and new communities of developers, Duffy says. “We’re finding a lot of traction with developers with Node.js. Most infrastructure teams, frankly, will say ‘I don’t want to touch JavaScript, but I love Python.’ A lot of ops folks have some Boto scripting, they’ve done Chef and Puppet, so they know Ruby — so Python is a comfortable thing for them to pick up. Go is really resonating with folks building larger systems where infrastructure provisioning is part of that system.”

As an example, Cockroach Labs is using Pulumi to build new instances of their Database-as-a-Service for new customers. “You go to their page and you click a button and it spins up a new Cockroach database; on the back end, they’re actually using Pulumi to build the Kubernetes clusters, deploy into them, version the resources and do that across multiple clouds.”

That’s an integration that would once have needed fairly specialized knowledge to build. Pulumi, says Duffy, makes it an option that’s available to far more developers.

“Folks graduating from college these days didn’t learn some YAML dialect or proprietary domain-specific language; but they did learn Python, they did learn JavaScript. We’re finding that this approach is making infrastructure as code more accessible to a larger set of folks than it has been in the past.”

Feature image by 畅 苏 from Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.