In a productive cloud native development workflow, individual teams can build and ship software independently from each other. But with a rapidly evolving cloud native landscape, creating an effective developer workflow using a platform based on something like Kubernetes can be challenging. You are all creating software to support the delivery of value to your customers and to the business, and therefore, the developer experience from idea generation to running (and observing) in production must be fast, reliable, and provide good feedback. During this talk Daniel will share with you several lessons learned from real world consulting experience working with teams deploying to Kubernetes. Key takeaways include: Why an efficient development workflow is so important A series of questions to ask in order to understand if you should attempt to build a PaaS on top of Kubernetes (everyone needs a platform, but how much should be built versus integrated versus bought?) A brief overview of developer experience tooling for Kubernetes, and how this domain could evolve in the future The role of Kubernetes, Envoy, Prometheus, and other popular cloud-native tools in your workflow Key considerations in implementing a cloud-native workflow

1. In Search of the Perfect
Cloud Native
Developer Experience
Daniel Bryant
@danielbryantuk | @datawireio

2. “Developer Experience”

3. 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

4. @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

5. DevEx 101

6. DevEx...
...reducing engineering friction between forming 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

7. DevEx: DevOps, Lean, and UX

8. DevEx Focuses
on Workflow

9. The Ideal Workflow

10. https://speakerdeck.com/stilkov/microservices-patterns-and-antipatterns-1

11. Decentralised Biz Teams and Control Plane;
Centralised Specialists and Platform
Team Z:
Prototyping
Team A:
Mission-Critical
Team T:
Production Phase

12. The New Normal
● Teams are responsible for end-to-end delivery and running
● Many components/interactions mean that code changes become stale quickly
● Developers must understand business goals
● Environmental parity (including data) is important
● Inner dev loop (ideally) needs to run within real environment (multi-dev cluster)
● Each developer needs to run full SDLC (self-service, without handoffs)
● “Staging” delivers low ROI; Instead favour contract tests + observability in prod

13. The Platform
Drives DevEx

14. CNCF Vision: Macro-Level Guidance
https://articles.microservices.com/developer-workflow-trail-for-cl
oud-native-applications-request-for-feedback-a9365b64c790
https://github.com/cncf/landscape#trail-map

15. https://twitter.com/kelseyhightower/status/851935087532945409

16. https://www.infoq.com/news/2017/06/paved-paas-netflix
https://www.infoq.com/news/2018/07/shopify-kubernetes-paas

17. Should I Build a
PaaS on k8s?

18. Key Questions to Ask...

19. 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 dev envs
○ Or hide Docker/k8s from devs
● Local/remote container dev tools like
Telepresence and Squash allow hybrid

20. How quick do you need
user feedback?
● Canary testing is very powerful
○ As is developing in prod and shadowing
● Needs app and platform support
● Some teams can be nervous about
testing in production

21. Do you want to implement
“guide rails” for your dev 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
https://blog.openshift.com/multiple-deployment-methods-openshift/

22. How much platform should we build?

23. 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
Code repo Mono / multi Multi / Mono Multi
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)

24. Workflow
Tooling and
Techniques

25. 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”

26. 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/

27. ● 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

28. 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/

29. Pattern: Self-Service Init and Deploy

30. 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

31. UX, it matters: API Gateway example

32. 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 https://www.slideshare.net/dbryant_uk/codemotion-rome-2018-continuous-d
elivery-with-containers-the-good-the-bad-and-the-ugly

34. 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”

35. UX, it matters: Dashboard Example

36. Conclusion

37. 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

38. 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”

39. Bonus

40. 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
http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository

41. https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html