How the Platform Experience Is Changing with Cloud Native

Over the past five years, an almost exponentially increasing number of tools were created to support the growth, uptake and popularity of cloud native development. Not only does this show the health of the ecosystem and a broad willingness to invent and innovate, but it also overloads the cognitive buffer in an already complex and changing software development arena.

Against a backdrop of increasing ownership responsibility, how can developers be expected to code, ship and run their applications when they are overwhelmed by too many tool choices?

This is where platform teams enter the fray. In the absence of a widespread consolidation of tools, cloud native platform teams are focusing on centralizing the developer experience and providing a “single pane of glass” overview and an opinionated set of tools.

The goal is to prevent developers from being overexposed to some of the complexity associated with developing in cloud environments with multiple layers of infrastructure, and instead put them into the driver’s seat quicker with the tools and continuous feedback loop they need.

This article, the third in a series, discusses how platform teams can empower developers with a self-service approach that creates efficiencies for developers, site reliability engineers (SREs) and for themselves, supporting a centralized developer experience to simplify the process of shipping software safely and at speed.

The Cloud Native Platform Team Experience

Most experienced platform teams will concur: There’s no right way to “shift left” the operational responsibilities any more than there is a defined, right set of tools that a developer has to use to ship and run their software. Working fast and iteratively with safety, the ostensible purposes of cloud native development, is facilitated by providing an opinionated, “paved path” to taking on full life-cycle ownership.

If a developer is new to an organization, or to cloud native development as a whole, cutting a clear path through cloud native tool sprawl, defining developer-friendly workflows and providing a single pane of glass for service visibility and insight gets a developer up and running and shipping software much faster.

A platform team’s role, as with the SRE, then is to support eventual developer ownership with a clear framework and a good user experience that contributes to strong foundations, not just for the developer, but for the cloud native organization itself.

As one leading platform architect shared, “Our job is to create an easy choice, but if that is not what the developer wants, they have the freedom to control it for themselves… but then it’s their responsibility.”

Part of the ownership and empowerment journey, whether accelerating developer ramp-up or increasing productivity, is fostering true developer freedom balanced with responsibility.

Developer Self-Service Regardless of Ownership

Even in organizations that don’t expect developers to take on full ownership, there are benefits to implementing self-service management for developers. Platform teams that invest in creating the right abstraction layer with self-service built in reap the benefits across the organization while also making developers’ jobs easier.

Developers can benefit from faster inner dev loops, gain clear overviews of their services and their dependencies, and do what they need to do without having to call on SREs to fix things.

The idea is to facilitate insight for developers to help them identify problems, fix what they can, and know when to “call in the cavalry” (SREs) when they can’t fix something themselves. Ultimately this relies on working from a common baseline before branching out into other tooling.

Self-service gives developers what they need to do their jobs and take a quick pulse of the system: both the “single pane of glass” to understand what is going on under the hood and the “developer control plane” to integrate these different activities and control them centrally.

At the same time, a self-service approach frees up SRE and platform resources to focus on strategic initiatives and other priorities.

Centralizing for Frictionless Developer Experiences

Creating and centralizing a clear baseline experience to reduce cognitive load, onboard new developers faster and with less friction, and boost developer and engineering teams’ productivity depends on the vision of the platform team.

Summary: Paving the Path

Enabling developer ownership is key to shipping software with speed, safely. By paving a clear path for developers and constructing support around that path and keeping it clear of obstacles, the “you build it, you run it” philosophy can become a reality.

If developers are expected to own the full software development life cycle, or even participate in the full spectrum of code, ship, and run activities, it can’t be too arduous a climb. An emerging consensus from platform architects and engineers is that they do need to empower developers. To do this, they must give them the platform and an opinionated take on tools, and not simply put more responsibility onto developers without context and support, e.g., “Go figure it out and become experts in all these different systems.”

For mature platform teams, setting out a clear, recommended paved path provides guardrails, adding the caveat that it’s not the only way to do things, but it’s one known way it will work.

Successful cloud native platform teams lay the groundwork for shifting left, giving developers a set of tools and visibility at the outset, helping organizations to realize the speed promised by cloud native development.