agile australia 2014: workshop - design and implementation of microservices

754
Microservices ThoughtWorks

Upload: agile-australia

Post on 10-May-2015

872 views

Category:

Business


1 download

DESCRIPTION

Design and Implementation of Microservices Sam Newman - Technical Consultant, ThoughtWorks Scott Shaw - Head of Technology, ThoughtWorks Discover a consistent and reinforcing set of tools and practices rooted in the philosophy of small and simple; this can help you move towards a microservice architecture.

TRANSCRIPT

  • 1.Microservices ThoughtWorks

2. Scott Shaw@scottwshaw Sam Newman @samnewman 3. Schedule 09:00 - 10:30 Session 1 10:30 - 10:45 Break 10:45 - 12:00 Session 2 12:00 - 13:15 Lunch 13:15 - 15:00 Session 3 15:00 - 15:30 Break 15:30 - 17:00 Session 4 4. 09:00 - 10:30 Session 1 Introduction Icebreaker Why Services Principes & Constraints Evolutionary Architecture 5. 10:45 - 12:00 Session 2 Integration 6. 13:15 - 15:00 Session 3 Splitting Services CAP & Transactions Testing & CDCs Operational Concerns 7. 15:00 - 15:30 Session 4 Deploying UI & Mobile Conways Law Security 8. http://www.ickr.com/photos/55255903@N07/6835060992 9. http://www.ickr.com/photos/22154104@N00/3466383400 10. http://www.ickr.com/photos/sailbit/3409405778/ 11. Why Services? 12. or: are we building systems that are too big? 13. 90% of the TCO of an application is incurred post launch 14. IT project-related losses are an embarrassment for the industry fund backers AustralianSuper, Cbus, HOSTPLUS, HESTA and MTAA Super which pride themselves on low fees and improving member services. Illustration: Karl Hilzinger A group of industry superannuation funds has revealed in accounts lodged with the Australian Securities and Investments Commission that the cost of implementing a key IT project has blown out by another $43 million. This means that a project that started in 2008 and was meant to be completed by 2010 will cost super fund members at least $250 million and will be delivered at least four years late. Superpartners, a super administration company owned by five industry retirement schemes, posted a $7.4 million loss on revenues of $257 million for the 12 months ended June 30, after being forced to take a $20.4 million impairment Superpartners botched IT project costs industry super funds millions Published 26 November 2013 01:17, Updated 27 November 2013 07:46 Sally Patten 15. we have to rewrite entire ecosystems every few years 16. we have to rewrite entire ecosystems every few years this doesnt make many CFOs happy 17. scary story 18. RetailSite DepartureControl 19. RetailSite DepartureControl 20. RetailSite DepartureControl 21. RetailSite DepartureControl 48 Cores! 256 GB RAM (NUMA)! ~ $1 x 106 per machine 22. 22 23. Airline Tightly coupled Golden Hammer Syndrome Single point of failure Expensive to scale High operational cost High cost of failure 24. 24 25. Airline RetailSite DepartureControl 26. Airline RetailSite DepartureControl 27. Airline RetailSite DepartureControl 28. Airline RetailSite DepartureControl X 29. scary story 30. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 31. The stovepipe enterprise Stovepipes)are)systems)procured)and)developed)to)solve)a)specic)problem,) characterized)by)a)limited)focus)and)func:onality,)and)containing)data)that) cannot)be)easily)shared)with)other)systems.)(DOE)1999)) DOE.%Commi*ee%to%Assess%the%Policies%and%Prac7ces%of%the%Department%of%Energy,%Improving%Project% Management%in%the%Department%of%Energy,%Na7onal%Academy%Press,%Washington,%D.C.,%1999,%page%133.% 32. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 33. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 34. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access ? HR UI "Middleware DB" ? ? ? UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access UI / Service Direct db access Direct db access HR UI "Middleware DB" ? ? ? UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access UI / Service Direct db access Direct db access HR UI "Middleware DB" ? ? ? UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access UI / Service Direct db access Direct db access HR UI "Middleware DB" ? ? ? Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access UI / Service Direct db access 35. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? Logic scattered all over the place Data scattered all over the place Difcult to predict the effect of changes Which system is right? BI / MI almost impossible to get at 36. V1 37. V2 38. Go JVM NodeJS Ruby 39. Go JVM NodeJS Ruby 40. Go NodeJS Ruby Clojure! 41. Why now? 42. standing on the shoulders of giants 43. Engineering for: reliability and availability Devops circuit breakers, health checks, status pages 44. Strategic Design Bounded Contexts town planning 45. web integration application protocols HATEOAS 46. infrastructure automation patterns for push button deployments the lean software value stream 47. Summary We understand more about building reliable distributed systems cloud compute and programmable infrastructure has matured organisations need to adapt and change quickly to survive we spend too much money on building monoliths 48. Evolutionary Architecture 49. Just enough architecture 50. towns are zoned 51. heavy industrial 52. commercial 53. light residential 54. Would you build a playground next to a power station? 55. Would you build a playground next to a power station? 56. Would you build a playground next to a power station? a sewage works next to Macys? 57. Towns share utilities 58. Everyone uses 240V DC right? 59. and it would be a bad idea not to use the same language for stop signs... 60. emergent design is within the zones 61. emergent design is within the zones 62. evolutionary architecture is in the gaps emergent design is within the zones 63. evolutionary architecture is in the gaps emergent design is within the zones 64. Things to think about: Concentrate on the business capabilities technical acronyms make us think the wrong way What are the common features? Integration methods? What different types of data live where? 65. it can be a single system and its component parts or chunking up to how your systems integrate with others and if you cant remember thats ok too, we dont want perfect, just something to work with 66. Summary do just enough up front evolutionary architecture is in the gaps emergent design is in the boxes 67. Bounded Contexts 68. What makes a good service? 69. High Cohesion 70. Loose Coupling 71. The Trie 72. The Trie Musik Web 73. The Trie Musik Web Persistence 74. The Trie Musik Web Persistence 75. The Trie Musik Web Persistence 76. The Trie Musik Web Persistence 77. A set of capabilities on an endpoint 78. Bounded Context 79. "The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently." 80. A specic responsibility enforced by explicit boundaries ! http://www.sapiensworks.com/blog/post/ 2012/04/17/DDD-The-Bounded-Context- Explained.aspx 81. Add to cart 82. Add to cart Checkout 83. Add to cart Checkout View Latest Releases 84. Add to cart Checkout View Latest Releases Search 85. Add to cart Checkout View Latest Releases Search Listen To Previews 86. Add to cart Checkout View Latest Releases Search Listen To Previews 87. Add to cart Checkout View Latest Releases Search Listen To Previews Shopping Cart Catalog Music Library 88. Hexagonal Architectures 83 bounded contexts all the way down (and back up again) 89. Object Object Object Object 90. Object James conjecture objects should be no bigger than my head 91. Object 92. Object Object Object Object 93. as we chunk up domains of abstraction, each domain should be small enough to t in my head 94. 93 in this case, it meant 100s of lines of code per application 95. Architecture Principles 96. to build systems is to make trade-os 97. to build systems is to make trade-os throughput vs cost 98. to build systems is to make trade-os throughput vs cost 99. to build systems is to make trade-os throughput vs cost portability vs deployability 100. to build systems is to make trade-os throughput vs cost portability vs deployability 101. to build systems is to make trade-os throughput vs cost portability vs deployability replacability vs maintainability 102. to build systems is to make trade-os throughput vs cost portability vs deployability replacability vs maintainability evolutionary architecture and emergent design are approaches that maximise ex 103. you want to maximise the degrees of freedom of your system 104. The idea of architecture principles is to try and balance these tradeoffs 105. to try and balance short term gain with longer term strategic goals The idea of architecture principles is to try and balance these tradeoffs 106. to try and balance short term gain with longer term strategic goals The idea of architecture principles is to try and balance these tradeoffs 107. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously The idea of architecture principles is to try and balance these tradeoffs 108. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously The idea of architecture principles is to try and balance these tradeoffs 109. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously They should move you towards a state where the tradeoffs dont happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffs 110. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously They should move you towards a state where the tradeoffs dont happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffsThey should be driven by the goals of the business 111. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously They should move you towards a state where the tradeoffs dont happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffsThey should be driven by the goals of the business 112. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously They should move you towards a state where the tradeoffs dont happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffsThey should be driven by the goals of the business for the next 18-24 months 113. to try and balance short term gain with longer term strategic goals Where trade offs have to be made they should be done so visibility and consciously They should move you towards a state where the tradeoffs dont happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffsThey should be driven by the goals of the business for the next 18-24 months any longer and you are only fooling yourself 114. and if you dont know what your business goals are... 115. and if you dont know what your business goals are... may we respectfully suggest that you go and nd them out! 116. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework 117. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework 118. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework this is not about not allowed to break them, this is about having a conversation 119. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework this is not about not allowed to break them, this is about having a conversation 120. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework this is not about not allowed to break them, this is about having a conversation these work best when backed up by tooling that makes it easy to do the right thing 121. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework this is not about not allowed to break them, this is about having a conversation these work best when backed up by tooling that makes it easy to do the right thing shall we take a look at some examples? 122. http://www.12factor.net/ 123. Herokus 12 factors are a mixture of principles and constraints http://www.12factor.net/ 124. never return directly from a POST 125. favour choreography over orchestration never return directly from a POST 126. favour choreography over orchestration dont share domain code (and physically separate the codebases to ensure this) never return directly from a POST 127. favour choreography over orchestration dont share domain code (and physically separate the codebases to ensure this) scale using processes, not threads never return directly from a POST 128. favour choreography over orchestration dont share domain code (and physically separate the codebases to ensure this) scale using processes, not threads dont use session state never return directly from a POST 129. Integration 130. or 131. Avoiding Babel 132. Two Key Attributes Of A Good Service 133. 1. High Cohesion ! 2. Loose Coupling 134. 1. High Cohesion ! 2. Loose Coupling 135. 2013 Electronic Arts Inc. 136. Otherwise http://www.ickr.com/photos/mikecogh/4472054494/ 137. Integration Styles An Evolutionary View Data Oriented Procedure Oriented Document Oriented Resource Oriented 138. Databases 139. DB MusikShopMono 140. DB Schema Recomendation Service MusicShopMono 141. DB Schema Recomendation ServiceMusicShopMono 142. DB Schema Recomendation ServiceMusicShopMono 143. DB Schema Recomendation ServiceMusicShopMono No loose coupling! 144. DB Schema Recomendation Service MusicShopMono DB Schema Magic ETL 145. which is ok until... 146. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of External Data Read only data Read only data Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access which is ok until... and yes, this is a real world example... 147. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of External Data Read only data Read only data Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access changing anything is really really hard 148. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? different types of data are smeared about 149. HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 150. systems like this are brittle HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 151. systems like this are brittle difcult to reason aboutHR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 152. systems like this are brittle difcult to reason about difcult to change HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 153. systems like this are brittle difcult to reason about difcult to change difcult to maintain HR UI "Middleware DB" ? ? ? Data Warehouse ? canned reports cubes / ad-hoc UIUI UI Finance UI Views of external Data Read only external data Read only external dataDirect db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access Direct db access SSO UI / Service AD Direct db access Direct db access ? 154. Next! 155. RPC 156. method calls across a process boundary 157. consider a client invoking the createUser endpoint 158. consider a client invoking the createUser endpoint 159. createUser(id, ! firstName, ! lastName,! address) consider a client invoking the createUser endpoint 160. other clients can use the same call as the rst createUser(id, ! firstName, ! lastName,! address) 161. other clients can use the same call as the rst createUser(id, ! firstName, ! lastName,! address) so far so good 162. but what happens when you want to change how one of the clients calls your service? 163. but what happens when you want to change how one of the clients calls your service? maybe I dont want to use rst name and last name anymore 164. I want to use the fullname createUser(id, ! firstName, ! lastName,! address) createUserByFullname(! id, ! fullName,! address) 165. or I want to specify address individually createUser(id, ! firstName, ! lastName,! address) createUserByFullname(! id, ! fullName,! address) createUserByFullnameAnd Address(! id, ! fullName,! street1,! street2,! zipcode) 166. one of two things tends to happen with systems of this type 167. one of two things tends to happen with systems of this type 1. you end up with very long service denitions 168. one of two things tends to happen with systems of this type 1. you end up with very long service denitions 2. coordination of changes to clients becomes difcult 169. 1. specications quickly become very very long and a nightmare to maintain 170. 1. specications quickly become very very long and a nightmare to maintain createUserWithFullname(...) 171. 1. specications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...) 172. 1. specications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...) createUserWithFullnameAndAddress (...) 173. 1. specications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...) createUserWithFullnameAndAddress (...) createUserWithAddress(...) 174. 1. specications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...) createUserWithFullnameAndAddress (...) createUserWithAddress(...) every time I want to change some logic, I have to change every method call 175. 2. you have to coordinate the release cycles of your clients createUser(id, ! firstName, ! lastName,! address) 176. createUser(id, ! firstName, ! lastName,! address) createUser(id, ! fullname, ! address) @deprecated 2. you have to coordinate the release cycles of your clients 177. createUser(id, ! firstName, ! lastName,! address) createUser(id, ! fullname, ! address) @deprecated and if you have many clients, thats no easy task 2. you have to coordinate the release cycles of your clients 178. A Brief Aside 179. Who can tell me about RFC 761? 180. Postels Law: Be liberal in what you do, conservative in what you expect 181. Practical impact of this - only bind to what you need to reduce breaking service consumption 182. Service B Service A Shared Lib v1 Shared Lib v1 183. Service B Service A Shared Lib v1 Shared Lib v1 184. Service B Service A Shared Lib v1 Shared Lib v1 185. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 186. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols 187. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols WSDL-binding 188. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols WSDL-binding JAXB 189. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols WSDL-binding JAXB Java Serialization 190. Messaging 191. (AMC / Associated Press) 192. a bit like going back to the 50s enterprise (AMC / Associated Press) 193. a bit like going back to the 50s enterprise except without the smoking and the rampant misogyny (AMC / Associated Press) 194. back in the day, if you wanted to book a holiday, you didnt go onto your corporate intranet to do it right? 195. back in the day, if you wanted to book a holiday, you didnt go onto your corporate intranet to do it right? you went to the cupboard 196. back in the day, if you wanted to book a holiday, you didnt go onto your corporate intranet to do it right? you went to the cupboard and you pulled out one of these 197. back in the day, if you wanted to book a holiday, you didnt go onto your corporate intranet to do it right? you went to the cupboard and you pulled out one of these and you lled it in 198. james holiday request form and then you sent it to the HR department 199. james holiday request form and then you sent it to the HR department where it was processed, and eventually you got another envelope back containing the approval 200. and messaging is a bit like that 201. and messaging is a bit like that asynchronous 202. and messaging is a bit like that asynchronous after all, you wouldnt want to block waiting for internal mail right? 203. incidentally, I wasnt actually there in the 50s. I just have this on good authority and messaging is a bit like that asynchronous after all, you wouldnt want to block waiting for internal mail right? 204. generally you create a message composed of a document 205. and you push it onto some kind of queue 206. and you push it onto some kind of queue 207. systems interested in your documents can pop those documents and act on them 208. systems interested in your documents can pop those documents and act on them 209. and return them should that be the semantics of the exchange 210. the documents allowed additive changes to be made without breaking existing clients 211. the documents allowed additive changes to be made without breaking existing clients If you want to add a eld, you can do so as long as clients are late bound to the documents 212. the documents allowed additive changes to be made without breaking existing clients If you want to add a eld, you can do so as long as clients are late bound to the documents and if you want to rename something, you can do that easily too (add another one with the same name) 213. and the asynchronous nature decouples the applications from each other 214. and the asynchronous nature decouples the applications from each other 215. and the asynchronous nature decouples the applications from each other you can change this 216. and the asynchronous nature decouples the applications from each other you can change this without breaking this 217. of course, there is a teensy bit more to it than that... 218. Channel Adapter Channel Datatype Channel Dead Letter Channel Guaranteed Delivery ! Invalid Message Channel Message Bus Messaging Bridge Publish Subscribe Channel Aggregator Content Based Router Composed Message Message FIlter Message Router Recipient List Process Manager Splitter Routing SlipResequencer Competing Consumers Message Endpoint Durable Subscriber Event-Driven Consumer Message Dispatcher ? Selective Consumer Service Activator Polling Consumer Transactional Client Messaging Gateway quite a lot more to be perfectly frank 219. Getting async comms right can be hard! 220. And can require the dreaded middleware 221. The ESB! 222. So when to use it? 223. So when to use it? Long-running jobs 224. So when to use it? Long-running jobs Alternative scaling 225. So when to use it? Long-running jobs Alternative scaling Resiliency 226. So when to use it? Long-running jobs Alternative scaling Resiliency Broadcast 227. So when to use it? Long-running jobs Alternative scaling Resiliency Broadcast Low-latency 228. Next! 229. Lets take a look at the worlds most successful, distributed, scalable computing system for some tips 230. The Web http://www.ickr.com/photos/photophilde/4527076709/ 231. Client cache Proxy cache CDN Infrastructurecaches Reverse proxycache 232. HTTP -> REST! 233. Leonard Richardsons maturity heuristic 234. Leonard Richardsons maturity heuristic http://martinfowler.com/articles/richardsonMaturityModel.html 235. Level 0 - POX single service endpoint, many methods 236. createUserWithFullname(...) Level 0 - POX single service endpoint, many methods 237. createUserWithFullname(...) createUser(...) Level 0 - POX single service endpoint, many methods 238. createUserWithFullname(...) createUser(...) updateUserById(...) Level 0 - POX single service endpoint, many methods 239. createUserWithFullname(...) createUser(...) updateUserById(...) updateUserByFullName(...) Level 0 - POX single service endpoint, many methods 240. createUserWithFullname(...) createUser(...) updateUserById(...) updateUserByFullName(...) deleteUserById(...) Level 0 - POX single service endpoint, many methods 241. createUserWithFullname(...) createUser(...) updateUserById(...) updateUserByFullName(...) deleteUserById(...) Level 0 - POX single service endpoint, many methods findUserById(...) 242. Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources. 243. Level 1 - resources 244. Level 1 - resources 245. ! ! Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation. 246. Level 2 - HTTP verbs 247. Level 2 - HTTP verbs getUserById(...) 248. Level 2 - HTTP verbs getUserById(...) GET /users/f3c2ac 249. Level 3 introduces discoverability, providing a way of making a protocol more self-documenting. 250. Basket! 251. What if consumers of a service could act in the same way? 252. scottwshaw / gist:ee875a6018e1676b36ad Last active 22 minutes ago 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 varjsonpath=require('JSONPath'); varversion1={"results": {"link":{"uri":"http://musikshop.com/search/artist=the%20brakes", "rel":"self"}, "releases":[{"release":"TaleofTwoCities", "year":"2008", "link":{"uri":"http://musikshop.com/api/cmVsZWFzZXMvMQ==", "rel":"http://musikshop.com/rels/release"}}, {"release":"TheBrakes", "year":"2006", "link":{"uri":"http://musikshop.com/api/cmVsZWFzZXMvMg==", "rel":"http://musikshop.com/rels/release"}}]}}; jsonpath.eval(version1,"$..[?(@.rel=='http://musikshop.com/rels/release')]"); gistfile1.json A Document with Hypermedia Links 253. A non-breaking change to the service contract scottwshaw / gist:d531a3f35de01ea45644 Last active 20 minutes ago 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 varjsonpath=require('JSONPath'); varversion2={"results":{ "link":{"uri":"http://musikshop.com/search/artist=the%20brakes", "rel":"http://musikshop.com/rels/self"}, "fullLengthReleases":[{"release":"TaleofTwoCities", "year":"2008", "link":{"uri":"http://musikshop.com/api/cmVsZWFzZXMvMQ==", "rel":"http://musikshop.com/rels/release"}}], "EPReleases":[{"release":"TheBrakes", "year":"2006", "link":{"uri":"http://musikshop.com/api/cmVsZWFzZXMvMg==", "rel":"http://musikshop.com/rels/release"}}]}} jsonpath.eval(version2,"$..[?(@.rel=='http://musikshop.com/rels/release')]"); gistfile1.json 254. In practice most people end up here Aim high! 255. This stuff is hard to change later - so do your research and pick principles that make sense for you 256. Go read more! http://martinfowler.com/articles/richardsonMaturityModel.html http://www.crummy.com/writing/speaking/2008-QCon/ 257. Summary REST over HTTP is best - aim high! Messaging is cool, but can be hard Whatever you do, think lazy binding! 258. How To Split Services 259. Add to cart 260. Add to cart Checkout 261. Add to cart Checkout View Latest Releases 262. Add to cart Checkout View Latest Releases Search 263. Add to cart Checkout View Latest Releases Search Listen To Previews 264. Add to cart Checkout View Latest Releases Search Listen To Previews 265. Add to cart Checkout View Latest Releases Search Listen To Previews Shopping Cart Catalog Music Library 266. MusikShopMono 267. MusikShopMono Warehouse Finance Catalog Recommendation 268. That was the easy bit 269. Enter the DB 270. DB MusikShopMono 271. DB Schema Recomendation Service MusicShopMono 272. DB Schema Recomendation ServiceMusicShopMono 273. DB Schema Recomendation ServiceMusicShopMono 274. DB MusikShopMono Warehouse Finance Catalog Recommendation Repository 275. DB MusikShopMono Warehouse Finance Catalog Recommendation 276. Catalog MusikShopMono 277. Catalog Line Items MusikShopMono 278. Catalog Finance Line Items MusikShopMono 279. Catalog Finance Line Items Ledger MusikShopMono 280. Catalog Finance Line Items Ledger MusikShopMono 281. Catalog Finance Line Items Ledger MusikShopMono 282. Catalog Finance Line Items Ledger MusikShopMono 283. Catalog Finance Line Items Ledger MusikShopMono 284. MusikShop System Finance ServiceCatalog Service 285. MusikShop System Finance ServiceCatalog Service 286. MusikShop System Line Items Finance ServiceCatalog Service 287. MusikShop System Line Items Ledger Finance ServiceCatalog Service 288. Country Codes MusikShopMono Finance Warehouse Catalog 289. Catalog Finance Warehouse Country Codes Country Codes Country Codes MusikShopMono 290. Catalog Finance Warehouse MusikShopMono 291. Finance Warehouse Customer Record MusikShopMono 292. reify 293. Finance Warehouse Customer Record MusikShop 294. Finance Warehouse Customer Record Customer MusikShop 295. Warehouse ServiceFinance Service MusikShop System Customer Service 296. Catalog Warehouse Item MusikShop 297. Catalog Warehouse Item MusikShop Bee Gees Hits | $4.99 | 45 298. Catalog Warehouse Item MusikShop Bee Gees Hits | $4.99 | 45 299. Catalog Warehouse Item MusikShop Bee Gees Hits | $4.99 | 45 300. Catalog Warehouse Catalog Item MusikShop Stock Levels 301. DB 302. DB Cost Of Change 303. @samnewman Summary Split around bounded contexts Make small, incremental changes Split inside the process boundary before splitting out services Start coarse-grained 304. CAP Theory 305. http://www.ickr.com/photos/76578519@N00/4695658106 306. What is CAP theory? 307. It is impossible for a distributed computer system to simultaneously provide all three of the following guarantees: http://en.wikipedia.org/wiki/CAP_theorem Consistency (all nodes see the same data at the same time) Availability (a guarantee that every request receives a response about whether it was successful or failed) Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system) 308. Partition Tolerance The system continues to operate despite arbitrary message loss or failure of part of the system Typically, we need this - so end up trading off the other two 309. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer 310. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer 311. Option 1: Keep Node 2 serving trafc Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service 312. Option 1: Keep Node 2 serving trafc Data is potentially stale, but, we keep Node 2 up Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service 313. Option 1: Keep Node 2 serving trafc Data is potentially stale, but, we keep Node 2 up We have sacriced consistency for availability Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service 314. Option 2: Remove Node 2 from service Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service 315. Option 2: Remove Node 2 from service Node 1 Master DB Node 2 Slave DB Load BalancerNow we have had to degrade availability to ensure consistency Inventory Service 316. Which is right? 317. What about sacricing Partition Tolerance? 318. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer 319. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer 320. So in general, we talk about CP or AP systems 321. And now, Eventual Consistency 322. Node 1 Node 1 Catalog Service Web Shop Node 1 & 2 will have the same catalog eventually 323. Node 1 Node 1 Catalog Service Web Shop ttl: 5 mins 12:00 Node 1 & 2 will have the same catalog eventually 324. Node 1 Node 1 Catalog Service Web Shop ttl: 5 mins 12:00 Update12:02 Node 1 & 2 will have the same catalog eventually 325. Node 1 Node 1 Catalog Service Web Shop ttl: 5 mins 12:00 Update12:02 ttl: 5 mins 12:03 Node 1 & 2 will have the same catalog eventually 326. http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html 327. You cant beat CAP Theory 328. Its Maths http://lpd.ep.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf 329. http://ferd.ca/beating-the-cap-theorem-checklist.html 330. You entire system doesnt need to be CP or AP! 331. Catalog Web Shop Payment ttl: 5 mins Customer 332. Catalog Web Shop Payment ttl: 5 mins Customer 333. Catalog Web Shop Payment ttl: 5 mins Customer 334. Catalog Web Shop Payment ttl: 5 mins Customer 335. Catalog Web Shop Payment ttl: 5 mins Customer 336. Scary Thought 337. Web Shop Master DB * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx 338. Web Shop Master DB Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx 339. Web Shop Master DB Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx 340. Web Shop Master DB Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx 341. Web Shop Master DB Is this consistent? Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx 342. Web Shop Master DB Is this consistent? Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx We should see this data as a memory* - we see this data as it was, we cant (easily ) be sure what it is now 343. Consistency = locks locks in distributed systems are hard and they are the enemy of scaling 344. https://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf 345. Web Shop Inventory Payment Gateway http://www.ickr.com/photos/63702881@N00/5038034651/ 346. Web Shop Inventory Payment Gateway r http://www.ickr.com/photos/63702881@N00/5038034651/ 347. Web Shop Inventory Payment Gateway r http://www.ickr.com/photos/63702881@N00/5038034651/ 348. Web Shop Inventory Payment Gateway r http://www.ickr.com/photos/63702881@N00/5038034651/ 349. Web Shop Inventory Payment Gateway r http://www.ickr.com/photos/63702881@N00/5038034651/ 350. Transaction Club The rst rule isdont! If you really, really, really have to, consider merging services rst 351. Summary Understand if consistency or availability is important - and this is normally a business decision! It isnt all or nothing Avoid distributed transactions if you can 352. TESTING & DEPLOYING MICROSERVICES Microservices Workshop 60 353. 61 Accounts Returns Invoicing Shipping Inventory Customer Service 354. 61 Accounts Returns Invoicing Shipping Inventory Customer Service 355. 62 356. 62 357. 62 DB 358. 63 Small Medium Large TEST PYRAMID Increasing Scope More Condence Faster! Better Isolation 359. 64 DB Small Large Medium 360. 64 DB Small Large Medium 361. 65 DB Small Large Medium 362. 65 DB Small Large Medium 363. 66 DB Small Large Medium 364. 66 DB Small Large Medium 365. 66 DB Small Large Medium 366. 6767 Small Medium Large TEST SNOWCONE 367. 68 Small Medium Large 368. 69 Small Medium Large Build Tests Tests Source Control BUILD PIPELINE 369. 69 Small Medium Large Build Tests Tests Source Control Faster Feedback BUILD PIPELINE 370. 69 Small Medium Large Build Tests Tests Source Control Faster Feedback Binary Artifact(s) BUILD PIPELINE 371. 69 Small Medium Large Build Tests Tests Source Control Faster Feedback Binary Artifact(s) BUILD PIPELINE 372. 70 DB 373. 70 DB 374. 71 S/M TestsBuild Large Tests UAT Prod 375. 71 S/M TestsBuild Large Tests UAT Prod DB Machine CI Node Large Tests Environment Large Tests 376. 72 S/M TestsBuild Large Tests UAT Prod DB Machine UAT Environment Machine 377. 73 S/M TestsBuild Large Tests UAT Prod Master DB Machine Production Environment Machine Machine Machine Slave DB 378. 74 S/M TestsBuild Large Tests UAT Prod More Production Like 379. 74 S/M TestsBuild Large Tests UAT ProdLarge Tests More Production Like 380. 74 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like 381. 75 Customer Service 382. 75 Customer Service S/M TestsBuild Large Tests 383. 75 Customer Service S/M TestsBuild Large Tests 384. 75 Customer Service S/M TestsBuild Large Tests 385. 76 Customer Service Web Shop Fullment Service 386. 76 Customer Service Web Shop Fullment Service Large Medium Small 387. 77 Customer Service Fullment Service Large Medium Small 388. 77 Customer Service Fullment Service Large Medium Small 389. 77 Customer Service Large Medium Small Fullment Service Stub 390. 78 Mountebank http://www.mbtest.org 391. 79 mountebank :2525 392. 79 mountebank :2525 393. 79 mountebank :2525 :5555 394. 79 mountebank :2525 :5555 Customer Service 395. 80 S/M TestsBuild Large Tests 396. 80 S/M TestsBuild Large Tests Customer Service Fullment Service Stub 397. 81 Customer Service V1 Web Shop Fullment Service 398. 81 Web Shop Customer Service v2 Fullment Service 399. 81 Web Shop Customer Service v2 Fullment Service 400. 81 Web Shop Customer Service v2 Fullment Service 401. 82 S/M TestsBuild Large Tests Customer Service Customer Service v1 Web Shop v1 Production 402. 82 S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v1 Web Shop v1 Production 403. 82 S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v1 Web Shop v1 Production Customer Service v2 Web Shop v1 Integration Test 404. 83 Customer Service v1 Web Shop v1 Production 405. 83 Customer Service v1 Web Shop v1 Production S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v2 406. 83 S/M TestsBuild Large TestsWeb Shop Customer Service v1 Web Shop v1 Production S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v2 407. 83 S/M TestsBuild Large TestsWeb Shop Customer Service v1 Web Shop v1 Production S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v2 Web Shop v2 408. 83 S/M TestsBuild Large TestsWeb Shop Customer Service v1 Web Shop v1 Production S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v2 Web Shop v2 ??? 409. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service 410. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service Integration Test 411. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service Integration Test S/M TestsBuild Large Tests Invoice Service 412. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service Integration Test S/M TestsBuild Large Tests Invoice Service S/M TestsBuild Large TestsBasket 413. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service Integration Test S/M TestsBuild Large Tests Invoice Service S/M TestsBuild Large TestsBasket S/M TestsBuild Large TestsFullment 414. 85 415. 85 Browsers 416. 85 Timing Browsers 417. 85 Provisioning of Environments Timing Browsers 418. 85 Provisioning of Environments Networks Timing Browsers 419. 85 Deployment Provisioning of Environments Networks Timing Browsers 420. 85 Deployment Provisioning of Environments Networks Timing Browsers Diagnosis 421. 86 422. 86 Integration Test 423. 86 Integration Test Prod 424. 86 Integration Test Prod 425. 86 Integration Test Prod 426. 86 Integration Test Prod 427. 87 428. 87 429. 88 John Allspaw: Ops Metametrics http://slidesha.re/dsSZIr 430. 88 John Allspaw: Ops Metametrics http://slidesha.re/dsSZIr 431. 89 Integration Test Prod v1v2 v6 v4 = v10 432. 89 Integration Test Prod v1v2 v6 v4 = v10 433. 90 Danger Will Robinson! 434. 91 Show Tangle 435. 92 Golden Rule: Get good at releasing services independently 436. 93 SO NO INTEGRATION TESTS? 437. 94 438. 94 439. 94 SEMANTIC MONITORING 440. 95 Customer Service Web Shop 441. 95 Customer Service Web Shop Small Medium Large 442. 95 Customer Service Web Shop Small Medium Large 443. 95 Customer Service Web Shop Small Medium Large Consumer Driven Contracts 444. 96 Customer Service Web Shop 445. 96 Customer Service Web Shop Expectations 446. 96 Customer Service Web Shop Expectations 447. 96 Customer Service Web Shop Expectations Prod 448. 96 Customer Service Web Shop Expectations Prod 449. 97 450. 97 https://github.com/realestate-com-au/pact 451. 98 Prod Prod Prod Prod 452. 98 Prod Prod Prod Prod 453. 98 Prod Prod Prod Prod QA 454. 98 Prod Prod Prod Prod QA Good Monitoring 455. 98 Prod Prod Prod Prod QA Good Monitoring Fast Remediation 456. 98 Prod Prod Prod Prod QA Good Monitoring Fast Remediation 457. 99 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like 458. 99 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like 459. 99 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like 460. 100 DB Machine CI Node Large Tests Environment S/M TestsBuild Large Tests UAT ProdLarge TestsLarge Tests 461. 100 DB Machine CI Node Large Tests Environment DB Machine UAT Environment Machine S/M TestsBuild Large Tests UAT ProdLarge Tests UAT 462. 100 DB Machine CI Node Large Tests Environment DB Machine UAT Environment Machine Master DB Machine Production Environment Machine Machine Machine Slave DB S/M TestsBuild Large Tests UAT ProdLarge Tests Prod 463. 101 Faster Feedback More Production Like S/M TestsBuild Large Tests UAT ProdLarge Tests 464. 101 Faster Feedback More Production Like S/M TestsBuild Large Tests UAT ProdLarge Tests 465. 102 466. 103 467. 104 Ansible Puppet Chef 468. 104 Ansible Puppet Chef 469. 104 Ansible Puppet Chef AWS 470. 104 Ansible Puppet Chef AWS Digital Ocean 471. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack 472. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare 473. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant 474. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers 475. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up 476. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up Provider Agnostic 477. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up Provider Agnostic Feedback Can Suer 478. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up Provider Agnostic Feedback Can Suer Cycle Time 479. 105 Prod Prod Prod Prod 480. 105 Prod Prod Prod Prod Packer Images 481. 105 Prod Prod Prod Prod Machine Service Packer Images 482. 105 Prod Prod Prod Prod Machine Service Machine Service Service Packer Images 483. 105 Prod Prod Prod Prod Machine Service Machine Service Service Packer Images 484. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests 485. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS 486. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare 487. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant 488. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant 489. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant 490. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant 491. 107 Machine Service 492. 107 Machine Service Much Easier To Reason About 493. 107 Machine Service Much Easier To Reason About Easier To Provision (Or Decommission) 494. 107 Machine Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-eects 495. 107 Machine Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-eects Cost & Management Overhead! 496. 107 Machine Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-eects Cost & Management Overhead! AWS Digital Ocean OpenStack 497. 107 Machine Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-eects Cost & Management Overhead! AWS Digital Ocean OpenStack 498. 108 STANDARD VIRTUALISATION 499. 108 Machine STANDARD VIRTUALISATION 500. 108 Machine Base OS STANDARD VIRTUALISATION 501. 108 Machine Base OS Hypervisor STANDARD VIRTUALISATION 502. 108 Machine Base OS Hypervisor VM STANDARD VIRTUALISATION 503. 108 Machine Base OS Hypervisor VM OS STANDARD VIRTUALISATION 504. 108 Machine Base OS Hypervisor VM OS Apps STANDARD VIRTUALISATION 505. 108 Machine Base OS Hypervisor VM OS Apps Packer Image STANDARD VIRTUALISATION 506. 108 Machine Base OS Hypervisor VM OS Apps VM OS Apps Packer Image STANDARD VIRTUALISATION 507. 108 Machine Base OS Hypervisor VM OS Apps VM OS Apps VM OS Apps Packer Image STANDARD VIRTUALISATION 508. 109 509. 110 CONTAINER VIRTUALISATION 510. 110 Machine CONTAINER VIRTUALISATION 511. 110 Machine Base OS CONTAINER VIRTUALISATION 512. 110 Machine Base OS Container CONTAINER VIRTUALISATION 513. 110 Machine Base OS Container OS CONTAINER VIRTUALISATION 514. 110 Machine Base OS Container OS Apps CONTAINER VIRTUALISATION 515. 110 Machine Base OS Container OS Apps Container OS Apps CONTAINER VIRTUALISATION 516. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION 517. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION Linux Only 518. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION Same Kernel Linux Only 519. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION Same Kernel Linux OnlyFine-grained control 520. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION Same Kernel Linux OnlyFine-grained control Very fast to provision 521. 111 522. 112 DOCKER 523. 112 DOCKER Machine 524. 112 DOCKER Machine Base OS 525. 112 DOCKER Machine Base OS Docker 526. 112 DOCKER Machine Base OS Docker Apps 527. 112 DOCKER Machine Base OS Docker Apps Apps 528. 112 DOCKER Machine Base OS Docker Apps Apps Apps 529. 112 DOCKER Machine Base OS Docker Apps Apps Apps Docker Image Registry 530. 112 DOCKER Machine Base OS Docker Apps Apps Apps Docker Image Registry 531. 113 532. 113 533. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests 534. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image 535. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image Registry Docker Image 536. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image Registry Docker Image 537. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image Registry Docker Image 538. 115 539. 115 Be aware of - and balance - your test Pyramid 540. 115 Be aware of - and balance - your test Pyramid Understand the balance between testing & rapid remediation 541. 115 Be aware of - and balance - your test Pyramid Understand the balance between testing & rapid remediation Deploy one thing at a time 542. 115 Be aware of - and balance - your test Pyramid Understand the balance between testing & rapid remediation Deploy one thing at a time Consider consumer-driven contracts over integration tests 543. 115 Be aware of - and balance - your test Pyramid Understand the balance between testing & rapid remediation Deploy one thing at a time Consider consumer-driven contracts over integration tests Explore image-based deployments to reduce environment dierences 544. Operational Complexity 545. Alert!!! 546. UP 547. DOWN 548. DOWN 549. DOWN Too slow? 550. UP? 551. UP? DOWN? 552. UP? DOWN? Too slow? Where is the problem? 553. it pushes the accidental complexity into the infrastructure Martin Fowler 554. it pushes the accidental complexity into the infrastructure Martin Fowler monitoring and logging are essential 555. Architectural Safety Measures 556. Every socket, process, pipe, or remote procedure call can and will hang. Even database calls [...]M. Nygard,Release It 557. Cascading Failures Happen when a problem in a service causes a problem in one or more consumers of that service Become a bigger problem with more services (cross more process boundaries) Can a failure in one back-end application take down the entire system (including the parts that dont depend on that back-end)? 558. Failure Types Rejected connections Dropped ACKs Slow responses (these are the nasty ones!) 559. Defense Mechanisms Resource pools Timeouts Circuit breakers Bulkheads Fail fast 560. Circuit Breakers If a service consistently fails, stop calling it for a while! 561. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend The Brakes! 562. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend The Brakes! 563. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend The Brakes! We Cant Rekomend Right Now! 564. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend The Brakes! We Cant Rekomend Right Now! 565. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend The Brakes! 566. Bulkheads = Damage containment Separate resource pools Partitioned servers 567. Fail Fast Check (and perhaps reserve) required resources before processing a request Reject immediately if, say, a circuit breaker has been tripped Allow consumers to query state of service before proceeding (see monitoring later) 568. Monitoring 569. Response time tracking 570. Response time tracking Log aggregation 571. Response time tracking Log aggregation Monitor down-stream dependencies 572. Response time tracking Log aggregation Monitor down-stream dependencies 573. Response time tracking Log aggregation Monitor down-stream dependencies UP? DOWN? Track health 574. For every instance of every service 575. For every instance of every service And you want to standardize 576. For every instance of every service And you want to standardize needs to be status aware 577. source: https://github.com/Netix/Hystrix/wiki/Dashboard remember hystrix? 578. aggregated dashboards 579. Logstash & Kibana 580. ID 123 581. ID 123 ID 123 ID 123 ID 123 582. ID 123 ID 123 ID 123 ID 123 583. ID 123 ID 123 ID 123 ID 123 Correlation IDs 584. Synthetic Transactions 585. How Small? 586. This might be the wrong question 587. How many >> size 588. So how many is too many? 589. From an architectural & operations view... 590. How many >> how small From an architectural & operations view... 591. Pain? 592. Pain? Pain? 593. http://www.ickr.com/photos/oufoufsworld/1233382476/ 594. Summary Complexity doesnt vanish, but with help it can be more evident Monitoring & architectural safety measures are essential! Start with a few services and understand what your appetite is for this new sort of complexity 595. Organisational Structures & Conways Law 596. "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" - Melvin Conway, Dude (HBR rejected the original paper as the thesis wasnt proved) 597. If seven people create a compiler, you get a seven pass compiler - Dan North, not quite a dude 598. http://www.ickr.com/photos/chijs/2869992728/ 599. http://www.ickr.com/photos/noodlepie/7256072798/ 600. High change frequency Fine-grained 601. High change frequency Fine-grained 602. High change frequency Fine-grained Low change frequency Coarse-grained 603. = Pain! 604. http://www.ickr.com/photos/a_ninjamonkey/3565672226/ 605. #123 As a despot when I press the big red button I want... 606. #123 As a despot when I press the big red button I want... 607. Splitting Stories When splitting, try and synchronise the work Consider re-assigning service ownership temporarily Splitting stories across multiple teams is painful... ...so what about shared services? 608. Conways law! 609. #123 As a despot when I press the big red button I want... 610. #123 As a despot when I press the big red button I want... Problems: 611. #123 As a despot when I press the big red button I want... Consistency of XD Problems: 612. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Problems: 613. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Bottlenecks Problems: 614. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Bottlenecks Testing Problems: 615. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Bottlenecks TL, QA, PM Testing Problems: 616. Summary In general assign services to team... ...where team means a co-located group of people Strongly splitting services around organizational boundaries Avoid shared services, instead temporarily re-assign ownership to reduce the need for ne-grained orchestration of work 617. Security 618. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service 619. Authentication Starting point: HTTP Basic Authentication + SSL/TLS It gives us: Condentiality and Integrity guarantees Strong server authentication 620. Why start here? Simple and secure Stable standards with implementations that have been battle hardened Straightforward interop between platforms 621. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service 622. SSL everywhere? 623. Exception 1 Scenario:All data is 100% public information No need for strict authentication or crypto Use API keys to monitor usage. Allows quotas to be applied if needed 624. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service 625. Exception 2 Scenario: I must have strong crypto guarantees for my authentication Use SSL/TLS with client certicates Benet: Strong authentication of client Drawback: PITA to manage 626. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service 627. Exception 3 Scenario: Some/all of the APIs will be consumed by native mobile applications Consider OAuth 2.0 + SSL/TLS Why? OAuth means the mobile app doesnt need to store passwords. It instead stores a token that can be revoked on a per-device basis. 628. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service 629. OAuth 2.0 drawbacks Its a framework, not a protocol Interop isn't guaranteed as not all implementations support all authorisation ows and token types Security pitfalls with some token types (bearer) and ows (implicit) 630. At vs inside perimeter Services that are only consumed by services inside the rewall dont have to use the same mechanism as services that are consumed from outside the rewall If a service is used both inside and outside the perimeter, consider two entry points with different authentication mechanisms 631. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service Form AuthOAuthAPI Key HTTP Basic HTTP Basic HTTP Basic SSL Client Cert 632. Confused deputy Fool downstream service into accessing resource the user shouldnt have access to Harder when lots of services are involved. Need to have sufcient authorisation information available wherever we needed to make an authorisation decision. Usually we make this part of the payload 633. Catalog service Music Web Shop Recommend service Royalty service Mobile app Web browsers User service 634. What about SAML? Over-complicated SOAP focused* Some interop problems Workable if your organisation already has a heavy investment Authorisation tokens can be used to solve the confused deputy problem 635. OpenID Connect Builds on OAuth 2.0, adds an identity layer Reinvents SAML, but HTTP friendly Tokens are no longer opaque strings but can contain claim information The future, not today. Ready in 1-2 years. 636. What about S3 Auth? HMAC-based, uses secret key HTTP Authorization header/status code Benet: No server-side state Drawbacks: No per service/device revocation. Requires canonicalisation. If you want to use it, clone the AWS spec 637. CONCLUSIONS Microservices Workshop 190 638. 191 http://martinfowler.com/articles/microservices.html 639. 192 Sam Newman Building Microservices DESIGNING FINE-GRAINED SYSTEMS 640. 193 641. 194 https://www.ickr.com/photos/futurowoman/2923992303 642. 195 Monitoring Deployment Testing Organisational Structure Integration Architectural Safety 643. 196 Go Incremental