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.

Surviving in a Microservices environment -abridged

163 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 considerable DevOps work and start learning about deployment pipelines, metrics, and logging.

Don’t panic. In this presentation we’ll discuss what we learned over the past four years by highlighting our mistakes. We’ll examine what a development lifecycle might look like for adding a new service, developing a feature, or fixing bugs. We’ll see how team communication is more important than one might realize. Most importantly, we’ll show how - while an individual service is simple - the infrastructure demands are now much more complicated: your organization will need to introduce and become increasingly dependent on various technologies, procedures, and tools - ranging from the ELK stack to Grafana to Kubernetes. Lastly, you’ll come away with the understanding that your resident SREs will become the most valued members of your team.

Publié dans : Technologie
  • Soyez le premier à commenter

Surviving in a Microservices environment -abridged

  1. 1. Surviving In A Microservices Environment Steve Pember DevOps Days, Boston 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. Writing a Microservice is EASY. Operating a Microservices platform is HARD
  10. 10. @svpember Infrastructure • How do we manage the logs?
  11. 11. Centralized Logs are your #1 Priority
  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. Your Infrastructure Needs to Scale Along With Your Application
  20. 20. Your Infrastructure Needs to Scale Along With Your Application
  21. 21. @svpember
  22. 22. –Johnny Appleseed “Type a quote here.”
  23. 23. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How/where are our builds done?
  24. 24. @svpember
  25. 25. @svpember
  26. 26. @svpember
  27. 27. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How/where are our builds done? • How do we deploy our code?
  28. 28. @svpember
  29. 29. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How/where are our builds done? • How do we deploy our code? • Do we have any coding conventions?
  30. 30. Check Style? Coverage?
  31. 31. @svpember
  32. 32. @svpember
  33. 33. @svpember
  34. 34. @svpember
  35. 35. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How/where are our builds done? • How do we deploy our code? • Do we have any coding conventions? • Can I generate a Service template?
  36. 36. wget https://github.com/klaviyo/base-template/archive/ release.zip (This is not a real url, but you get the idea)
  37. 37. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How/where are our builds done? • How do we deploy our code? • Do we have any coding conventions? • Can I generate a Service template? • How do we share code?
  38. 38. Whoops! Gotcha!
  39. 39. @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 business logic • NEVER share Domain objects, Models
  40. 40. @svpember Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How/where are our builds done? • How do we deploy our code? • Do we have any coding conventions? • Can I generate a Service template? • How do we share code? • How do we manage our (multiple) environments?
  41. 41. @svpember
  42. 42. @svpember
  43. 43. Test & Develop in Isolation
  44. 44. @svpember
  45. 45. @svpember
  46. 46. @svpember
  47. 47. @svpember
  48. 48. @svpember
  49. 49. @svpember Fail
  50. 50. @svpember Fail
  51. 51. @svpember Success
  52. 52. @svpember Success
  53. 53. @svpember Microservice Topics • Infrastructure • Architecture
  54. 54. @svpember Architecture • Do we have an overall design vision?
  55. 55. Does Anyone Know What We’re Doing?!
  56. 56. @svpember Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies?
  57. 57. @svpember
  58. 58. @svpember
  59. 59. Be Careful When Choosing New Tech
  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?
  61. 61. Integration Tests are the Best Tests
  62. 62. @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?
  63. 63. @svpember Test Environment • Run periodically (e.g. nightly) • Each service generates fixture data • Service data reset after EACH test
  64. 64. Consider NOT testing platform Instead, monitor error rates
  65. 65. @svpember
  66. 66. @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?
  67. 67. HTTP vs Async Events
  68. 68. Ensure you have Circuit Breaker or a Dead Letter Mechanism
  69. 69. @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? • Do we follow an overall architectural style?
  70. 70. Make Sure Everyone Is Aware
  71. 71. Applies to Both Intra- and Inter- Service
  72. 72. Everyone needs to read =>
  73. 73. @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? • Do we follow an overall architectural style? • When do we create new services?
  74. 74. @svpember New Service? • Initially: design platform around Bounded Contexts, create services from inner Contexts • Don’t create services ‘just because’ • Don’t create services that are basically CRUD-wrappers • 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
  75. 75. # of services < # of developers
  76. 76. @svpember Microservice Topics • Infrastructure • Architecture • Team Communication
  77. 77. Conway’s Law is REAL
  78. 78. @svpember Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
  79. 79. @svpember Miscellaneous Advice • Don’t get cute with the naming of services
  80. 80. Any idea what these do?
  81. 81. @svpember Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see
  82. 82. @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, but don’t be afraid of bugs
  83. 83. @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, but don’t be afraid of bugs • If a service A has another service B as a dependency => release B first
  84. 84. @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, but don’t be afraid of bugs • If a service A has another service B as a dependency => release B first • How to bootstrap a new service?
  85. 85. @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, but don’t be afraid of bugs • If a service A has another service B as a dependency => release B first • How to bootstrap a new service? • API or Message Versioning is just.. blech.. a Big Thing
  86. 86. @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, but don’t be afraid of bugs • If a service A has another service B as a dependency => release B first • How to bootstrap a new service? • API or Message Versioning is just.. blech.. a Big Thing • Don’t release Friday afternoons
  87. 87. In Summary
  88. 88. Most of the Challenge is In infrastructure
  89. 89. <3 Microservices
  90. 90. Please share your survival tips! @svpember
  91. 91. Thank you! @svpember
  92. 92. @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/ • Site Reliability Engineer Shirt: https://www.sunfrog.com/102539321-160396457.html • Watson, “Wait”: https://giphy.com/gifs/B8qMV3f7PH7nq •
  93. 93. @svpember Links • Eric Evans: DDD and Microservices: https://www.youtube.com/watch? v=yPvef9R3k-M •

×