Cloud Native / Development / Kubernetes / Sponsored / Contributed

How the Developer Experience Is Changing with Cloud Native

14 Oct 2021 7:21am, by

Daniel Bryant
Daniel Bryant is the director of developer relations at Ambassador Labs (formerly Datawire). Daniel is a Java Champion, a TechBeacon DevOps 100 Influencer and contributes to several open source projects. Additionally, Daniel is a regular contributor to industry publications and is a frequent speaker at international conferences such as KubeCon, QCon and JavaOne.

The complexity and speed of cloud native, Kubernetes-based software delivery make collaboration among traditionally decoupled roles — the developer, ops and site reliability engineers  (SREs) — essential.

More collaboration and a redefinition of traditional roles is helping to propel cloud native software development forward and break down silos, foster increased developer ownership of the full life cycle, and enable faster, safer shipping of software.

This three-part series, with insights drawn from frontline interviews with developers, SREs, platform architects and leadership, explores how the developer experience has changed, influenced in part by the changing experience of operations and site reliability teams, and what is expected of each role in the cloud native development space.

Let’s begin with the developer.

The New Normal for Developers

The developer experience is shifting away from “code and forget” to taking on full-service ownership. This is creating a developer experience in which the developer is responsible for coding, shipping and running their own applications. Of course, developers aren’t alone in this, and part of this new experience is cooperation with SREs and ops. This critical collaboration is at the heart of the changing developer experience, enabling and empowering developer ownership by creating centralized self-service tooling, education and support.

This cloud native “new normal” for developers relies on organization-wide support for the shift-left mindset and for the concept of developer-owned full life-cycle ownership. It also demands a completely different approach to collaboration, that is, an evolution in the way developers work with SRE and ops teams to focus more on strategic goals around shipping software and less on post-incident firefighting and ad-hoc requests. The more the teams work together, the easier the developer’s job assuming full life-cycle ownership becomes, and the faster and safer software ships and reaches end users.

Out with the Old

For the most part, traditional development workflows allowed for a “code and forget” developer experience. This isn’t the way cloud native development works. Microservice-driven development introduced significant changes, including new technologies and workflows. Suddenly the “inner dev loop,” the domain in which a developer spends most of their time, began to see increased coupling with the “outer dev loop” and beyond, where all kinds of unfamiliar “ship” activities, dependencies and complexities live. In many ways, thanks to this complexity, the cloud native space is still uncharted waters. Organizations that have waded into cloud native territory exist at very different levels of maturity, making it inevitable that the standard monolith will continue to live in parallel with the cloud native, and that developers will end up with a foot in each world.

For those organizations and teams that have jumped into cloud native even partly, it will be abundantly clear that the cloud native development ecosystem drives a level of complexity in building, shipping and running distributed systems that developers in particular have never had to manage or understand. The surrounding ecosystem has responded by creating many supporting tools, but this has led to “tool sprawl.” At the same time, as these tools proliferate and complexity increases, developers are being called on to own the full software development life cycle, despite their lack of familiarity with important aspects of the ship-and-run delivery equation. Without a change in the relationships among developers, SREs and ops and a breaking down of existing silos alongside a shift in the scope of work these teams do, it’s possible that the velocity promised by cloud native application development will be lost.

And in with the New

What do these new relationships look like, and how can developers adjust the way they work, not only with the new development paradigm, but also the SRE and ops teams who support their work? How can the adoption of these new working relationships help developers, SREs and ops teams alike capitalize on the flexibility and advantages of cloud native development for successful cloud native app delivery?

Developers Site Reliability Engineer (SRE) team Operations team 
Treat SREs as application operation partners, not only as first responders to incidents.

Turn to ops teams for the “paved path” or centralized developer control plane.

Provide and teach effective use of platform tooling to empower developers to be self-sufficient.

Document clear escalation paths for developers struggling in production.

Provide self-service platform deployment and observability, and enable visibility into ramifications of actions.

Provide opinionated “paved path” platform or developer control plane (DCP), but allow developers to swap platform components if they also want to be accountable.

From a developer’s perspective, “infrastructure is really, really hard.” In organizations that need to keep a tight rein on resources, empowering developers with hands-on understanding of infrastructure and running their own apps benefits the entire organization. This strategy upskills the developer and makes them more versatile, freeing up existing SRE and ops resources and gaining faster insight during incidents.

From the SRE point of view, the SRE team should get behind developer education and help the culture evolve to embrace the “you build it; you run it” approach. The SREs should support interactive self-service and incident understanding rather than “riding to the rescue” to firefight during incidents. “If developers understand the full code-ship-run journey, I am not being called to fight fires that they can manage.”

From an operations and platform perspective, the function of operations is to help balance developer freedom and responsibility, which the ops team facilitates by ensuring that the right technologies are completely embedded in the developer experience. Defining a “paved path” for developers streamlines their ramp-up, helps combat tool sprawl and supports developer ownership as a key to shipping software fast and safely.

Summary: Reaching Common Ground

While there is no unified developer experience, most cloud-native-first organizations, whatever their maturity level, experience commonalities that boil down to two key takeaways:

  • Cross-functional collaboration: For developers, cross-functional collaboration with SRE and ops teams is critical. These partner functions can ease the complexity of the developer’s work and help ensure seamlessness and speed in getting software features into the hands of users safely.
  • Empowering developer ownership: The centralization of developer control planes and the self-service approach are key cloud native best practices. Supporting the empowerment of developer ownership and offering clear self-service options and integrated tooling contribute to and drive overall engineering, and organizational, success and goal achievement.

The developer experience is changing for the better, enhancing collaboration and building on what cloud native software development can accomplish.

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Ambassador Labs.

Featured image via Pixabay

A newsletter digest of the week’s most important stories & analyses.