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.

QCon SF 2017 - Microservices: Service-Oriented Development

243 views

Published on

Conventional wisdom is that microservices is an architecture that is the spiritual successor to service-oriented architecture. While true, this myopic view of microservices ignores some of the profound workflow shifts in today’s microservices organizations.

The reality is that microservices is an architecture _and_ workflow. In this talk, we’ll introduce the workflow of service-oriented development. Rafael will talk about how the real goal of microservices is to break up a monolithic development workflow. We’ll show you how, by breaking up your workflow, you can build software that lets you move fast and make things.

Published in: Software
  • Be the first to comment

  • Be the first to like this

QCon SF 2017 - Microservices: Service-Oriented Development

  1. 1. Microservices: Service Oriented Development Rafael Schloming
  2. 2. datawire.io How do I break up my monolith? How do I architect my app with microservices? What infrastructure do I need in place before I can benefit from microservices? 2
  3. 3. datawire.io ● Building a cloud application using microservices in 2013 ● Distributed systems engineers ● Multiple services ● Prototyping was really fast ● … then we launched and things slowed down… 3 Microservices at Datawire ...
  4. 4. datawire.io Debugging Velocity (or lack thereof) 4
  5. 5. datawire.io Tooling Architecture Process!!! 5
  6. 6. datawire.io Debugging our Pipeline 6
  7. 7. datawire.io Velocity comes from Process, not Architecture 7
  8. 8. datawire.io Service Oriented Architecture Service Oriented Development 8
  9. 9. datawire.io 9 Stability/Maturity Velocity Prototype Production Mission critical
  10. 10. datawire.io 10 Stability/Maturity Velocity Prototype Production Mission critical
  11. 11. datawire.io A single process is inefficient (Forces a single Stability vs Velocity Tradeoff) 11
  12. 12. datawire.io 12 Define Code Test Release Prod
  13. 13. datawire.io 13 Define Code Test Release Prod Centralized process ● Specialized teams ● Fixed policies (e.g., release criteria)
  14. 14. datawire.io A single process doesn’t scale 14
  15. 15. datawire.io How do I break up my monolith? How do I break up my process? 15
  16. 16. datawire.io 16 Microservices lets you run multiple processes!
  17. 17. datawire.io Microservices is a distributed development architecture workflow. 17
  18. 18. datawire.io 18 Stability/Maturity Velocity Prototype Production Mission critical ● How do I get to Continuous Deployment incrementally? ● How do I limit the scope of PCI (audit process)? ● How do I ship feature X as fast as possible?
  19. 19. datawire.io Microservices is ... ● Multiple workflows ○ Including your existing workflow! ○ Workflows designed for different stability/velocity tradeoffs ● Simultaneous workflows 19
  20. 20. datawire.io Doing things this way shifts how people operate! ● Requires both organizational and technical changes 20
  21. 21. datawire.io Organizational Implementation 21
  22. 22. datawire.io You gotta give in order to get 22 Education ● Everyone exposed to full dev cycle Communication ● Nobody speaks the same language Delegation ● Small teams own big important parts
  23. 23. datawire.io But you get a lot 23 Education ● Specialists become generalists -> Better holistic systems ● Learning, personal growth -> Job satisfaction Communication ● Conflict -> Collaboration Delegation ● Massive organizational scale
  24. 24. datawire.io Create self-sufficient, autonomous software teams. 24
  25. 25. datawire.io Why self-sufficiency and autonomy? ● Self-sufficient ○ Team does not need to rely on other teams to achieve its goals ● Autonomy ○ Team is able to independently make (process) decisions on how to achieve its goals 25
  26. 26. datawire.io Eliminate centralized specialist functions 26 Centralized architecture Centralized infrastructure / ops* (You might need a platform team)
  27. 27. datawire.io Think Spinoff 27
  28. 28. datawire.io 28 Monolith
  29. 29. datawire.io 29 Monolith Microservice Team
  30. 30. datawire.io Technical Implementation 30
  31. 31. datawire.io The Workflows 31 Prototype Production Users & Growth Mission CriticalStage Goals Fast Feedback from both Tools & Users Add Features & Don’t Disrupt Users Stability
  32. 32. datawire.io One Platform, Parallel Workflows, Seamless Transitions 32 Stage 1: Rapid development, early users Stage 2: Users Stage 3: Internal users, coupling Stage Goals 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, couplingPrototype Production Users & Growth Mission Critical Doesn’t crash... Minimal disruption to users... No cascade failures...Doesn’t crash... Minimal disruption to users... No cascade failures... Fast Feedback from both Tools & Users Add Features & Don’t Disrupt Users Stability
  33. 33. datawire.io Kubernetes / Docker / Envoy give you the infra you need 33
  34. 34. datawire.io How do I actually use these technologies to build my workflows? 34
  35. 35. datawire.io 35 Stage 1: Prototyping Org Problem: You need buy-in for prototyping in production Goal: Fast Feedback from both Tools and Users Tech Problem: You can’t run microservices locally
  36. 36. datawire.io 36 Strategy: Self Service Provisioning & Development Containers
  37. 37. datawire.io Make this fast and easy! ● Too much friction leads to accidental coupling Provide fast self-service provisioning 37
  38. 38. datawire.io Problem: Coding on remote infra is slow... VM based pipeline: ● Deploy time: maybe 45 minutes? Docker based pipeline: ● Deploy time: maybe a few minutes? Hacking react on my laptop with live reload: ● Maybe 1-2 seconds? Hacking flask on my laptop with live reload: ● Instantaneous 38
  39. 39. datawire.io How can we do better? 39
  40. 40. datawire.io Develop inside a container Helps with onboarding and jumping between services: ● Single source of truth for build & dependencies ● Consistent and portable dev environment You can make a faster feedback loop: 1. Sync local files -> remote build 2. Sync local files -> local build; snapshot image; deploy in seconds 3. Sync local files -> local build; proxy into remote cluster Shameless self promotion: ● See https://forge.sh for (2) and https://telepresence.io for (3) 40
  41. 41. datawire.io Fast Deploy == Resilience 41
  42. 42. datawire.io 42 Stage 2: Production Users & Growth Org Problems: Recognize the Tradeoff & How to measure user impact Goal: Add Features & Don’t Disrupt Users Tech Problem: Software Bugs
  43. 43. datawire.io 43 Strategy: Genetic Diversity (Multiversion Deployment)
  44. 44. datawire.io Multiple versions for software redundancy 44 End user Primary version Canary version Dev version
  45. 45. datawire.io 45 Stage 3: Mission Critical Org Problem: Avoid regressing Goal: Stability Tech Problem: L7 Observability
  46. 46. datawire.io 46 Strategy: Service Level Objectives & L7 Observability
  47. 47. datawire.io Cascade Failures 47 A B C D EX
  48. 48. datawire.io Summary 1. Start with: “How do I break up my monolithic process?” 2. Spinoff self sufficient & autonomous teams 3. Build awesome tooling for Service Oriented Development 48
  49. 49. datawire.io Thank you! ● rhs@datawire.io ● If you want to learn more about these ideas, check out our hands-on tutorial here: ○ https://datawire.io/faster ● If you’re interested in any of our open source tools, check them out: ○ https://forge.sh for deployment ○ https://www.telepresence.io for real-time live coding ○ https://www.getambassador.io self-service API Gateway built on Envoy 49
  50. 50. END

×