Surviving In A Microservices Environment
•
2 gostaram•659 visualizações
The document discusses various topics related to surviving in a microservices environment. It addresses questions around infrastructure, architecture, team communication and provides advice. Key points include the importance of centralized logging and monitoring, avoiding tight coupling between services, ensuring an overall architectural vision, and being reluctant to add new process unless something goes wrong. The document emphasizes that most of the challenge with microservices is in infrastructure.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Surviving In A Microservices Environment
Semelhante a Surviving In A Microservices Environment (20)
Mais de Steve Pember
Mais de Steve Pember (20)
Último
Último (20)
Surviving In A Microservices Environment
- 1. Surviving In A Microservices Environment Steve Pember CTO, ThirdChannel @svpember
- 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. MICROSERVICES HAVE MANY LESSONS TO OFFER
- 4. @spring_io #springio17 WHAT EVEN ARE MICROSERVICES?
- 6. @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)
- 9. HELP?
- 10. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
- 12. @spring_io #springio17 Infrastructure • How do we manage the logs?
- 13. @spring_io #springio17 CENTRALIZED LOGS ARE YOUR #1 PRIORITY
- 19. @spring_io #springio17 Infrastructure • How do we manage the logs? • How about metrics / telemetry?
- 20. @spring_io #springio17 YOU’D BEST BE MONITORING YOUR PLATFORM.
- 23. @spring_io #springio17 Infrastructure • How do we manage the logs? • How about metrics / telemetry? • How do we deploy our code?
- 26. @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?
- 28. @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?
- 34. @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?
- 35. @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)
- 36. @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?
- 39. @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
- 40. @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?
- 42. @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?
- 43. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture
- 44. @spring_io #springio17 Architecture • Do we have an overall design vision?
- 45. @spring_io #springio17 DOES ANYONE KNOW WHAT WE’RE DOING?!
- 48. @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?
- 51. @spring_io #springio17 BE CAREFUL WHEN CHOOSING NEW TECH
- 52. @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?
- 53. INTEGRATION TESTS ARE THE BEST TESTS
- 54. @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?
- 55. @spring_io #springio17 Test Environment • Run periodically (e.g. nightly) • Each service generates fixture data • Service data reset after EACH test
- 56. @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?
- 57. @spring_io #springio17 HTTP VS ASYNC EVENTS
- 58. @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
- 59. @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
- 60. @spring_io #springio17 ENSURE YOU HAVE CIRCUIT BREAKER OR A DEAD LETTER MECHANISM
- 61. @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?
- 63. @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?
- 64. @spring_io #springio17 Date Locality of Reference • Spatial: “How close together is our data?”
- 65. @spring_io #springio17 Data Locality of Reference • Spatial: “How close together is our data?” • Temporal: “How often is our data accessed?”
- 69. @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?
- 70. @spring_io #springio17 MAKE SURE EVERYONE IS AWARE
- 71. @spring_io #springio17 APPLIES TO BOTH INTRA- AND INTER-SERVICE
- 72. IT ALL STARTED WITH ^
- 73. @spring_io #springio17 Domain Driven Design • Ubiquitous Language • Entities • Aggregates • Bounded Contexts • No Direct communications across Boundaries
- 81. @spring_io #springio17 WHILE WE’RE AT IT, GO REACTIVE
- 83. @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?
- 84. @spring_io #springio17 DDD TO THE RESCUE
- 86. @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
- 87. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture • Team Communication
- 88. @spring_io #springio17 Team Communication • How are our teams structured?
- 92. @spring_io #springio17 Team Communication • How are our teams structured? • Who owns which Service?
- 93. @spring_io #springio17 TEAMS SHOULD BE OWNERS
- 94. @spring_io #springio17 Team Communication • How are our teams structured? • Who owns which Service? • What’s our process for merging code?
- 96. @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?
- 98. @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?
- 101. @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?
- 102. @spring_io #springio17 BE RELUCTANT TO ADD NEW PROCESS
- 103. @spring_io #springio17 HIGH FREEDOM / HIGH RESPONSIBILITY
- 105. @spring_io #springio17 Microservice Topics • Infrastructure • Architecture • Team Communication • Miscellaneous Advice
- 106. @spring_io #springio17 Miscellaneous Advice • Don’t get cute with the naming of services
- 107. ANY IDEA WHAT THESE DO?
- 108. @spring_io #springio17 Miscellaneous Advice • Don’t get cute with the naming of services • New Feature -> walk backwards from what the user will see
- 109. @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
- 110. @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
- 111. @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?
- 112. @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
- 114. @spring_io #springio17 MOST OF THE CHALLENGE IS IN INFRASTRUCTURE
- 115. <3 MICROSERVICES
- 116. @spring_io #springio17 PLEASE SHARE YOUR SURVIVAL TIPS!
- 117. @spring_io #springio17 ANY QUESTIONS? ANYTHING I MISSED?
- 118. Thank you!
- 119. @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/
- 120. @spring_io #springio17 Links • Eric Evans: DDD for Microservices: https://www.youtube.com/watch?v=yPvef9R3k-M