How Pulumi’s developer-first approach constrains and enables developer freedom

Software developers have never been more important to enterprise innovation, but there are right and wrong ways to enable them to be successful.

We’ve become so accustomed to celebrating developers as “the new kingmakers” that we can fall into the fallacy of thinking this means developers should have unbridled freedom. But as Pulumi CEO Joe Duffy and Redmonk co-founder James Governor recently discussed, the most successful enterprises will put guardrails in place to help developers express their creativity without running afoul of security or other problems.

Developer-first infrastructure

Pulumi, which makes it straightforward to create, deploy and manage cloud infrastructure using the increasingly popular infrastructure-as-code approach, is all about enabling developers. In fact, the company’s tagline is “developer-first infrastructure as code,” and makes a point of stressing to developers that they can use their preferred cloud, programming language, etc.

SEE: Mobile device security policy (TechRepublic Premium)

If developers are the new kingmakers, Pulumi is all in. The company encapsulates the characteristics of developer-first infrastructure in this way:

1. Unified engineering: Software engineering tools and practices for applications and infrastructure.
2. APIs: Making everything programmable and composable with APIs.
3. Everything as Code: Use “as code” techniques like infrastructure as code and policy as code.
4. Polyglot: Embrace the best language ecosystems for the job at hand.
5. Modularity: Tackle complexity with real sharing and reuse, not copy and paste.
6. Continuous delivery: Deliver and scale applications and infrastructure with automated techniques.
7. Continuous Verification: Verify and enforce guardrails at all times.
8. Environment parity: Share as much as possible between dev, test and prod environments.
9. Securely configured: Loosely couple and securely configure environments.
10. Distributed architectures: Go beyond “lift and shift” to building truly cloud-native applications and infrastructure.
11. Observable: Instrument applications and infrastructure to log high cardinality events, early and often.

But “developer-first” is not the same thing as saying “developer-only.” As Duffy stressed in the Redmonk interview, “‘Developer first’ doesn’t mean there isn’t an infrastructure team or a DevOps team. Of course there is. Those require deep domain expertise to run cos- effective, secure Kubernetes clusters, for example.” It’s tempting to think that DevOps means that developers take on all operations functions but, Duffy noted, “Most developers are not going to go deep on” things like Kubernetes cluster security. It’s not their primary interest or skillset.

The goal for infrastructure teams and others, then, is to “empower the developers because…that’s what is going to get the level of innovation [the business] needs.” In so doing, however, you “can’t give away the keys to the kingdom” and “need to make sure things are still secure [and…] that guardrails are in place.” Such guardrails might include compliance, security, and cost policies that keep developers from accidentally spinning up resources that blow up the company’s cloud bill overnight. Those same guardrails ensure that “even if something gets into production, we’re continuously verifying that things are safe and sound.”

If this sounds like a straightjacket on developer freedom, it’s actually the opposite, Governor responded. “Guardrails should make you more free” because they “take worry out of your hands. Safety is aligned with freedom.”

So this might mean embracing the principle of least privilege, requiring explicit opt-in to move beyond defaults in Kubernetes, Amazon S3 or other popular tools. “Root access is the root of all evil,” Governor quipped.

Help me to help you

Though not discussed in the interview, this also increasingly means self-service development platforms. Netflix, for example, creates centralized tooling that serves as a “paved road” for its developers. “Teams have the freedom to implement alternative solutions, but they also take on additional responsibility for maintaining these solutions.” It’s easier to stay on that paved path, most of the time, which comes with the guardrails envisioned by Duffy.

In an interview with Weaveworks CEO Alexis Richardson, he talked through how such constrained environments help both the enterprise and their developers. It’s not surprising that enterprises want “fast but safe,” he said, which means making sure “that compliance and security are in place, … containers are scanned, supply chain is verified in the GitOps pipeline, and so on.” In so doing, this allows “app devs to become super productive so that the time from idea to dopamine is minimal.” In other words, he said, by giving developers “a standard, pre-approved environment in which the effort to create an app from an idea is minimal, [developers can] focus on innovation not plumbing.”

Developers win. Enterprises win. Customers win.

So, yes, developers remain the new kingmakers, and companies should take a developer-first approach to infrastructure and more. But this was never meant to downplay the importance of security, operations or other teams. Rather, it’s a symbiotic relationship that should make each more productive through intelligent guardrails.

Disclosure: I work for MongoDB but the views expressed herein are mine.