The Cloud Native ‘Paved Path’ Developer Experience

This is the first in a three-part series.

Cloud native software development, we’ve argued, has forever changed the developer experience. Though it’s important to note: The new developer experience isn’t monolithic. There are as many different developer experiences as there are cloud native tools crowding the landscape.

We have hypothesized that a broader trend influencing the developer experience is the “shift left” approach. That is placing more ownership and responsibility for the full code-ship-run equation directly into the hands of developers. As more organizations go cloud native, the reality is more nuanced than an all-or-nothing accounting of developer responsibility and requires acknowledging that there are gradations of ownership.

This article is the first of a three-part series that features insights from discussions with cloud native thought leaders. It takes a closer look at the unique paths forward for cloud native technology across different organizations and examines how each found the “sweet spot” between full developer ownership and providing an opinionated “paved” path in the cloud native ecosystem.

Balancing Freedom and Responsibility: Where Is the Sweet Spot?

The cloud native landscape is filled with a staggering and growing number of tools, platforms and approaches to accomplish development goals. While Kubernetes appears to be dominant as the default orchestration system, the same cannot be said for tools. As a result, the idea that developers in every organization can, or should, take on full life cycle responsibility seems, if not irresponsible, impractical.

The reality is murkier and largely depends on organizational culture, business goals and a company’s level of cloud maturity. These less technical factors influence the different levels of freedom and responsibility developers experience in their work.

Nicki Watt, the CEO/CTO of technical consultancy OpenCredo explained, “Some organizations are set up to empower developers to take on as much as they want; others are siloed and prefer to “contain” developers, ensuring that there are no deviations, no going off-piste. Whether developers have full freedom to own the full software life cycle or are more constrained by organizational or platform restrictions, getting to a point where developers are empowered to take on increasing levels of responsibility can contribute to better software and better teams.”

Leaders in the cloud native space, such as Lunar’s Kasper Nissen, CartaX’s Mario Loria and Apple’s Cheryl Hung mirror these thoughts, based on their own experience working with cloud technologies in production. Providing clear guardrails, or an opinionated, “paved path,” promotes both responsibility and freedom. That is, a developer understands that taking the paved path will help them deliver what the organization expects and can offer a stable control plane to which they can always return. At the same time, many organizations provide this abstraction layer as a jumping-off point, encouraging developers to embrace the freedom to explore beyond the paved path as long as they also assume responsibility for the outcome.

Dependencies and Outcomes: Does the Developer Know Best?

What does the term “developer responsibility” really mean in practice? Even if, as we have argued, shifting left casts the developer as the driver of coding, shipping and running software, this does not actually mean that the developer is “pushing the button” at every stage of the life cycle. Instead, it is more about defining who is responsible for each step, and what consequences will follow each of the steps taken? (Hint: This will not always be the developer, no matter how much ownership developers assume.)

Cloud luminary, Kelsey Hightower, clarified the thinking when asked about developer responsibility. He explained that there are times when only a developer understands what dependencies they need. It is possible that only the developer can resolve these dependencies because they have a clearer view of possible outcomes. But this does not put all the responsibility on developers’ shoulders alone.

“If you’re the developer, you will have some responsibility for the ‘ingredients’ you add to the mix. You will be asked to understand and answer for some of the choices you make,” Kelsey stated. “But beyond the developer, everyone needs to be aware of their responsibility in that pipeline.”

There will always be limitations to the scope of what a developer can take responsibility for. Kelsey went on to highlight dependencies, such as security issues or problems that violate company policy. That is, issues well outside the purview of a software developer, but this does not relieve developers of responsibility. It just means that they should be able to account for what is actually in the software they code. This, too, is moving toward a paved path of its own in the form of software bills of materials (SBOMs).

Summary: Paved Paths as a Sign of Maturity

In the absence of workflow and tooling standardization, cloud native developers don’t need to be mavericks, figuring everything out for themselves. If the cloud native promise of shipping software faster is to materialize fully, the developer experience needs to be loosely shaped to reduce friction and enable clear visibility into code, its dependencies, source control, service ownership, and so on. Paving a path for developers in the form of a common platform creates consistency, predictability, and transparency, leapfrogging the developer experience and the organization to the next level of cloud native maturity. Ultimately this next level creates conditions for more productive engineering teams that thrive in the constantly shifting cloud native ecosystem.