Microservices: lessons from the trenches
•Transferir como PPT, PDF•
1 gostou•1,950 visualizações
Microservices are awesome, when they're done right. Teams start with microservices with the best intentions and sometimes end up hurting themselves and the business in doing so. There are many gotchas and oversights that could make the experience a bit painful or in some cases a complete disaster. In this presentation I talk about some of the happy and not so happy lessons I've learnt in implementing microservices over the years.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Microservices: lessons from the trenches
Semelhante a Microservices: lessons from the trenches (20)
Último
Último (20)
Microservices: lessons from the trenches
- 2. Microservices: lessons from the trenches http://tiny.cc/microservices-lessons @MehdiKhalili
- 9. agenda • Introduction • Benefits • Challenges and tips • Resources • Questions
- 10. Introduction
- 11. Monolith
- 16. Microservices
- 17. Microservices one repo per service
- 18. Microservices one language per service
- 19. Microservices one persistence engine per service
- 20. Microservices one data store per service
- 21. Microservices one deployment per service
- 22. Benefits AKA the cool parts!
- 23. Scalability
- 25. Loose Coupling
- 26. Fault Tolerance
- 30. Autonomous Teams
- 36. Challenges
- 37. Fault Tolerance
- 38. 30 services with 99.9% SLA = 432 mins = 21.6 hours
- 39. 99.9% SLA 30 services one day of downtime a month
- 41. Netflix: assumed broken components
- 44. circuit breaker
- 49. fallback and graceful degradation
- 52. be proactive about failure
- 56. troubleshooting
- 57. correlation id
- 58. log aggregation
- 59. Gif-y break
- 68. Werner Vogels: "No direct database access is allowed from outside the service, and there’s no data sharing among the services." http://queue.acm.org/detail.cfm?id=1142065
- 69. don’t take inter-database dependency
- 70. you will lose loose coupling
- 71. you will lose tech diversification
- 72. that includes BI too!
- 73. use aggregator services for cross-cutting logic
- 74. don’t use distributed transactions
- 78. Loose Coupling
- 80. loose coupling could lead to violation of contract
- 81. runtime failure
- 82. consumer driven contracts consumer provider consumer contract contract
- 85. consumer driven contracts consumer provider consumer mock contract mock contract <- DSL -> <- DSL ->
- 86. consumer provider consumer service libraries service lib service lib
- 87. you need the big picture
- 89. use logging for populating the big picture
- 90. correlation id plus transaction code
- 93. swagger and curies for self documenting services
- 94. "_links": { "curies": [ { "name": "doc", "href": "http://domain/docs/{rel}” } ] }
- 96. Netflix: ” you code it, you'll deploy it and you'll be on pager-duty.”
- 97. DevOps culture
- 98. test automation
- 101. Size Matters
- 102. It’s microservices; not nanoservices
- 103. Arnon Rotem-Gal-Oz: “A nanoservice is a service whose overhead outweighs its utility.”
- 104. nanoservice kill me now monolith Yaaaay! Size pain
- 105. organized around Business Capabilities
- 106. Ian Cartwright: “There should be business and architecture isomorphism”
- 107. The Culture
- 108. “Our release process has 43 steps”
- 109. “We need a DevOps team”
- 110. “Test automation might work for others but our system is different.”
- 111. “We need to stop obsessing about quality and focus on getting this out soon.”
- 112. Conway’s Law: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”
- 113. monolithic apps thrive at monolithic organizations
- 114. microservices thrive at agile organizations
- 115. fix your organization first
- 116. Wrap up
- 118. Microservices is NOT a silver bullet
- 119. apply it to the extent where benefits outweigh the overheads
- 120. takeaway Culture, culture, culture!
- 123. Resources
Notas do Editor
- We see something awesome and we get really excited about it and think I want to be like that. I want to do that
- One repo One programming language One database One deployment
- One repo One programming language One database One deployment
- One repo One programming language One database One deployment
- One repo One programming language One database One deployment
- One repo One programming language One database One deployment
- Each service has One repo One programming language One data store And one deployment
- Each service has One repo One programming language One data store And one deployment
- Each service has One repo One programming language One data store And one deployment
- Each service has One repo One programming language One data store And one deployment
- Each service has One repo One programming language One data store And one deployment
- Each service has One repo One programming language One data store And one deployment
- Scale the bits that require scale.
- Encapsulate data with the services No locks =&gt; Scalability Ease of maintenance: 4000 sps and 1000 tables!
- allows services and consumers to evolve independently of each other. reimplement a service as long as from outside it looks and behaves the same
- It&apos;s not all or nothing unlike monolith
- Monolith is one repo not as many merge conflicts not as much consistency force/requirement
- Less code =&gt; easier to understand =&gt; faster to run =&gt; easier to maintain
- Eliminates any long-term commitment to a technology stack. Use right tool, standards and stack for every service and change it whenever you like.
- from scoping out the functionality, to architecting it, to building it, and operating it
- Each service can be deployed independently of other services - easier to deploy new versions of services frequently. Less to release each time =&gt; CD =&gt; all the benefits of CD
- Smaller services are easier to change and evolve and that facilitates experimentation Create a new microservice to experiment with an idea in isolation of the rest of the system. If it flies, keep it. If it doesn&apos;t, kill it.
- This actually shows one of the bigger risks with microservices: when it hurts, it really hurts!!
- Akamai NetStorage
- Assume everything your system talks to is broken and write it so it can cope!
- when one of your dependencies stops responding, you need to stop calling it for a little while.
- circuit breaker
- Fire & forget Pub/sub Contain the failure
- Hitting a different URL Caching Returning a canned response (null)
- circuit breaker with fallbacks and graceful degradation monitoring
- Guaranteed fire & forget background processing
- Don&apos;t wait for it to fail before you fix it
- to expose the error count, response times, up time, transaction per second
- simulate an action or path that a customer or end-user would take. continuously monitor functionality, availability, and response time measures
- Helps with troubleshooting and also with health monitoring
- We were getting exception on an endpoint because it was missing a param Where did the traffic came in from?
- you’ll lose most of microservices benefits
- We changed a stored procedure’s param and it broke BI
- In a monolithic app you have transactions You will have slower transactions, and might create system wide locking!
- We were introducing soft deletes and we didn’t know what would be impacted
- Pact: DSL, generates mock and plays back the request for the provider
- Consumer codes against a mock and provider complies with contracts Unit testing
- circuit breaker Fallback graceful degradation caching
- so when you want to change the behavior of something you know what will be impacted
- Extensive logging Correlation id Transaction code Log aggregation
- Extensive logging Correlation id Transaction code Log aggregation
- It will be resisted by operations and change management Resistance by ops
- And you should have a bounded context representing each capability keep to your bounded context
- A business person should be able to look at a high level map of the architecture and see the business represented there and similarly as technologists we should be able to look at the business and see the architecture represented there.
- The microservices culture
- Explain what’s wrong with this
- Not organizations doing agile; but agile organization
- Micro management Long release process Hard to sell unit testing