In the growing cloud-native landscape, there are as many different approaches to cloud-native development as there are companies in the space. One recurring theme, though, is the adoption of a developer platform or control plane as a clear way to ensure developer productivity, workflows and developer experience. These developer control planes are likewise as varied as the companies using them, but to be effective, the design of the platform needs to match the business problems they aim to solve and the goals and challenges of the developers who use them.
In the growing cloud-native landscape, there are as many different approaches to cloud-native development as there are companies in the space. One recurring theme, though, is the adoption of a developer platform or control plane as a clear way to ensure developer productivity, workflows and developer experience. These developer control planes are likewise as varied as the companies using them, but to be effective, the design of the platform needs to match the business problems they aim to solve and the goals and challenges of the developers who use them.
Several key takeaways surfaced:
- Support developer efficiency and success with an opinionated developer platform: Meeting business goals comes down to how people, and in this case developers, get their work done. At Zipcar, the platform team strives to help developers become more effective at their jobs and do this with a developer platform. "We are focused on the developer experience and on building developer understanding of how their work interacts with the other components in the system. We want to pave a seamless path to production." For Zipcar, this has meant ensuring that a developer can get up to speed and contribute right away using the tools and processes of the platform. At the same time, the platform is designed on the principle that "a developer can come up with a new idea for a microservice any time, and in a self-service way, create everything they need to get it to production. With a couple of pull requests, they can in fact be in production within an hour". While most developers might not do that practically speaking, the idea is that the platform makes it possible.
- "Automate and create" — Make sure ops removes development bottlenecks: If your organization, like Zipcar, is developer-focused, ops needs to remove roadblocks to developer productivity proactively. "Ops should clear the path, not be or create bottlenecks. Where possible, introduce automation and self-service so the operations team does not have to get involved in setting up basics like routing, load balancing, and so on. We want devs to be empowered to compose things in interesting patterns themselves without having to invent something completely new." The combination of automating processes and creating self-service opportunities not only removes traditional bottlenecks but also frees ops teams to help developers answer bigger questions or solve more challenging issues.
- Embrace flexibility to scale workloads: At Zipcar, “cloud native” meant embracing and then finding ways to reduce complexity to serve rapidly expanding workloads. "When we were setting up our development environment, it was clear it would become extremely complicated fast, going from having three or four deployables going out every week to potentially hundreds of deployables with a complicated dependency tree. Without a lot of automation and flexibility underpinned by careful planning, we could not have done this." While Zipcar's initial plan did not include migrating everything to Kubernetes, that became the way forward, and as Bo explains, it made the organization more flexible. "Now we can support things that are not just our in-house application framework, but much heavier workloads that our parent company [Avis Budget Group] has at a much more demanding scale."
- Treat Kubernetes as a generic standard: Kubernetes has emerged as somewhat of a platform standard within the cloud-native space, and at Zipcar it has been a useful, unifying general purpose framework. "It is easy to create standards on top of the generic tools Kubernetes provides." Bo shares, "Most of us are not doing general purpose work, so we can use Kubernetes as the framework, and build our abstractions, relevant to our own business problems on top." Bo cites the Ambassador Labs's podcast interview with Cheryl Hung to explain how this approach translates into developer efficiency at Zipcar but does not lock anyone into anything. That is, it is still possible with a framework like Kubernetes to give developers the freedom to access an escape hatch or "color outside the lines". Echoing Cheryl's observations, it is possible with Kubernetes to build and promote a standard platform that is modular enough to give developers autonomy.
- Consider developer empathy and workflow as part of creating a good developer experience: Empathy comes down to listening and understanding. As a concept, empathy, and humanizing the developer experience, is making its way into the work practices of many engineering organizations and cloud-native thought leaders. Bo maintains that empathy and connecting with developers pays off: "Find ways in your organization to spend time with developers. When we had offices, you could sit with developers as they were trying to solve some problem and work through a solution together and quickly understand why the code we wrote does not work for their situation. In the absence of face-to-face time, make yourself open in other ways and be responsive and have a conversation. Any time you find one of these developers who seems like they are on the verge of "getting it", or putting all the pieces together, invest in that developer because they will help other developers, get them across the line in understanding the core concepts. Champion the developer who is a resource for other developers."
Listen to the full conversation between Daniel and Bo.
