Join us on June 5th for a Tech Talk with Bill Doerrfeld and Kenn Hussey as we discuss the future of open source. Register now

Wrangling Complexity for a Better Developer Experience

Bo Daley, DevOps Platform Engineer at Zipcar, talked to Ambassador Labs about designing a developer platform to deliver better developer workflows and experiences.

How can DevOps help developers become better and more effective at their jobs? Bo Daley asked himself this question as he and his team at Zipcar evolved their thinking on delivering developer support. As the thinking transitioned, it converged around building a platform that would give developers a seamless path from coding locally to production. Bo describes this process to Ambassador Labs's Daniel Bryant, and also emphasizes the importance of communication and having empathy in supporting the developer experience.

Kubernetes as a general purpose framework: Primed for flexibility

"Most of us are not doing general purpose work, but because it is easy to create standards on the generic tools Kubernetes provides, we can use Kubernetes as the framework. We then have the flexibility to build our abstractions, relevant to our own business problems, on top." -Bo Daley, DevOps Platform Engineer, Zipcar

Kubernetes has become a de facto standard in cloud-native platforms, and for Zipcar, it has provided a unifying and flexible general purpose framework. Acting as a "universal control", as Kelsey Hightower described Kubernetes in a recent Ambassador Labs podcast, Kubernetes provides flexibility to build and promote a standard but modular platform that balances dueling developer demands: a clear, paved path for efficiency and getting code into production AND an 'escape hatch' that supports developer autonomy and freedom.

"A new developer is going to take some time to absorb all the pieces of the platform, and to fully grasp all the levers they can pull. Our approach, which makes it simpler, is to abstract and codify what we consider to be the best practices or conventions to pave the path. But we don't fence developers in.” -Bo Daley, DevOps Platform Engineer, Zipcar

How should platform engineers design the developer platform: What do developers need to be productive?

What do developers need to be productive? Ideally, they have a way to code, ship, and run their software rapidly and safely. In order to get there, the developer platform needs to meet a few requirements, such as enabling fast feedback loops and providing well-defined workflows. In Zipcar's setup, they will likely retain their historical CI/CD approach to achieve many of these goals. These include fast developer feedback and frequent code deployments into a safe environment that can be tested and verified in pre-production.

For the Zipcar DevOps team, designing a developer platform has been approached with a “developer-first” mindset. That is, deliver on developer needs, as described by the Zipcar developers, and understand and build around developer workflows. A secondary but no less important design principle and consideration was the ability to migrate, both from the old way of doing things, but also from the new platform to another future improved version. Whether or not specific platforms and tools disappear, the key was to make it easy to move to a different platform, should the need arise, with minimal disruption to the developer's work and productivity. Much of this comes down to balancing the machine with the human side of engineering.

"We need to ensure that DevOps has time for developers, and that we build empathy for their experience. We invest in optimizing the developer experience by making more time to build the relationship by automating everything we can and then using that time to forge relationships with developers and understand their needs. Ops should clear the path, not be or create bottlenecks." -Bo Daley, DevOps Platform Engineer, Zipcar

Make it about the developer: "Champion a developer who is a resource for other developers"

The developer experience is defined by much more than just the technology. In addition to building a platform that considers developer experience, workflows and productivity, the experience is underpinned and driven by the relationships, communication and continuous empathy between developers, DevOps and the rest of the organization. The bottom line is that it is essential to find ways to connect and spend time with developers in whatever way is available.

"Focusing on the developer experience, for DevOps and platform engineers, is about being responsive and having real conversations, observing what developers actually do and the problems they run into.

Sometimes a developer is another developer's best resource.. Any time you find a developer who seems like they are on the verge of understanding the big picture, invest in that developer because they will help other developers, get them across the line in understanding the core concepts. Champion a developer who is a resource for other developers." -Bo Daley, DevOps Platform Engineer, Zipcar

Conclusion: Kubernetes isn't the story, the developer experience is

A common thread woven through the Ambassador Labs podcast series is the idea that Kubernetes isn't the story any more. It has become mainstream enough that it is perceived as the norm, and for many, the presumed de facto platform. It has become the foundation on which higher-order platforms and control planes are being created:

"Our in-house Zipcar platform is on Kubernetes, and we call that a developer control plane. This is effectively a command-line tool and an operator that runs inside the Kubernetes cluster, picks up state changes and makes the necessary changes in the cluster on behalf of the application. This enables us to replicate exactly the same deployment process in all our environments, simplifying and automating everything nicely." -Bo Daley, DevOps Platform Engineer, Zipcar

But Kubernetes isn't the story. Platforms and tools come and go, but supporting developer efficiency and developer experience should be what drives platform choices and changes. Platform teams may enjoy the flexibility of Kubernetes, but its flexibility in being able to use it to create a "paved-path" developer experience that also gives the option to veer off the path is where the value is.