Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SACON NY 19: "Creating an effective developer experience for cloud-native apps"


Published on

Many organizations are embracing cloud-native technologies, such as microservices, containers, and Kubernetes, but are struggling to adapt their developer experience (DevEx or DX) and continuous delivery processes. Failure to adapt leads to longer lead times for delivery, frustration for developers, and stability issues in production. Architects and technical leaders need to drive this change.

The developer experience with modern cloud-native technologies is very different than the classic enterprise experience of the 1990s or even the early cloud experiences of the 2000s. For example, it’s often no longer possible to spin up an entire application or system on local hardware, and the extra layers of abstract of containers and VMs make debugging and observing systems more challenging.

Daniel Bryant explores the core concepts of the cloud-native developer experience, introduces and compares several useful tools, and shares lessons learned from the trenches.

Published in: Technology
  • Be the first to comment

SACON NY 19: "Creating an effective developer experience for cloud-native apps"

  1. 1. Creating an Effective Developer Experience for Cloud-Native Apps Daniel Bryant @danielbryantuk | @datawireio
  2. 2. The “Architect” Role is Changing
  3. 3. “Developer Experience”
  4. 4. tl;dr “Developer experience” is primarily about minimising the friction between having an idea to delivering some code into production that provides business value How you construct your ‘platform’ impacts the developer experience greatly Architects need to think about intentionally designing this platform
  5. 5. @danielbryantuk Independent Technical Consultant, Product Architect at Datawire and News Manager at InfoQ Previously: Academic, software developer (from startups to gov), architect, consultant, CTO, trainer, conference tourist… Leading change through technology and teams
  6. 6. DevEx 101
  7. 7. Developer Experience (DevEx) is about... “...reducing engineering friction between creating a hypothesis, to delivering an observable experiment (or business value) in production” - Adrian Trenaman (SVP Engineering, HBC)
  8. 8. DevEx isn’t new, but it is important ● Lead time ● Deployment frequency ● Mean time to restore (MTTR) ● Change fail percentage ● Rapid provisioning ● Basic monitoring ● Rapid app deployment
  9. 9. DevEx: Three Components
  10. 10. DevEx and Workflow
  11. 11. The Ideal Workflow
  12. 12.
  13. 13. Decentralised Biz/Product Teams; Centralised Specialists and Platform Team Z: Prototyping Team A: Mission-Critical Team T: Production Phase
  14. 14. The (Cloud) Platform Drives DevEx
  15. 15.
  16. 16.
  17. 17. CNCF Vision: Macro-Level Guidance oud-native-applications-request-for-feedback-a9365b64c790
  18. 18. Platform/architecture: Chicken/egg?
  19. 19. Should I Build a PaaS on k8s?
  20. 20. Key Questions to Think About...
  21. 21. Develop and test services locally, or within the cluster (or both)? ● Working locally has many advantages ○ Reduce ops cost of multi-cluster ● However, some systems are simply too large to run locally (for integration tests) ● Local/remote container dev tools like Telepresence and Squash allow hybrid
  22. 22. How quick do you need user feedback? ● Probabilistic guarantees with pre-prod testing in complex systems ● Canary testing is very powerful ○ As is developing in prod and shadowing ● Needs app and platform support ○ And appropriate architecture -sane-way-9bb31d158c16
  23. 23. 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 ● Hybrid? Offer platform, but allow service teams freedom and responsibility
  24. 24. Where should you focus your efforts?
  25. 25. Some thoughts on this... Prototype Production Mission Critical Dev and test Local / hybrid Local / hybrid / MDC MDC / local Deployment Canary Canary / pre-prod test Pre-prod test / Canary Guide rails “YOLO” Limited Strong Where to focus? Inner development loop & CI/CD Scaffolding (codifying best practices) Testing (pre/post-prod, and environment/data re-creation)
  26. 26. Workflow Tooling and Techniques
  27. 27. Pattern: K8s as a Foundation ● Kubernetes becoming de facto CoaaS (the new cloud broker?) ○ Lots of hosted options ● Know the extension points ○ Custom Controllers ○ Operators ○ CloudBuddies ● Extension enables custom workflow ○ “Kubernetes Custom Resource, Controller and Operator Development Tools”
  28. 28. Vendor Lock-in “Engineers sometimes 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 @adrianco
  29. 29. Pattern: Automate Inner Dev Loop
  30. 30. Pattern: Automate Inner Dev Loop ksonnet-vs-metaparticle-vs-skaffold-f5aa9561f948 tes-helm-related-tools/
  31. 31. ● 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 ● Tilt ○ Automates “inner loop” build-test-deploy ● Garden ○ Automates local build-push-test-deploy 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 ● Telepresence (*) ○ Enables local-to-prod development (*) CNCF projects
  32. 32.
  33. 33. Skaffold
  34. 34. Telepresence
  35. 35. Pattern: Self-Service Init and Deploy
  36. 36. Pattern: Envoy for Managing L7 Traffic ● Implementing cross-cutting concerns in the platform enables loose-coupling ● Allows fine-grained deploy/release ● Many control planes (for Envoy) ○ Ambassador ○ Gloo ○ Istio
  37. 37. Pattern: CI/CD Enforces Policy ● Make is easy to do the right thing ○ Self-service pipeline creations ○ Bake-in hooks/slots for platform functionality ○ Sensible policy defaults ● Testing of NFRs is vital ○ Security ○ Performance ○ Quality
  38. 38. Pattern: Observability > Testing ● Essential part of the platform and developer workflow/experience ○ Monitoring, logging and tracing ○ Bake-in hooks to scaffolding ● Global && service-to-service dashboards ● “Observability and Avoiding Alert Overload from Microservices at the Financial Times”
  39. 39. UX, it matters...
  40. 40. Conclusion
  41. 41. In Summary The developer experience is primarily about minimising the friction between having an idea, to dev/test, to deploy, 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
  42. 42. Thanks for Listening! Questions, comments, thoughts… @danielbryantuk More info: | | |, | “Kubernetes Up and Running”
  43. 43. Bonus
  44. 44. Do you have a strong opinion on code repository structure? ● Monorepo: ○ Coordination of integration and testing across services is generally easier, ○ Service dependency management easier ● Multi-repo: ○ Clearer ownership ○ Can promote loose coupling ○ Refactoring and code-level standardization can be challenging
  45. 45.