Creating an Effective Developer Experience
Daniel Bryant, Head of DevRel at Ambassador Labs, gave a webinar on creating an effective developer experience as part of the CNCF Webinar series. Based on his experience working with cloud native applications at companies large and small, Daniel’s presentation focused on three key points:
- The developer experience is primarily about minimizing the friction from idea to code to delivering observable business value.
- How you construct your platform impacts the developer experience greatly
- High productivity comes from intentionally designing the experience of local development, packaging apps, CI/CD, deployment control, and observability
Creating Development Environments
To create a development environment, you can think about this process by breaking it down into five key questions to ask.
#1 Develop and test services locally, or within the cluster
Working locally has many advantages, like reducing the operational cost of multi-cluster apps, but some teams prefer to maintain minimal development environments by hiding Docker and Kubernetes from developers. Telepresence is a tool that allows developers to develop and debug locally while bridging to a remote Kubernetes cluster, a good example of a hybrid approach.
#2 How quick do you need user feedback?
Canary testing has become very powerful, and isn’t only for the bigger companies. With a microservices architecture, a single service team is able to test their updates with real world users. We have written a lot about canary deployments and their usefulness. However, some teams are nervous about testing in production, so this is always an important question to ask.
#3 Do you have a strong opinion on code repository structure?
If you choose a monorepo, the coordination of integration and testing across services as well as service dependency management is generally easier, but this approach can be more difficult to manage (particularly as the number of services grows). Multi-repos allow you to have clearer ownership of services and can promote looser coupling, although with this approach refactoring and code-level standardization can be challenging.
#4 Do you want to implement “guide rails” for your development teams?
This refers to creating guidelines and controls for tooling that you expose to developers. Typically, larger teams often want to provide comprehensive guide rails, as this limits (and audits) potential damage that can be caused by incorrect platform usage and also facilitates tooling knowledge transfer. Startups and smaller teams often value team independence more highly. In a hybrid model, you could offer a “paved road” platform with limited guide rails that also allow service teams complete freedom to do what they want, which comes with the the associated responsibility.
#5 How much platform should you build?
This depends on your team’s business objectives: Are you looking for product/market fit? Are you iterating on a service in production? Or are you building a mission critical service?
Workflow Tooling and Techniques
Kubernetes has become the de facto CoaaS and has a lot of operational benefits – it’s highly extensible, and allows you to build custom controllers and use the operator pattern. In order to enable a truly effective developer experience on Kubernetes, you must intentionally curate the experience of local development, packaging apps, CI/CD, Layer 7 deployment control, and observability. Daniel highlighted the following tools to consider when making these decisions (among others): Ambassador Labs, Istio, Telepresence, and Prometheus.
Get in Touch
Let's talk --> Contact Us