Downloaded 43 times
!["_links": {
"curies": [
{
"name": "doc",
"href": "http://domain/docs/{rel}”
}
]
}](https://image.slidesharecdn.com/microservices-lessons-141204162455-conversion-gate01/75/Microservices-lessons-from-the-trenches-94-2048.jpg)
Uploaded byMehdi Khalili
Microservices: lessons from the trenches
The document discusses the benefits and challenges of microservices architecture, emphasizing scalability, decentralized data management, and fault tolerance as key advantages while addressing pitfalls such as tightly coupled services and the complexities of monitoring. It includes practical tips on designing for failure, maintaining loose coupling, and the importance of organizational culture in successfully implementing microservices. The conclusion underscores that while microservices offer significant benefits, they are not a one-size-fits-all solution and emphasize the need for proper organizational alignment and cultural shift.
Microservices: lessons from the trenches
- 2. Microservices: lessons fromthe trenches http://tiny.cc/microservices-lessons @MehdiKhalili
- 3.
- 4.
- 5.
- 7.
- 8.
- 9. agenda • Introduction • Benefits • Challenges and tips • Resources • Questions
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. Microservices one repo per service
- 18. Microservices one language per service
- 19. Microservices one persistenceengine per service
- 20. Microservices one datastore per service
- 21. Microservices one deployment per service
- 22. Benefits AKA thecool parts!
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38. 30 services with99.9% SLA = 432 mins = 21.6 hours
- 39. 99.9% SLA 30services one day of downtime a month
- 40.
- 41. Netflix: assumed brokencomponents
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49. fallback and gracefuldegradation
- 50.
- 51.
- 52. be proactive aboutfailure
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68. Werner Vogels: "Nodirect 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-databasedependency
- 70. you will lose loose coupling
- 71. you will lose tech diversification
- 72. that includes BItoo!
- 73. use aggregator services for cross-cutting logic
- 74. don’t use distributedtransactions
- 75.
- 76.
- 77.
- 78.
- 79.
- 80. loose coupling couldlead to violation of contract
- 81.
- 82. consumer driven contracts consumer provider consumer contract contract
- 83.
- 84.
- 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 thebig picture
- 88.
- 89. use logging for populating the big picture
- 90. correlation id plus transaction code
- 91.
- 92.
- 93. swagger and curiesfor self documenting services
- 94. "_links": { "curies":[ { "name": "doc", "href": "http://domain/docs/{rel}” } ] }
- 95.
- 96. Netflix: ” youcode it, you'll deploy it and you'll be on pager-duty.”
- 97.
- 98.
- 99.
- 100.
- 101.
- 102. It’s microservices; notnanoservices
- 103. Arnon Rotem-Gal-Oz: “Ananoservice is a service whose overhead outweighs its utility.”
- 104. nanoservice kill menow monolith Yaaaay! Size pain
- 105. organized around BusinessCapabilities
- 106. Ian Cartwright: “Thereshould be business and architecture isomorphism”
- 107.
- 108. “Our release processhas 43 steps”
- 109. “We need aDevOps team”
- 110. “Test automation mightwork for others but our system is different.”
- 111. “We need tostop obsessing about quality and focus on getting this out soon.”
- 112. Conway’s Law: “Organizationswhich 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 atagile organizations
- 115.
- 116.
- 117.
- 118. Microservices is NOTa silver bullet
- 119. apply it tothe extent where benefits outweigh the overheads
- 120. takeaway Culture, culture,culture!
- 121.
- 122.
- 123.
- 124.
Editor's Notes
- #5 We see something awesome and we get really excited about it and think I want to be like that. I want to do that
- #12 One repo One programming language One database One deployment
- #13 One repo One programming language One database One deployment
- #14 One repo One programming language One database One deployment
- #15 One repo One programming language One database One deployment
- #16 One repo One programming language One database One deployment
- #17 Each service has One repo One programming language One data store And one deployment
- #18 Each service has One repo One programming language One data store And one deployment
- #19 Each service has One repo One programming language One data store And one deployment
- #20 Each service has One repo One programming language One data store And one deployment
- #21 Each service has One repo One programming language One data store And one deployment
- #22 Each service has One repo One programming language One data store And one deployment
- #24 Scale the bits that require scale.
- #25 Encapsulate data with the services No locks =&gt; Scalability Ease of maintenance: 4000 sps and 1000 tables!
- #26 allows services and consumers to evolve independently of each other. reimplement a service as long as from outside it looks and behaves the same
- #27 It&apos;s not all or nothing unlike monolith
- #28 Monolith is one repo not as many merge conflicts not as much consistency force/requirement
- #29 Less code =&gt; easier to understand =&gt; faster to run =&gt; easier to maintain
- #30 Eliminates any long-term commitment to a technology stack. Use right tool, standards and stack for every service and change it whenever you like.
- #31 from scoping out the functionality, to architecting it, to building it, and operating it
- #32 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
- #33 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.
- #36 This actually shows one of the bigger risks with microservices: when it hurts, it really hurts!!
- #41 Akamai NetStorage
- #43 Assume everything your system talks to is broken and write it so it can cope!
- #44 when one of your dependencies stops responding, you need to stop calling it for a little while.
- #45 circuit breaker
- #48 Fire & forget Pub/sub Contain the failure
- #50 Hitting a different URL Caching Returning a canned response (null)
- #51 circuit breaker with fallbacks and graceful degradation monitoring
- #52 Guaranteed fire & forget background processing
- #53 Don&apos;t wait for it to fail before you fix it
- #54 to expose the error count, response times, up time, transaction per second
- #55 simulate an action or path that a customer or end-user would take. continuously monitor functionality, availability, and response time measures
- #56 Helps with troubleshooting and also with health monitoring
- #57 We were getting exception on an endpoint because it was missing a param Where did the traffic came in from?
- #70 you’ll lose most of microservices benefits
- #73 We changed a stored procedure’s param and it broke BI
- #75 In a monolithic app you have transactions You will have slower transactions, and might create system wide locking!
- #81 We were introducing soft deletes and we didn’t know what would be impacted
- #84 Pact: DSL, generates mock and plays back the request for the provider
- #86 Consumer codes against a mock and provider complies with contracts Unit testing
- #87 circuit breaker Fallback graceful degradation caching
- #88 so when you want to change the behavior of something you know what will be impacted
- #90 Extensive logging Correlation id Transaction code Log aggregation
- #91 Extensive logging Correlation id Transaction code Log aggregation
- #96 It will be resisted by operations and change management Resistance by ops
- #106 And you should have a bounded context representing each capability keep to your bounded context
- #107 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.
- #108 The microservices culture
- #109 Explain what’s wrong with this
- #115 Not organizations doing agile; but agile organization
- #121 Micro management Long release process Hard to sell unit testing