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.

Surviving in a Microservices Environment

304 views

Published on

Cloud Native Microservice architectures have become increasingly popular over the past few years, and for good reasons: smaller, efficient codebases, finely targeted scaling options, and the ability to do continuous deployment along with continuous integration, among others. All potentially very powerful features. However - as with most things - Microservices bring tradeoffs in terms of application complexity: working with an individual service is easy; overall application development becomes increasingly complex. Perhaps too complex for your average web application.

Many presentations on the Microservice phenomena offer either a high level view on what it is, compare and contrast it with the Monolith pattern, or discuss how to migrate from a Monolith to Microservices, but rarely does one hear what it’s like to actually work in such an environment. Frankly, it can be intimidating for someone accustomed to a traditional monolithic development experience. Individual services are somewhat trivial to develop, but now you suddenly have countless others to keep track of. You may become lost: with all these services, is anyone directing the overall development? You’ll become obsessed over how and when they communicate. You’ll have to start referring to the application on the whole as “the Platform”. It’ll soon become difficult or even impossible to run the whole Platform on a development laptop. You may even have to take on some DevOps work, and start learning about deployment pipelines, and whole new worlds of metrics and logging.

Don’t panic. In this presentation we’ll discuss what we learned working with a Microservice platform for the past three years. We’ll cover what to expect when joining a Microservice team and what the situation will look like as the team size grows. We’ll see how critical inter-service testing strategies are to the success of the team. We’ll examine what a development lifecycle might look like for adding a new service, developing a new feature, or fixing bugs. We’ll dive a bit into DevOps and see how one will become dependent and various metric and centralized logging tools, like Kubernetes and the ELK stack. Finally we’ll talk about communication, team organization strategies, and how they are likely the most important tool for surviving a Microservices development team.

Published in: Technology
  • Be the first to comment

Surviving in a Microservices Environment

  1. 1. Surviving In A Microservices Environment Steve Pember CTO, ThirdChannel @svpember
  2. 2. @spring_io #springio17 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. @spring_io #springio17 WHAT EVEN ARE MICROSERVICES?
  5. 5. @spring_io #springio17 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. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
  8. 8. @spring_io #springio17 Microservice Topics • Infrastructure
  9. 9. @spring_io #springio17 Infrastructure • How do we manage the logs?
  10. 10. @spring_io #springio17 CENTRALIZED LOGS ARE YOUR #1 PRIORITY
  11. 11. @spring_io #springio17
  12. 12. @spring_io #springio17
  13. 13. @spring_io #springio17
  14. 14. @spring_io #springio17
  15. 15. @spring_io #springio17 Infrastructure • How do we manage the logs? • How about metrics / telemetry?
  16. 16. @spring_io #springio17 YOU’D BEST BE MONITORING YOUR PLATFORM.
  17. 17. @spring_io #springio17
  18. 18. @spring_io #springio17 Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code?
  19. 19. @spring_io #springio17 Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code? • How/where are our builds done?
  20. 20. @spring_io #springio17
  21. 21. @spring_io #springio17 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?
  22. 22. @spring_io #springio17 CHECK STYLE? COVERAGE?
  23. 23. @spring_io #springio17
  24. 24. @spring_io #springio17
  25. 25. @spring_io #springio17 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?
  26. 26. @spring_io #springio17 WGET HTTPS://GITHUB.COM/THIRDCHANNEL/SPRING-BOOT-BASE- TEMPLATE/ARCHIVE/RELEASE.ZIP (THIS IS NOT A REAL URL, BUT YOU GET THE IDEA)
  27. 27. @spring_io #springio17 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?
  28. 28. @spring_io #springio17 OOPS! GOTCHA!
  29. 29. @spring_io #springio17 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
  30. 30. @spring_io #springio17 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?
  31. 31. @spring_io #springio17
  32. 32. @spring_io #springio17 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?
  33. 33. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture
  34. 34. @spring_io #springio17 Architecture • Do we have an overall design vision?
  35. 35. @spring_io #springio17 DOES ANYONE KNOW WHAT WE’RE DOING?!
  36. 36. @spring_io #springio17 Architecture • Do we have an overall design vision? • What technologies do we use? • How much freedom do we have in choosing new technologies?
  37. 37. @spring_io #springio17
  38. 38. @spring_io #springio17
  39. 39. @spring_io #springio17 BE CAREFUL WHEN CHOOSING NEW TECH
  40. 40. @spring_io #springio17 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?
  41. 41. INTEGRATION TESTS ARE THE BEST TESTS
  42. 42. @spring_io #springio17 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?
  43. 43. @spring_io #springio17 Test Environment • Run periodically (e.g. nightly) • Each service generates fixture data • Service data reset after EACH test
  44. 44. @spring_io #springio17 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?
  45. 45. @spring_io #springio17 HTTP VS ASYNC EVENTS
  46. 46. @spring_io #springio17 HTTP • Well Established • Built In libraries / Easy to get started • 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
  47. 47. @spring_io #springio17 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
  48. 48. @spring_io #springio17 ENSURE YOU HAVE CIRCUIT BREAKER OR A DEAD LETTER MECHANISM
  49. 49. @spring_io #springio17 <3 RabbitMq • It’s from Pivotal! • Intelligent broker; dumb consumers • Highly nuanced & robust routing • Backpressure • Dead letters /retries • Message Ordering • Multiple deliveries • Ack / Nack/ Reject … re-enqueue?
  50. 50. @spring_io #springio17
  51. 51. @spring_io #springio17 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?
  52. 52. @spring_io #springio17 Date Locality of Reference • Spatial: “How close together is our data?”
  53. 53. @spring_io #springio17 Data Locality of Reference • Spatial: “How close together is our data?” • Temporal: “How often is our data accessed?”
  54. 54. @spring_io #springio17
  55. 55. @spring_io #springio17
  56. 56. @spring_io #springio17 BEWARE THE ‘MINI-MONOLITH’
  57. 57. @spring_io #springio17 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?
  58. 58. @spring_io #springio17 MAKE SURE EVERYONE IS AWARE
  59. 59. @spring_io #springio17 APPLIES TO BOTH INTRA- AND INTER-SERVICE
  60. 60. IT ALL STARTED WITH ^
  61. 61. @spring_io #springio17 Domain Driven Design • Ubiquitous Language • Entities • Aggregates • Bounded Contexts • No Direct communications across Boundaries
  62. 62. @spring_io #springio17
  63. 63. @spring_io #springio17 … AND CQRS
  64. 64. @spring_io #springio17 ALLOWS FOR INTERESTING ARCHITECTURES
  65. 65. @spring_io #springio17 WHILE WE’RE AT IT, GO REACTIVE
  66. 66. @spring_io #springio17
  67. 67. @spring_io #springio17 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?
  68. 68. @spring_io #springio17 DDD TO THE RESCUE
  69. 69. @spring_io #springio17 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
  70. 70. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture • Team Communication
  71. 71. @spring_io #springio17 Team Communication • How are our teams structured?
  72. 72. @spring_io #springio17 CONWAY’S LAW IS REAL
  73. 73. @spring_io #springio17 DBA Engineers QA UX
  74. 74. @spring_io #springio17 Team Communication • How are our teams structured? • Who owns which Service?
  75. 75. @spring_io #springio17 TEAMS SHOULD BE OWNERS
  76. 76. @spring_io #springio17 Team Communication • How are our teams structured? • Who owns which Service? • What’s our process for merging code?
  77. 77. @spring_io #springio17 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?
  78. 78. @spring_io #springio17 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?
  79. 79. @spring_io #springio17 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?
  80. 80. @spring_io #springio17 BE RELUCTANT TO ADD NEW PROCESS
  81. 81. @spring_io #springio17 HIGH FREEDOM / HIGH RESPONSIBILITY
  82. 82. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
  83. 83. @spring_io #springio17 Miscellaneous Advice • Don’t get cute with the naming of services
  84. 84. ANY IDEA WHAT THESE DO?
  85. 85. @spring_io #springio17 Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see
  86. 86. @spring_io #springio17 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
  87. 87. @spring_io #springio17 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
  88. 88. @spring_io #springio17 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?
  89. 89. @spring_io #springio17 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
  90. 90. @spring_io #springio17 IN SUMMARY
  91. 91. @spring_io #springio17 MOST OF THE CHALLENGE IS IN INFRASTRUCTURE
  92. 92. <3 MICROSERVICES
  93. 93. @spring_io #springio17 PLEASE SHARE YOUR SURVIVAL TIPS!
  94. 94. @spring_io #springio17 ANY QUESTIONS? ANYTHING I MISSED?
  95. 95. Thank you!
  96. 96. @spring_io #springio17 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 • 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/ • Pipeline: http://debatepost.com/2017/04/14/keystone-pipeline-final-decision-to-be-announced/
  97. 97. @spring_io #springio17 Links • Eric Evans: DDD for Microservices: https://www.youtube.com/watch?v=yPvef9R3k-M

×