MA Microservices Meetup: Move fast and make things
1 like203 views
This document discusses the importance of process, people, and technology in developing microservices. It advocates for adopting a service-oriented development process focused on incremental improvements through frequent releases. Autonomous teams should be defined functionally rather than by technical boundaries. Technology choices like Kubernetes and Docker should aim to support a process of rapid, low-risk experimentation through deployment and observability tools. The goal is to balance stability and progress for services at different stages of maturity and adoption.
MA Microservices Meetup: Move fast and make things
- 1. Microservices: move fast and break make things Rafael Schloming
- 2. datawire.io Three components of Microservices 2 Technology Process People
- 4. datawire.io Why is process so important? 4
- 5. datawire.io Velocity comes from process, not architecture 5
- 6. datawire.io Microservices: Service Oriented Development What this means Why it works How to do it 6
- 8. datawire.io Engineering is Guess & Check 8
- 12. datawire.io Cheap Guess/Check merges roles 12
- 14. datawire.io Microservices Process: Service Oriented Development The output of the process: ● Continuously improving Service The process: ● Guess (incremental improvements) ● Check (correctness + availability & user impact in production) The tools: ● Deployment - make small guesses ● Observability - measure the impact on functionality, availability, users ● Resilience - ensure negative impacts are not catastrophic 14
- 15. datawire.io Microservices Process: Service Oriented Development Ignore architecture, focus on release frequency As soon as you have users, adjust your process to measure user impact Recognize that stability vs progress is a fundamental tradeoff ● for a single service… 15
- 17. datawire.io Microservices People: Autonomous Teams What this means Why it works How to do it 17
- 18. datawire.io Cheap Guess/Check merges roles 18
- 19. datawire.io Aggregate Health: God’s Eye View Harmful 19 A B C D EX
- 20. datawire.io Two Perspectives C’s problem: Is it worth it? D’s problem: Did I break C? 20 C DX
- 21. datawire.io Two Solutions Operational Responsibility System Visibility & Resilience 21
- 22. datawire.io Microservices People: Autonomous Teams Make your teams fully autonomous Ignore technical boundaries, define services functionally ● who uses the service, and what does it help them do God’s eye view is harmful ● decentralize the architecture & operations work to avoid organizational bottlenecks 22
- 24. datawire.io The tech stack ● Kubernetes -- infrastructure as configuration ● Docker -- build containers ● Envoy -- API gateway + L7 Router 24
- 25. datawire.io The Journey 25 Stage 1: Rapid development, early users Stage 2: Users Stage 3: Internal users, coupling Stage Successful Deploy Doesn’t crash... Minimal disruption to users... No cascade failures...
- 26. datawire.io Organizational Journey: Many services, different stages 26 Stage 1: Rapid development, early users Stage 2: Users Stage 3: Internal users, coupling Stage Successful Deploy Doesn’t crash... Minimal disruption to users... No cascade failures... Stage 1: Rapid development, early users Stage 2: Users Stage 3: Internal users, coupling Stage 1: Rapid development, early users Stage 2: Users Stage 3: Internal users, coupling Stage 1: Rapid development, early users Stage 2: Users Stage 3: Internal users, coupling Doesn’t crash... Minimal disruption to users... No cascade failures...Doesn’t crash... Minimal disruption to users... No cascade failures...Doesn’t crash... Minimal disruption to users... No cascade failures...
- 29. datawire.io Summary People: small autonomous teams Process: focus on release frequency Technology: adopt on demand to fit your workflow Demo Source: https://d6e.co/MAmsv 29