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.
Microservices: 
lessons from the trenches 
http://tiny.cc/microservices-lessons 
@MehdiKhalili
Mehdi Khalili 
@MehdiKhalili
http://giphy.com/gifs/parkour-tJLFLygAbaxYk
http://giphy.com/gifs/fail-parkour-dZeSENj3pXT6o
Microservices is 
awesome
Microservices is 
challenging
agenda 
• Introduction 
• Benefits 
• Challenges and tips 
• Resources 
• Questions
Introduction
Monolith
Monolith 
one 
repo
Monolith 
one 
language
Monolith 
one 
database
Monolith 
one 
deployment
Microservices
Microservices 
one 
repo 
per service
Microservices 
one 
language 
per service
Microservices 
one 
persistence engine 
per service
Microservices 
one 
data store 
per service
Microservices 
one 
deployment 
per service
Benefits 
AKA the cool parts!
Scalability
Decentralized 
Data Management
Loose Coupling
Fault Tolerance
Scalable Development
Lower 
Cognitive Load
Technical 
Diversification
Autonomous Teams
Continuous Delivery
Evolutionary Design
http://giphy.com/gifs/win-parkour-12GGmxlQU22fxS
http://giphy.com/gifs/parkour-hardcore-SdtFpqUnHtlbq
http://giphy.com/gifs/fail-parkour-jCi66sK0E770s
Challenges
Fault Tolerance
30 services with 99.9% SLA 
= 432 mins 
= 21.6 hours
99.9% SLA 
30 services 
one day of downtime a month
tightly coupled services
Netflix: 
assumed broken components
design for failure
circuit breaker pattern
circuit breaker
http://martinfowler.com/bliki/images/circuitBreaker/state.png
tightly coupled services
loosely coupled services
contain the failure
fallback 
and 
graceful degradation
https://github.com/Netflix/Hystrix
Hangfire 
hangfire.io
be proactive 
about failure
monitoring endpoints
synthetic monitoring
extensive logging
troubleshooting
correlation id
log aggregation
Gif-y break 
http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
http://giphy.com/gifs/fail-parkour-movement-7SqLFyxYHal6o
http://giphy.com/gifs/fail-parkour-2BuleA8z0C4uY
Decentralized Data Management
Werner Vogels: 
"No direct database access is 
allowed from outside the service, 
and there’s no data sharing 
among the s...
don’t take 
inter-database dependency
you will lose 
loose coupling
you will lose 
tech diversification
that includes BI too!
use aggregator services 
for cross-cutting logic
don’t use 
distributed transactions
CAP theorem 
http://www.allthingsdistributed.com/2007/12/eventually_consistent.html
eventual consistency
compensating actions
Loose Coupling
consumer 
provider 
consumer
loose coupling could lead to 
violation of contract
runtime failure
consumer driven contracts 
consumer 
provider 
consumer 
contract 
contract
pact 
https://github.com/realestate-com-au/pact
pactNet 
https://github.com/SEEK-Jobs/pact-net
consumer driven contracts 
consumer 
provider 
consumer 
mock contract 
mock 
contract 
<- DSL -> 
<- DSL ->
consumer 
provider 
consumer 
service libraries 
service lib 
service lib
you need the big picture
don’t draw diagrams
use logging for 
populating the big picture
correlation id 
plus 
transaction code
document your services
swagger.io 
http://petstore.swagger.wordnik.com/
swagger and curies for 
self documenting services
"_links": { 
"curies": [ 
{ 
"name": "doc", 
"href": "http://domain/docs/{rel}” 
} 
] 
}
Continuous Delivery
Netflix: 
” you code it, you'll deploy it 
and you'll be on pager-duty.”
DevOps culture
test 
automation
deployment 
automation
infrastructure 
automation
Size Matters
It’s microservices; 
not nanoservices
Arnon Rotem-Gal-Oz: 
“A nanoservice is a service whose 
overhead outweighs its utility.”
nanoservice 
kill me now 
monolith 
Yaaaay! 
Size 
pain
organized around 
Business Capabilities
Ian Cartwright: 
“There should be business and 
architecture isomorphism”
The Culture
“Our release process has 43 
steps”
“We need a DevOps team”
“Test automation might work for 
others but our system is different.”
“We need to stop obsessing 
about quality and focus on 
getting this out soon.”
Conway’s Law: 
“Organizations which design 
systems are constrained to produce 
systems which are copies of the 
communica...
monolithic apps thrive 
at monolithic organizations
microservices thrive 
at agile organizations
fix your organization first
Wrap up
Microservices is 
awesome
Microservices is 
NOT a silver bullet
apply it to the extent 
where benefits 
outweigh the overheads
takeaway 
Culture, culture, culture!
takeaway 
Size matters
takeaway 
Fault Tolerance
Resources
Thanks 
Q&A 
@MehdiKhalili
Microservices: lessons from the trenches
Microservices: lessons from the trenches
Upcoming SlideShare
Loading in …5
×

Microservices: lessons from the trenches

1,514 views

Published on

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.

Published in: Software
  • Be the first to comment

Microservices: lessons from the trenches

  1. 1. Microservices: lessons from the trenches http://tiny.cc/microservices-lessons @MehdiKhalili
  2. 2. Mehdi Khalili @MehdiKhalili
  3. 3. http://giphy.com/gifs/parkour-tJLFLygAbaxYk
  4. 4. http://giphy.com/gifs/fail-parkour-dZeSENj3pXT6o
  5. 5. Microservices is awesome
  6. 6. Microservices is challenging
  7. 7. agenda • Introduction • Benefits • Challenges and tips • Resources • Questions
  8. 8. Introduction
  9. 9. Monolith
  10. 10. Monolith one repo
  11. 11. Monolith one language
  12. 12. Monolith one database
  13. 13. Monolith one deployment
  14. 14. Microservices
  15. 15. Microservices one repo per service
  16. 16. Microservices one language per service
  17. 17. Microservices one persistence engine per service
  18. 18. Microservices one data store per service
  19. 19. Microservices one deployment per service
  20. 20. Benefits AKA the cool parts!
  21. 21. Scalability
  22. 22. Decentralized Data Management
  23. 23. Loose Coupling
  24. 24. Fault Tolerance
  25. 25. Scalable Development
  26. 26. Lower Cognitive Load
  27. 27. Technical Diversification
  28. 28. Autonomous Teams
  29. 29. Continuous Delivery
  30. 30. Evolutionary Design
  31. 31. http://giphy.com/gifs/win-parkour-12GGmxlQU22fxS
  32. 32. http://giphy.com/gifs/parkour-hardcore-SdtFpqUnHtlbq
  33. 33. http://giphy.com/gifs/fail-parkour-jCi66sK0E770s
  34. 34. Challenges
  35. 35. Fault Tolerance
  36. 36. 30 services with 99.9% SLA = 432 mins = 21.6 hours
  37. 37. 99.9% SLA 30 services one day of downtime a month
  38. 38. tightly coupled services
  39. 39. Netflix: assumed broken components
  40. 40. design for failure
  41. 41. circuit breaker pattern
  42. 42. circuit breaker
  43. 43. http://martinfowler.com/bliki/images/circuitBreaker/state.png
  44. 44. tightly coupled services
  45. 45. loosely coupled services
  46. 46. contain the failure
  47. 47. fallback and graceful degradation
  48. 48. https://github.com/Netflix/Hystrix
  49. 49. Hangfire hangfire.io
  50. 50. be proactive about failure
  51. 51. monitoring endpoints
  52. 52. synthetic monitoring
  53. 53. extensive logging
  54. 54. troubleshooting
  55. 55. correlation id
  56. 56. log aggregation
  57. 57. Gif-y break 
  58. 58. http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
  59. 59. http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
  60. 60. http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
  61. 61. http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
  62. 62. http://www.buzzfeed.com/richardhjames/are-these-the-funniest-gifs-of-all-time
  63. 63. http://giphy.com/gifs/fail-parkour-movement-7SqLFyxYHal6o
  64. 64. http://giphy.com/gifs/fail-parkour-2BuleA8z0C4uY
  65. 65. Decentralized Data Management
  66. 66. 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
  67. 67. don’t take inter-database dependency
  68. 68. you will lose loose coupling
  69. 69. you will lose tech diversification
  70. 70. that includes BI too!
  71. 71. use aggregator services for cross-cutting logic
  72. 72. don’t use distributed transactions
  73. 73. CAP theorem http://www.allthingsdistributed.com/2007/12/eventually_consistent.html
  74. 74. eventual consistency
  75. 75. compensating actions
  76. 76. Loose Coupling
  77. 77. consumer provider consumer
  78. 78. loose coupling could lead to violation of contract
  79. 79. runtime failure
  80. 80. consumer driven contracts consumer provider consumer contract contract
  81. 81. pact https://github.com/realestate-com-au/pact
  82. 82. pactNet https://github.com/SEEK-Jobs/pact-net
  83. 83. consumer driven contracts consumer provider consumer mock contract mock contract <- DSL -> <- DSL ->
  84. 84. consumer provider consumer service libraries service lib service lib
  85. 85. you need the big picture
  86. 86. don’t draw diagrams
  87. 87. use logging for populating the big picture
  88. 88. correlation id plus transaction code
  89. 89. document your services
  90. 90. swagger.io http://petstore.swagger.wordnik.com/
  91. 91. swagger and curies for self documenting services
  92. 92. "_links": { "curies": [ { "name": "doc", "href": "http://domain/docs/{rel}” } ] }
  93. 93. Continuous Delivery
  94. 94. Netflix: ” you code it, you'll deploy it and you'll be on pager-duty.”
  95. 95. DevOps culture
  96. 96. test automation
  97. 97. deployment automation
  98. 98. infrastructure automation
  99. 99. Size Matters
  100. 100. It’s microservices; not nanoservices
  101. 101. Arnon Rotem-Gal-Oz: “A nanoservice is a service whose overhead outweighs its utility.”
  102. 102. nanoservice kill me now monolith Yaaaay! Size pain
  103. 103. organized around Business Capabilities
  104. 104. Ian Cartwright: “There should be business and architecture isomorphism”
  105. 105. The Culture
  106. 106. “Our release process has 43 steps”
  107. 107. “We need a DevOps team”
  108. 108. “Test automation might work for others but our system is different.”
  109. 109. “We need to stop obsessing about quality and focus on getting this out soon.”
  110. 110. Conway’s Law: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”
  111. 111. monolithic apps thrive at monolithic organizations
  112. 112. microservices thrive at agile organizations
  113. 113. fix your organization first
  114. 114. Wrap up
  115. 115. Microservices is awesome
  116. 116. Microservices is NOT a silver bullet
  117. 117. apply it to the extent where benefits outweigh the overheads
  118. 118. takeaway Culture, culture, culture!
  119. 119. takeaway Size matters
  120. 120. takeaway Fault Tolerance
  121. 121. Resources
  122. 122. Thanks Q&A @MehdiKhalili

×