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.
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. @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
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)
https://www.infoq.com/news/2017/07/remove-friction-dev-ex
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
https://martinfowler.com/bliki/MicroservicePrerequisites.html
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. 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
https://medium.com/@copyconstruct/testing-microservices-the
-sane-way-9bb31d158c16
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
https://blog.openshift.com/multiple-deployment-methods-openshift/
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)
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. 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
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 https://www.infoq.com/articles/ambassador-api-gateway-kubernetes
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
https://www.youtube.com/watch?v=hJkhPP2OLA8
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”
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. 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”
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
http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository