Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

SACon 2019 - Surviving in a Microservices Environment

89 Aufrufe

Veröffentlicht am

Many presentations on microservices offer a high-level view of the architecture; rarely do you hear what it’s like to work in such an environment. Stephen Pember shares his experience migrating from a monolith to microservices across several companies, highlighting the mistakes made along the way and offering advice.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

SACon 2019 - Surviving in a Microservices Environment

  1. 1. Surviving In A Microservices Environment Steve Pember Principal Engineer @ Toast Software Architecture Conf, San Jose, 2019 @svpember
  2. 2. @svpember Microservice Blog Posts & Presentations
  3. 3. <3
  4. 4. What Are Microservices?
  5. 5. @svpember Why Choose Microservices? • Reduce Coupling! • Team Autonomy • Forced Boundaries between Functional Areas • Right Tool for the Job • Continuous Delivery • Smaller codebases are easier to reason about • Easy to replace old services • Efficient Scaling • Can move quickly (once you’re up and running)
  6. 6. Help?
  7. 7. This talk is not a Good Talk.
  8. 8. Please let me know if I missed anything
  9. 9. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations • Architecture • Developer Productivity / Happiness • People Communication • Breaking off from the Monolith • Random
  10. 10. @svpember Topics • Is it time for Microservices?
  11. 11. @svpember Is it time for Microservices? • … is it?
  12. 12. Not before 8 Engineers. After You have known Defined Functional Areas.
  13. 13. You may not be ready, and that’s OK.
  14. 14. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations
  15. 15. One Microservice is Easy One Microservice Platform is HARD
  16. 16. @svpember Infrastructure / Operations • Do we have Centralized Logging?
  17. 17. Centralized Log Aggregation is Critical to Success
  18. 18. @svpember
  19. 19. @svpember
  20. 20. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics?
  21. 21. @svpember
  22. 22. Your Infrastructure needs to Scale along with your Platform
  23. 23. Your Infrastructure needs to Scale along with your Platform
  24. 24. @svpember
  25. 25. –Johnny Appleseed “Type a quote here.”
  26. 26. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics? • How are our builds performed?
  27. 27. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics? • How are our builds performed? • When are our builds performed?
  28. 28. Continuous Integration!
  29. 29. Frequent merging provides fast feedback. Faster Iterations.
  30. 30. CI should be run on each ‘main’ branch and PR commit
  31. 31. CI should produce some correct Artifact
  32. 32. @svpember
  33. 33. @svpember
  34. 34. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics? • How are our builds performed? • When are our builds performed? • Can our CI keep up with the the team’s build demand?
  35. 35. @svpember
  36. 36. @svpember
  37. 37. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics? • How are our builds performed? • When are our builds performed? • Can our CI keep up with the the team’s build demand? • Do we have any coding conventions or quality gates?
  38. 38. @svpember
  39. 39. @svpember
  40. 40. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics? • How are our builds performed? • When are our builds performed? • Can our CI keep up with the the team’s build demand? • Do we have any coding conventions or quality gates? • How are our services deployed?
  41. 41. Continuous Deployment is your Ultimate Goal
  42. 42. A Certain level of Operational-Readiness is required
  43. 43. @svpember
  44. 44. @svpember
  45. 45. @svpember Service Mesh • Likely don’t need in a small org with few services / Essential as you grow • Aids in resiliency, can reroute traffic around failing nodes • App Devs focus on building services vs wiring them up • Sidecars can handle metric, log collection and auth between services • Easy Canary Deploys
  46. 46. @svpember Infrastructure / Operations • Do we have Centralized Logging? • What do we use for Metrics? • How are our builds performed? • When are our builds performed? • Can our CI keep up with the the team’s build demand? • Do we have any coding conventions or quality gates? • How are our services deployed? • Do we have multiple environments? How are our environments managed?
  47. 47. @svpember
  48. 48. Goal: standup a new environment with a single command
  49. 49. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations • Architecture
  50. 50. @svpember Architecture • Do we have an overall design vision?
  51. 51. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them?
  52. 52. Right Tool for the Job!
  53. 53. @svpember
  54. 54. Be wary of new adopting new technology
  55. 55. Boring is Good
  56. 56. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them? • How do we share code between services?
  57. 57. Shared Code can increase coupling and decrease Autonomy
  58. 58. @svpember Shared code? • Internal Commons (e.g. a custom String Utils) - OK! • Styling, CSS - Go for it! • Business Logic - You’re gonna have a bad time • Domain Objects - Never!
  59. 59. @svpember
  60. 60. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them? • How do we share code between services? • How do we test an individual service?
  61. 61. Integration tests are the best tests
  62. 62. @svpember
  63. 63. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them? • How do we share code between services? • How do we test an individual service? • How do we test the platform as a whole?
  64. 64. @svpember End-to-End tests are Difficult 1. Reset fixture / default state data on each service’s datastore 2. Execute test by performing some user action at the edge 3. Wait for test to complete 4. Make assertions on each service (e.g. look out for unknown side effects) 5. Repeat
  65. 65. Consider… Not doing that.
  66. 66. @svpember
  67. 67. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them? • How do we share code between services? • How do we test an individual service? • How do we test the platform as a whole? • Overall architectural style for services?
  68. 68. Are there common, repeatable, patterns?
  69. 69. Does everyone in the org know?
  70. 70. Asynchronous, Event Driven Communications + Domain Driven Design
  71. 71. 1) Async Comms
  72. 72. Services that communicate Synchronously are a Distributed Monolith
  73. 73. @svpember
  74. 74. @svpember
  75. 75. Embrace Eventual Consistency
  76. 76. @svpember
  77. 77. @svpember
  78. 78. Decoupled Services allow for team Autonomy
  79. 79. Decoupled Services scale easily and efficiently
  80. 80. @svpember
  81. 81. @svpember
  82. 82. –Johnny Appleseed “Type a quote here.” Source: https://dzone.com/articles/distributed-sagas-for-microservices
  83. 83. 2) Domain Driven Design
  84. 84. Please Read =>
  85. 85. And also =>
  86. 86. @svpember Some DDD concepts • Ubiquitous Language • Entities • Aggregates • Bounded Contexts • No Direct communications across Boundaries, communicate through some single point of contact
  87. 87. @svpember
  88. 88. One Last Thing: Always have a way to recover
  89. 89. @svpember
  90. 90. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them? • How do we share code between services? • How do we test an individual service? • How do we test the platform as a whole? • Overall architectural style for services? • When do we decide to create new services?
  91. 91. @svpember New Service? • Don’t make services ‘just because’ • Don’t make CRUD services • Look for places where Eventual Consistency is acceptable • A service should be thought as wrapping some functional business logic, not the domain objects inside of it • When new functionality is proposed: does it fall within the responsibilities of an existing service?
  92. 92. # of services < # of developers
  93. 93. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? How much freedom do we have in choosing them? • How do we share code between services? • How do we test an individual service? • How do we test the platform as a whole? • Overall architectural style for a service? • When do we decide to create new services? • How do we bootstrap a new service?
  94. 94. An Event Log makes this trivial
  95. 95. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations • Architecture • Developer Productivity / Happiness
  96. 96. @svpember Developer Productivity / Happiness • Do we have a service template?
  97. 97. git clone git@github.com: your_org/services-template.git
  98. 98. @svpember Developer Productivity / Happiness • Do we have a service template? • What does it take to run our services?
  99. 99. What’s our Developer experience like?
  100. 100. Running the Monolith on your laptop will eventually become problematic
  101. 101. Running a single Microservice is easy. Running all of them is impossible.
  102. 102. @svpember Developing against other Services 1. Every team publishes a mock service along with the real service 2. Only run services you need at the time 3. On-demand Environments 4. Keep buying bigger laptops
  103. 103. @svpember
  104. 104. @svpember Developer Productivity / Happiness • Do we have a service template? • What does it take to run our services? • Do our Engineers know how our services are deployed?
  105. 105. Let App Devs App Dev
  106. 106. @svpember Developer Productivity / Happiness • Do we have a service template? • What does it take to run our services? • Do our Engineers know how our services are deployed? • How do our Engineers know about other Services?
  107. 107. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations • Architecture • Developer Productivity / Happiness • People Communication
  108. 108. Conway’s Law is Real
  109. 109. People are the reason for Microservices
  110. 110. @svpember People Communication • How large are our teams?
  111. 111. @svpember
  112. 112. @svpember
  113. 113. @svpember
  114. 114. @svpember
  115. 115. Team larger than 4? Break them up
  116. 116. @svpember
  117. 117. @svpember People Communication • How large are our teams? • How are they structured?
  118. 118. @svpember People Communication • How large are our teams? • How are they structured? • Are there clear functional boundaries between teams?
  119. 119. @svpember People Communication • How large are our teams? • How are they structured? • Are there clear functional boundaries between teams? • Do we encourage cross-team socializing?
  120. 120. @svpember People Communication • How large are our teams? • How are they structured? • Are there clear functional boundaries between teams? • Do we encourage cross-team socializing? • Do we have clear methods for engineers to share & publicize services they’ve built?
  121. 121. @svpember People Communication • How large are our teams? • How are they structured? • Are there clear functional boundaries between teams? • Do we encourage cross-team socializing? • Do we have clear methods for engineers to share & publicize services they’ve built? • Do we add more process if something goes wrong?
  122. 122. Process is like Scar Tissue
  123. 123. @svpember People Communication • How large are our teams? • How are they structured? • Are there clear functional boundaries between teams? • Do we encourage cross-team socializing? • Do we have clear methods for engineers to share & publicize services they’ve built? • Do we add more process if something goes wrong? • Do we have company ‘Core Values’? Do they include non-technical skills?
  124. 124. Empathy should be your #1 Core Value
  125. 125. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations • Architecture • Developer Productivity / Happiness • People Communication • Breaking off from the Monolith
  126. 126. @svpember Breaking off from the Monolith • Do we have a process / guideline for breaking functionality out of the monolith?
  127. 127. @svpember Breaking off from the Monolith • Do we have a process / guideline for breaking functionality out of the monolith? • Do we have a process / guideline for new services to interact w/ the monolith?
  128. 128. @svpember Breaking off from the Monolith • Do we have a process / guideline for breaking functionality out of the monolith? • Do we have a process / guideline for new services to interact w/ the monolith? • So… how much functionality have we actually split off?
  129. 129. @svpember Breaking off from the Monolith • Do we have a process / guideline for breaking functionality out of the monolith? • Do we have a process / guideline for new services to interact w/ the monolith? • So… how much functionality have we actually split off? • How’s the monolith doing?
  130. 130. All of your dependent systems need to scale to meet the demands of your services
  131. 131. @svpember
  132. 132. @svpember Slicing code from the Monolith • Not that straightforward! • Create programmatic boundaries around the departing code • Measure traffic and operational load across those boundaries • Any dependencies on original system? • Has the monolith accounted for the backpressure from the new service? • Roll out slowly • How are the metrics looking?
  133. 133. The First Service will be HARD
  134. 134. Beware Being the First
  135. 135. @svpember Topics • Is it time for Microservices? • Infrastructure / Operations • Architecture • Developer Productivity / Happiness • People Communication • Breaking off from the Monolith • Random
  136. 136. @svpember Random Advice • API & Message versioning is a real issue
  137. 137. @svpember Random Advice • API & Message versioning is a real issue • Always have more than one cluster
  138. 138. @svpember Random Advice • API & Message versioning is a real issue • Always have more than one cluster • Don’t get cute with the naming of services
  139. 139. Any idea what these do?
  140. 140. @svpember Random Advice • API & Message versioning is a real issue • Always have more than one cluster • Don’t get cute with the naming of services • New Feature? Walk backwards from the End User UI
  141. 141. Be Customer Focused
  142. 142. @svpember Random Advice • API & Message versioning is a real issue • Always have more than one cluster • Don’t get cute with the naming of services • New Feature? Walk backwards from the End User UI • Release when a feature is ready, don’t be afraid of bugs
  143. 143. @svpember Random Advice • API & Message versioning is a real issue • Always have more than one cluster • Don’t get cute with the naming of services • New Feature? Walk backwards from the End User UI • Release when a feature is ready, don’t be afraid of bugs • But don’t release Friday afternoon.
  144. 144. To Summarize:
  145. 145. Microservices are hard because of Infrastructure and People
  146. 146. Thank you! @svpember
  147. 147. @svpember Images • Factory Workers: https://www.stallardkaneassociates.com/hr-employment-law/factory-workers/ • Bad Demolition: https://media.giphy.com/media/zf3skxc4BFBqo/giphy.mp4 • Tom Hanks, Desert: http://www.trbimg.com/img-57ba8bc0/turbine/sdut-lost-in-the-desert-waiting-for-the-king-2016apr21 • Say Anything / John Cusak: http://www.glamour.com/story/happy-birthday-john-cusack-and • Wilderness Survival Guide: https://www.kobo.com/us/en/ebook/the-wilderness-survival-guide-1 • XKCD: Code Review: https://xkcd.com/1513/ • Monolithic vs Microservices: @alvaro_sanchez • Drago (break you): https://giphy.com/gifs/GWD5nSpiHxs3K • Michael Jackson, Bad: https://www.imdb.com/title/tt0124288/mediaviewer/rm4118942720 • Rocky Stairs: http://pixgood.com/rocky-stairs.html • Assembly Line: http://www.solidsmack.com/culture/humans-need-apply-new-short-film-explores-future-robots-manufacturing-automation/ • Site Reliability Engineer Shirt: https://www.sunfrog.com/102539321-160396457.html • Watson, “Wait”: https://giphy.com/gifs/B8qMV3f7PH7nq • Service Mesh: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh • Trick question: https://media.giphy.com/media/ZcaSXPd7di8O4ZfsnH/giphy.mp4 • Dumpster fire: https://sentinelksmo.org/lawmakers-spark-dumpster-fire-with-tax-school-funding-bill/shutterstock_49161094/ • Work meeting: https://pxhere.com/en/photo/910324 • People in Conversation: https://preply.com/en/blog/2018/07/06/5-main-principles-of-small-talk/ • Indiana Jones: https://giphy.com/explore/indiana-jones-and-the-raiders-of-the-lost-ark • Simpsons Mob: https://www.bobleesays.com/2017/06/18/halt-angry-fan-mob/ • Picard: https://fanfilmfactor.com/2019/03/07/the-right-captain-at-the-right-time-why-we-like-pike-discovery-editorial/ • Megaphone: https://imgflip.com/i/332n0j
  148. 148. @svpember Links • Eric Evans: DDD and Microservices: https://www.youtube.com/watch? v=yPvef9R3k-M •

×