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; and key considerations in implementing a cloud-native workflow.
3. @danielbryantuk
Independent Technical Consultant, Product Architect at Datawire
Previously: Academic, software developer (from startups to gov),
architect, consultant, CTO, trainer, conference tourist…
Leading change through technology and teams
5. 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
6. 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
16. Fundamental questions
Do you understand your domain?
Is your problem domain complex?
Do you have product/market fit?
Question
Is your solution event-driven (and simple)?
Should you be adding value elsewhere?
17. SOLID K8s: Open for Extension...
● Kubernetes becoming de facto CoaaS (the new cloud broker?)
○ Lots of hosted options
● Know the extension points
○ Custom Resources & Controllers
○ Operators
○ CloudBuddies
● Extension enables custom workflow
○ “Kubernetes Custom Resource, Controller and Operator Development Tools”
22. 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
Question
24. How do want to verify your system?
● Pre-prod testing in complex systems
● Canary testing is very powerful
https://medium.com/@copyconstruct/testing-microservices-
the-sane-way-9bb31d158c16
Question
25. Envoy for Managing L7 Traffic
● “Service-mesh all the things”?
● Allows fine-grained release
● Many control planes (for Envoy)
○ Ambassador
○ Gloo
○ Istio
○ Consul Connect
https://www.infoq.com/articles/ambassador-api-gateway-kubernetes
28. Canary gotchas (and mitigations)
● Observability is a prerequisite
○ Service Level Indicators (SLIs)
○ Service Level Objectives (SLOs)
○ Key Performance Indicators (KPIs)
● Needs high volume of diverse
(representative) traffic
● Take care with side effects
● Focus on “golden signals”
○ Latency, traffic, errors, saturation
○ Okay to initially “eyeball” data
○ Create actionable alerts
● Load test (with flag header)
● Run synthetic transactions
● Service virtualisation (Hoverfly)
30. Do you want to implement “guard rails”
for your development teams?
● Larger teams often want to provide
comprehensive guard 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/
Question
35. Some thoughts on where to focus...
Prototype Production Mission Critical
Dev and test Local / hybrid Hybrid / local / staged Local / (hybrid) staged
Release Canary
(synthetic shadow)
Canary / pre-prod test Pre-prod test / Canary
Guide rails “YOLO” Limited Strong
Where to focus? Inner development
loop & CI/CD
Observability and
scaffolding (codifying
best practices)
Observability, debugging
and “recreatability”
(environment & data)
37. In Summary
The developer experience is primarily about minimising the friction between having
an idea, to dev/test, to release, to delivering observable business value
How you construct your ‘platform’ impacts the developer experience greatly
You must intentionally curate the experience of: local development, continuous
delivery, release control, observability, debuggability, and more...
38. Thanks for Listening!
Questions, comments, thoughts…
db@datawire.io
@danielbryantuk
More info: getambassador.io | telepresence.io | Canary Releasing
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
47. 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
48. 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”
How you construct your ‘platform’ impacts the developer experience greatly
...is minimising the distance between a good idea and production
Do you want to implement “guide rails” for your development teams?
Larger teams and enterprises often want to provide comprehensive guide rails for development teams; these constrain the workflow and toolset being used. Doing this has many advantages, such as the reduction of friction when moving engineers across projects, and the creation of integrated debug tooling and auditing is easier. The key trade-off is the limited flexibility associated with the establishment of workflows required for exceptional circumstances, such as when a project requires a custom build and deployment or differing test tooling. Red Hat’s OpenShift and Pivotal Cloud Foundry offer PaaS-es that are popular within many enterprise organizations.
Startups and small/medium enterprises (SMEs) may instead value team independence, where each team chooses the most appropriate workflow and developer tooling for them. My colleague, Rafael Schloming, has spoken about the associated benefits and challenges at QCon San Francisco: Patterns for Microservice Developer Workflows and Deployment. Teams embracing this approach often operate a Kubernetes cluster via a cloud vendor, such as Google’s GKE or Azure’s AKS, and utilize a combination of vendor services and open-source tooling.
A hybrid approach, such as that espoused by Netflix, is to provide a centralized platform team and approved/managed tooling, but allow any service team the freedom to implement their own workflow and associated tooling that they will also have the responsibility for managing. My summary of Yunong Xiao’s QCon New York talk provides more insight to the ideas: The “Paved Road” PaaS for Microservices at Netflix. This hybrid approach is the style we favor at Datawire, and we are building open-source tooling to support this.