Velocity NY 2018 "The Cloud Native Developer Workflow"
0 likes266 views
The document discusses creating an effective developer experience on Kubernetes by minimizing friction from idea to code to delivering business value. It emphasizes that the design of the platform greatly impacts productivity and the overall experience, focusing on local development, CI/CD, deployment, and observability. Key considerations include user feedback speed, guide rails for development teams, and the balance between independence and structure in workflows.
Velocity NY 2018 "The Cloud Native Developer Workflow"
- 1. Creating an Effective Developer Experience on Kubernetes Daniel Bryant @danielbryantuk | @datawireio
- 2. tl;dr The developer experience is primarily about minimising the friction from idea to code to delivering observable business value How you construct your ‘platform’ impacts the developer experience greatly High productivity (and fun) comes from intentionally designing experience of: local development, packaging apps, CI/CD, deployment control, and observability
- 3. @danielbryantuk Independent Technical Consultant, Product Architect at Datawire Previously: Academic, software developer (from startups to gov), consultant, CTO, trainer, conference tourist... Leading change through technology and teams
- 4. DevEx 101
- 5. DevEx... ...reducing engineering friction between creating a hypothesis to delivering an observable experiment (or value) in production - Adrian Trenaman (SVP Engineering, HBC) https://www.infoq.com/news/2017/07/remove-friction-dev-ex
- 6. DevEx: DevOps, Lean, and UX
- 13. Should I Build a PaaS on k8s?
- 14. Key Questions to Ask...
- 15. Develop and test services locally, or within the cluster (or both)? ● Working locally has many advantages ○ Reduce ops cost of multi-cluster ● Some want to maintain minimal local development envs ○ Or hide Docker/k8s from devs ● Local/remote container dev tools like Telepresence and Squash allow hybrid
- 16. How quick do you need user feedback? ● Canary testing is very powerful ○ As is developing in prod and shadowing ○ K8s tools like Istio & Ambassador enable this ● Needs app and platform support ● Some teams can be nervous about testing in production (quite rightly!)
- 17. Do you want to implement “guide rails” for your development teams? ● Larger teams often want to provide comprehensive guide rails ● Startups and SMEs may instead value team independence ○ #YOLO ● Hybrid? Offer platform, but allow service teams freedom and responsibility https://blog.openshift.com/multiple-deployment-methods-openshift/
- 19. Pattern: K8s as a Foundation ● Kubernetes becoming de facto CoaaS (the new cloud broker?) ○ Lots of hosted options ● Highly extensible ○ Custom Controllers ○ Operators ○ CloudBuddies ● Extension enables custom workflow ○ “Kubernetes Custom Resource, Controller and Operator Development Tools”
- 20. DIY K8s? What About Vendor Lock-in? “Engineers go to great lengths to avoid vendor lock-in. The irony is that in doing so, they often become their own vendor... with just as troublesome behaviour and rules” - Paraphrasing Adrian Cockcroft https://www.battery.com/powered/%EF%BB%BFwho-doesnt-like-lock-in/
- 21. ● Draft ○ Automates “inner loop” build-push-deploy ○ Utilises Helm ● Gitkube ○ Automates build-push-deploy ○ Provides heroku / CF like experience ● Skaffold ○ Automates build-push-deploy ○ Watches source code ○ Provides “dev” and “run” (CD) modes ● Telepresence (*) ○ Enables local-to-prod development Pattern: Automate Inner Dev Loop ● Helm (*) ○ Package manager for k8s ○ Deploy and manage (ready-made) charts ● Ksonnet ○ Define k8s manifests in jsonnet ○ Create composable config/services ● Metaparticle ○ “Standard library for cloud native apps” ○ Language-specific binding ● Ballerina ○ “Microservice programming language” ○ Annotations for package and deploy (*) CNCF projects
- 22. Pattern: Automate Inner Dev Loop https://blog.hasura.io/draft-vs-gitkube-vs-helm-vs- ksonnet-vs-metaparticle-vs-skaffold-f5aa9561f948 https://codeengineered.com/blog/2018/kuberne tes-helm-related-tools/
- 23. Pattern: Envoy for Managing L7 Traffic ● Allows fine-grained deploy/release ● Enables real-time development in production (with shadowing) ● Many control planes (for Envoy) ○ Ambassador ○ Gloo ○ Istio
- 24. Pattern: CI/CD Enforces Policy ● Make is easy to do the right thing ○ Self-service pipeline creations ○ Bake-in hooks/slots for platform functionality ● Testing of NFRs is vital ○ Security, Performance, Quality ● Post-pipeline: Run chaos tests to codify properties and assert in production https://www.slideshare.net/dbryant_uk/codemotion-rome-2018-continuous-d elivery-with-containers-the-good-the-bad-and-the-ugly
- 25. Pattern: Observability > Testing ● Essential part of the platform and developer workflow/experience ○ Monitoring, logging and tracing ○ Bake-in hooks to scaffolding ● Global/service dashboards ● “Observability and Avoiding Alert Overload from Microservices at the Financial Times”
- 26. Conclusion
- 27. In Summary The developer experience is primarily about minimising the friction from idea to code to delivering observable business value How you construct your ‘platform’ impacts the developer experience greatly You must intentionally curate the experience of: local development, packaging apps, CI/CD, deployment control, and observability
- 28. Thanks for Listening! Questions, comments, thoughts… db@datawire.io @danielbryantuk More info: dzone.com/articles/creating-a-positive-developer-experience-for-conta datawire.io/what-is-cloud-native | getambassador.io | istio.io | telepresence.io, prometheus.io | “Kubernetes Up and Running”