Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Greach 2018: Surviving Microservices

517 vues

Publié le

Many presentations on Microservices offer a high level view; rarely does one hear what it’s like to work in such an environment. Individual services are somewhat trivial to develop, but now you suddenly have countless others to track. You’ll become obsessed over how they communicate. You’ll have to start referring to the whole thing as “the Platform”. You will have to take on some DevOps work and start learning about deployment pipelines, metrics, and logging.

Don’t panic. In this presentation we’ll discuss what we, at ThirdChannel, learned over the past four years. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent on various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about team communication and organization… and how they are likely the most important tool for surviving a Microservices development team.

Publié dans : Technologie
  • Soyez le premier à commenter

Greach 2018: Surviving Microservices

  1. 1. Surviving In A Microservices Environment Steve Pember CTO, ThirdChannel Greach, 2018 @svpember
  2. 2. @svpember Microservice Blog Posts & Presentations • Microservices: Yay! • Microservices: Boo! • Smashing The Monolith (and here’s how we did it) • Microservices + Technology X • Microservices + Methodology Y
  3. 3. Microservices have many lessons to offer
  4. 4. What even are Microservices?
  5. 5. @svpember Why Choose Microservices? • Reduce Coupling! • 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. @svpember Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
  8. 8. @svpember Microservice Topics • Infrastructure
  9. 9. @svpember Infrastructure • How do we manage the logs?
  10. 10. Centralized Logs are your #1 Priority
  11. 11. @svpember
  12. 12. @svpember
  13. 13. @svpember
  14. 14. @svpember
  15. 15. @svpember
  16. 16. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry?
  17. 17. You’d best be monitoring your platform.
  18. 18. –Johnny Appleseed “Type a quote here.”
  19. 19. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code?
  20. 20. @svpember
  21. 21. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done?
  22. 22. @svpember
  23. 23. @svpember
  24. 24. @svpember
  25. 25. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done? • Do we have any coding conventions?
  26. 26. Check Style? Coverage?
  27. 27. @svpember
  28. 28. @svpember
  29. 29. @svpember
  30. 30. @svpember
  31. 31. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done? • Do we have any coding conventions? • Can I generate a Service template?
  32. 32. wget https://github.com/thirdchannel/base-template/ archive/release.zip (This is not a real url, but you get the idea)
  33. 33. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done? • Do we have any coding conventions? • Can I generate a Service template? • How do we share code?
  34. 34. Whoops! Gotcha!
  35. 35. @svpember Sharing Code • It’s OK to reimplement functionality within each service • Setup your own internal Artifactory! • DO share infrastructure libraries (e.g. communications) • NEVER share Domain or business logic libraries
  36. 36. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done? • Do we have any coding conventions? • Can I generate a Service template? • How do we share code? • How do we manage our (multiple) environments?
  37. 37. @svpember
  38. 38. Test & Develop in Isolation
  39. 39. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done? • Do we have any coding conventions? • Can I generate a Service template? • How do we share code? • How do we manage our (multiple) environments? • Do our Devs get time to work on Infrastructure?
  40. 40. @svpember Microservice Topics • Infrastructure • Architecture
  41. 41. @svpember Architecture • Do we have an overall design vision?
  42. 42. Does Anyone Know What We’re Doing?!
  43. 43. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies?
  44. 44. @svpember
  45. 45. @svpember
  46. 46. Be Careful When Choosing New Tech
  47. 47. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies? • How do we test an individual service?
  48. 48. Integration Tests are the Best Tests
  49. 49. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies? • How do we test an individual service? • How do we test the platform as a whole?
  50. 50. @svpember Test Environment • Run periodically (e.g. nightly) • Each service generates fixture data • Service data reset after EACH test
  51. 51. Consider NOT testing platform Instead, monitor error rates
  52. 52. @svpember
  53. 53. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies? • How do we test an individual service? • How do we test the platform as a whole? • How do our services communicate?
  54. 54. HTTP vs Async Events
  55. 55. @svpember HTTP • Well Established • Built In libraries • Existing structure for response codes (2**, 4**, 5**, etc) • Synchronous • Increases coupling • Requires services to know which others require their data • Has dependency on Service Discovery mechanism • Susceptible to Data Loss
  56. 56. @svpember Events • Asynchronous • Pub-sub / Fire and forget • Loose Coupling • Prevents Data Loss • Allows for Reactive systems • No existing structure for response error handling • Dependency on Message Broker technology • Can be difficult for Junior folks to understand
  57. 57. Ensure you have Circuit Breaker or a Dead Letter Mechanism
  58. 58. @svpember
  59. 59. @svpember <3 RabbitMq • Intelligent broker; dumb consumers • Highly nuanced & robust routing • Backpressure • Dead letters /retries • Message Ordering • Multiple deliveries • Ack / Nack/ Reject … re-enqueue
  60. 60. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies? • How do we test an individual service? • How do we test the platform as a whole? • How do our services communicate? • How/where is our data persisted?
  61. 61. @svpember Locality of Reference • Spatial: “How close together is our data?”
  62. 62. @svpember Locality of Reference • Spatial: “How close together is our data?” • Temporal: “How often is our data accessed?”
  63. 63. @svpember
  64. 64. @svpember
  65. 65. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies? • How do we test an individual service? • How do we test the platform as a whole? • How do our services communicate? • How/where is our data persisted? • Do we follow an overall architectural style?
  66. 66. Make Sure Everyone Is Aware
  67. 67. Applies to Both Intra- and Inter-Service
  68. 68. It all Started With =>
  69. 69. @svpember Domain Driven Design • Ubiquitous Language • Entities • Aggregates • Bounded Contexts • No Direct communications across Boundaries
  70. 70. @svpember
  71. 71. @svpember
  72. 72. … And CQRS
  73. 73. Allows for interesting Architectures
  74. 74. MVC
  75. 75. CQRS
  76. 76. CQRS
  77. 77. While we’re at it, go Reactive
  78. 78. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies? • How do we test an individual service? • How do we test the platform as a whole? • How do our services communicate? • How/where is our data persisted? • Do we follow an overall architectural style? • When do we create new services?
  79. 79. DDD to the rescue
  80. 80. @svpember New Service? • Initially: design platform around Bounded Contexts, create services from inner Contexts • Don’t create services ‘just because’ • Do make an effort to identify boundaries • Ensure a service has/will have proper context boundaries before creating • If two services need to communicate synchronously or frequently, good candidates for MERGING
  81. 81. # of services < # of developers
  82. 82. @svpember Microservice Topics • Infrastructure • Architecture • Team Communication
  83. 83. @svpember Team Communication • How are our teams structured?
  84. 84. Conway’s Law is REAL
  85. 85. –Johnny Appleseed “Type a quote here.” DBA Engineers QA UX
  86. 86. @svpember
  87. 87. @svpember Team Communication • How are our teams structured? • Who owns which Service?
  88. 88. Teams should be Owners
  89. 89. @svpember Team Communication • How are our teams structured? • Who owns which Service? • What’s our process for merging code?
  90. 90. @svpember Team Communication • How are our teams structured? • Who owns which Service? • What’s our process for merging code? • What’s our process for releasing code?
  91. 91. @svpember
  92. 92. @svpember Team Communication • How are our teams structured? • Who owns which Service? • What’s our process for merging code? • What’s our process for releasing code? • What’s our process for monitoring code in production? Dealing with bugs?
  93. 93. @svpember
  94. 94. –Johnny Appleseed “Type a quote here.”
  95. 95. @svpember Team Communication • How are our teams structured? • Who owns which Service? • What’s our process for merging code? • What’s our process for releasing code? • What’s our process for monitoring code in production? Dealing with bugs? • Do we add more process if something goes wrong?
  96. 96. Be Reluctant to Add New Process
  97. 97. High Freedom / High Responsibility
  98. 98. @svpember Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
  99. 99. @svpember Miscellaneous Advice • Don’t get cute with the naming of services
  100. 100. Any idea what these do?
  101. 101. @svpember Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see
  102. 102. @svpember Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see • Release when a feature is ready
  103. 103. @svpember Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see • Release when a feature is ready • If a service A has another service B as a dependency => release B first
  104. 104. @svpember Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see • Release when a feature is ready • If a service A has another service B as a dependency => release B first • How to bootstrap a new service?
  105. 105. @svpember Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see • Release when a feature is ready • If a service A has another service B as a dependency => release B first • How to bootstrap a new service? • Don’t release Friday afternoons
  106. 106. In Summary
  107. 107. Most of the Challenge is In infrastructure
  108. 108. <3 Microservices
  109. 109. Please share your survival tips!
  110. 110. Any Questions? Anything I missed?
  111. 111. Thank you! @svpember
  112. 112. @svpember Images • Bad Odds (Jon Snow): https://www.reddit.com/r/gameofthrones/comments/4owm95/s6e9_megathread_gifwallpaperscreenshot_requests/ • 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 • Picard FacePalm: https://www.flickr.com/photos/30418788@N03/8381426895 • Council of Ricks: https://www.reddit.com/r/rickandmorty/comments/3exy00/it_looks_like_there_might_some_sort_of_council_of/ • Drago (break you): https://giphy.com/gifs/GWD5nSpiHxs3K • Wrecking Ball: https://www.flickr.com/photos/rhysasplundh/5202454842/in/photostream/ • Rocky Stairs: http://pixgood.com/rocky-stairs.html • Technical Difficulties: https://www.youtube.com/watch?v=EC15BmzsdhM • Grafana example: https://i.imgur.com/KOqcD6L.png • Zipkin example: https://blog.buoyant.io/2016/05/17/distributed-tracing-for-polyglot-microservices/ • Assembly Line: http://www.solidsmack.com/culture/humans-need-apply-new-short-film-explores-future-robots-manufacturing-automation/
  113. 113. @svpember Links • Eric Evans: DDD and Microservices: https://www.youtube.com/watch? v=yPvef9R3k-M

×