Agile Australia 2014: Workshop - Design and Implementation of Microservices
•
7 likes•1,340 views
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.
Recommended
Recommended
More Related Content
Similar to Agile Australia 2014: Workshop - Design and Implementation of Microservices
Similar to Agile Australia 2014: Workshop - Design and Implementation of Microservices (20)
Recently uploaded
Recently uploaded (20)
Agile Australia 2014: Workshop - Design and Implementation of Microservices
- 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 • Conway’s Law • Security
- 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
- 15. 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
- 16. we have to rewrite entire ecosystems every few years
- 17. we have to rewrite entire ecosystems every few years this doesn’t make many CFO’s happy
- 18. scary story
- 22. Retail Site Departure Control 48 Cores ! 256 GB RAM (NUMA) ! ~ $1 x 106 per machine
- 23. 22
- 24. Airline Tightly coupled “Golden Hammer Syndrome” Single point of failure Expensive to scale High operational cost High cost of failure
- 25. 24
- 30. scary story
- 31. 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 ?
- 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 ? 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
- 36. 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 Difficult to predict the effect of changes Which system is right? BI / MI almost impossible to get at
- 39. V1
- 40. V2
- 46. Why now?
- 49. standing on the shoulders of giants
- 51. Engineering for: reliability and availability Devops circuit breakers, health checks, status pages
- 52. Strategic Design Bounded Contexts “town planning”
- 54. infrastructure automation patterns for push button deployments the lean software value stream
- 56. 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
- 66. towns are zoned
- 67. heavy industrial
- 68. commercial
- 71. Would you build a playground next to a power station?
- 72. Would you build a playground next to a power station?
- 73. Would you build a playground next to a power station? a sewage works next to Macy’s?
- 76. Everyone uses 240V DC right?
- 78. and it would be a bad idea not to use the same language for stop signs...
- 81. emergent design is within the zones
- 82. emergent design is within the zones
- 83. evolutionary architecture is in the gaps emergent design is within the zones
- 84. evolutionary architecture is in the gaps emergent design is within the zones
- 85. • 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?
- 86. it can be a single system and its component parts or chunking up to how your systems integrate with others and if you can’t remember thats ok too, we don’t want perfect, just something to work with
- 87. Summary do just enough up front evolutionary architecture is in the gaps emergent design is in the boxes
- 88. Bounded Contexts
- 89. What makes a good service?
- 90. High Cohesion
- 91. Loose Coupling
- 92. The Trifle
- 104. “A set of capabilities on an endpoint”
- 106. Bounded Context
- 107. "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."
- 108. A specific responsibility enforced by explicit boundaries ! http://www.sapiensworks.com/blog/post/ 2012/04/17/DDD-The-Bounded-Context- Explained.aspx
- 117. Add to cart
- 118. Add to cart Checkout
- 119. Add to cart Checkout View Latest Releases
- 120. Add to cart Checkout View Latest Releases Search
- 121. Add to cart Checkout View Latest Releases Search Listen To Previews
- 122. Add to cart Checkout View Latest Releases Search Listen To Previews
- 123. Add to cart Checkout View Latest Releases Search Listen To Previews Shopping Cart Catalog Music Library
- 124. Hexagonal Architectures 83 bounded contexts all the way down (and back up again)
- 128. Object James’ conjecture “objects should be no bigger than my head”
- 129. Object
- 133. as we chunk up domains of abstraction, each domain should be small enough to fit in my head
- 134. 93 in this case, it meant 100’s of lines of code per application
- 136. to build systems is to make trade-offs
- 137. to build systems is to make trade-offs throughput vs cost
- 138. to build systems is to make trade-offs throughput vs cost
- 139. to build systems is to make trade-offs throughput vs cost portability vs deployability
- 140. to build systems is to make trade-offs throughput vs cost portability vs deployability
- 141. to build systems is to make trade-offs throughput vs cost portability vs deployability replacability vs maintainability
- 142. to build systems is to make trade-offs throughput vs cost portability vs deployability replacability vs maintainability evolutionary architecture and emergent design are approaches that maximise flex
- 143. you want to maximise the degrees of freedom of your system
- 144. The idea of architecture principles is to try and balance these tradeoffs
- 145. to try and balance short term gain with longer term strategic goals The idea of architecture principles is to try and balance these tradeoffs
- 146. to try and balance short term gain with longer term strategic goals The idea of architecture principles is to try and balance these tradeoffs
- 147. 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
- 148. 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
- 149. 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 don’t happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffs
- 150. 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 don’t happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffs They should be driven by the goals of the business
- 151. 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 don’t happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffs They should be driven by the goals of the business
- 152. 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 don’t happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffs They should be driven by the goals of the business for the next 18-24 months
- 153. 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 don’t happen so often or have such large impact The idea of architecture principles is to try and balance these tradeoffs They should be driven by the goals of the business for the next 18-24 months any longer and you are only fooling yourself
- 154. and if you don’t know what your business goals are...
- 155. and if you don’t know what your business goals are... may we respectfully suggest that you go and find them out!
- 157. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework
- 158. The idea of constraints is to allow your teams the freedom to make decisions within a consistent framework
- 159. 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
- 160. 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
- 161. 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
- 162. 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?
- 168. Heroku’s 12 factors are a mixture of principles and constraints http://www.12factor.net/
- 171. never return directly from a POST
- 172. favour choreography over orchestration never return directly from a POST
- 173. favour choreography over orchestration don’t share domain code (and physically separate the codebases to ensure this) never return directly from a POST
- 174. favour choreography over orchestration don’t share domain code (and physically separate the codebases to ensure this) scale using processes, not threads never return directly from a POST
- 175. favour choreography over orchestration don’t share domain code (and physically separate the codebases to ensure this) scale using processes, not threads don’t use session state never return directly from a POST
- 176. Integration
- 177. or…
- 178. Avoiding Babel
- 179. Two Key Attributes Of A Good Service
- 180. 1. High Cohesion ! 2. Loose Coupling
- 181. 1. High Cohesion ! 2. Loose Coupling
- 182. © 2013 Electronic Arts Inc.
- 184. Integration Styles An Evolutionary View Data Oriented Procedure Oriented Document Oriented Resource Oriented
- 185. Databases
- 186. DB MusikShopMono
- 190. DB Schema Recomendation ServiceMusicShopMono No loose coupling!
- 191. DB Schema Recomendation Service MusicShopMono DB Schema Magic ETL
- 192. which is ok until...
- 193. 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...
- 194. 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
- 195. 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
- 196. 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 ?
- 197. 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 ?
- 198. systems like this are brittle difficult 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 ?
- 199. systems like this are brittle difficult to reason about difficult 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 ?
- 200. systems like this are brittle difficult to reason about difficult to change difficult 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 ?
- 201. Next!
- 202. RPC
- 203. method calls across a process boundary
- 204. consider a client invoking the createUser endpoint
- 205. consider a client invoking the createUser endpoint
- 206. createUser(id, ! firstName, ! lastName,! address) consider a client invoking the createUser endpoint
- 207. other clients can use the same call as the first createUser(id, ! firstName, ! lastName,! address)
- 208. other clients can use the same call as the first createUser(id, ! firstName, ! lastName,! address) so far so good
- 209. but what happens when you want to change how one of the clients calls your service?
- 210. but what happens when you want to change how one of the clients calls your service? maybe I don’t want to use first name and last name anymore
- 211. I want to use the ‘fullname’ createUser(id, ! firstName, ! lastName,! address) createUserByFullname(! id, ! fullName,! address)
- 212. or I want to specify address individually createUser(id, ! firstName, ! lastName,! address) createUserByFullname(! id, ! fullName,! address) createUserByFullnameAnd Address(! id, ! fullName,! street1,! street2,! zipcode)
- 213. one of two things tends to happen with systems of this type
- 214. one of two things tends to happen with systems of this type 1. you end up with very long service definitions
- 215. one of two things tends to happen with systems of this type 1. you end up with very long service definitions 2. coordination of changes to clients becomes difficult
- 216. 1. specifications quickly become very very long and a nightmare to maintain
- 217. 1. specifications quickly become very very long and a nightmare to maintain createUserWithFullname(...)
- 218. 1. specifications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...)
- 219. 1. specifications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...) createUserWithFullnameAndAddress (...)
- 220. 1. specifications quickly become very very long and a nightmare to maintain createUserWithFullname(...) createUser(...) createUserWithFullnameAndAddress (...) createUserWithAddress(...)
- 221. 1. specifications 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
- 222. 2. you have to coordinate the release cycles of your clients createUser(id, ! firstName, ! lastName,! address)
- 223. createUser(id, ! firstName, ! lastName,! address) createUser(id, ! fullname, ! address) @deprecated 2. you have to coordinate the release cycles of your clients
- 224. 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
- 225. A Brief Aside…
- 226. Who can tell me about RFC 761?
- 228. Postel’s Law: “Be liberal in what you do, conservative in what you expect”
- 229. Practical impact of this - only bind to what you need to reduce breaking service consumption
- 230. Service B Service A Shared Lib v1 Shared Lib v1
- 231. Service B Service A Shared Lib v1 Shared Lib v1
- 232. Service B Service A Shared Lib v1 Shared Lib v1
- 233. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2
- 234. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols
- 235. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols WSDL-binding
- 236. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols WSDL-binding JAXB
- 237. Service B Service A Shared Lib v1 Shared Lib v1 Shared Lib v2 Beware of shared serialization protocols WSDL-binding JAXB Java Serialization
- 238. Messaging
- 239. (AMC / Associated Press)
- 240. a bit like going back to the 50’s enterprise (AMC / Associated Press)
- 241. a bit like going back to the 50’s enterprise except without the smoking and the rampant misogyny (AMC / Associated Press)
- 242. back in the day, if you wanted to book a holiday, you didn’t go onto your corporate intranet to do it right?
- 243. back in the day, if you wanted to book a holiday, you didn’t go onto your corporate intranet to do it right? you went to the cupboard
- 244. back in the day, if you wanted to book a holiday, you didn’t go onto your corporate intranet to do it right? you went to the cupboard and you pulled out one of these
- 245. back in the day, if you wanted to book a holiday, you didn’t go onto your corporate intranet to do it right? you went to the cupboard and you pulled out one of these and you filled it in
- 246. james’ holiday request form and then you sent it to the HR department
- 247. 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
- 248. and messaging is a bit like that
- 249. and messaging is a bit like that asynchronous
- 250. and messaging is a bit like that asynchronous after all, you wouldn’t want to block waiting for internal mail right?
- 251. incidentally, I wasn’t actually there in the 50’s. I just have this on good authority and messaging is a bit like that asynchronous after all, you wouldn’t want to block waiting for internal mail right?
- 252. generally you create a message composed of a document
- 253. and you push it onto some kind of queue
- 254. and you push it onto some kind of queue
- 255. systems interested in your documents can pop those documents and act on them
- 256. systems interested in your documents can pop those documents and act on them
- 257. and return them should that be the semantics of the exchange
- 259. the documents allowed additive changes to be made without breaking existing clients
- 260. the documents allowed additive changes to be made without breaking existing clients If you want to add a field, you can do so as long as clients are late bound to the documents
- 261. the documents allowed additive changes to be made without breaking existing clients If you want to add a field, 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)
- 262. and the asynchronous nature decouples the applications from each other
- 263. and the asynchronous nature decouples the applications from each other
- 264. and the asynchronous nature decouples the applications from each other you can change this
- 265. and the asynchronous nature decouples the applications from each other you can change this without breaking this
- 266. of course, there is a teensy bit more to it than that...
- 267. 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
- 268. Getting async comms right can be hard!
- 269. And can require the dreaded ‘middleware’
- 270. The ESB!
- 273. So when to use it?
- 274. So when to use it? Long-running jobs
- 275. So when to use it? Long-running jobs Alternative scaling
- 276. So when to use it? Long-running jobs Alternative scaling Resiliency
- 277. So when to use it? Long-running jobs Alternative scaling Resiliency Broadcast
- 278. So when to use it? Long-running jobs Alternative scaling Resiliency Broadcast Low-latency
- 279. Next!
- 280. Let’s take a look at the world’s most successful, distributed, scalable computing system for some tips
- 283. Client cache Proxy cache CDN Infrastructure caches Reverse proxy cache
- 286. HTTP -> REST!
- 289. Level 0 - POX single service endpoint, many methods
- 290. createUserWithFullname(...) Level 0 - POX single service endpoint, many methods
- 291. createUserWithFullname(...) createUser(...) Level 0 - POX single service endpoint, many methods
- 292. createUserWithFullname(...) createUser(...) updateUserById(...) Level 0 - POX single service endpoint, many methods
- 293. createUserWithFullname(...) createUser(...) updateUserById(...) updateUserByFullName(...) Level 0 - POX single service endpoint, many methods
- 294. createUserWithFullname(...) createUser(...) updateUserById(...) updateUserByFullName(...) deleteUserById(...) Level 0 - POX single service endpoint, many methods
- 295. createUserWithFullname(...) createUser(...) updateUserById(...) updateUserByFullName(...) deleteUserById(...) Level 0 - POX single service endpoint, many methods findUserById(...)
- 296. • Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.
- 297. Level 1 - resources
- 298. Level 1 - resources
- 299. ! ! • Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation.
- 300. Level 2 - HTTP verbs
- 301. Level 2 - HTTP verbs getUserById(...)
- 302. Level 2 - HTTP verbs getUserById(...) GET /users/f3c2ac
- 303. • Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.
- 306. Basket!
- 307. What if consumers of a service could act in the same way?
- 308. scottwshaw / gist:ee875a6018e1676b36ad Last active 22 minutes ago 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 var jsonpath = require('JSONPath'); var version1 = {"results": {"link": {"uri": "http://musikshop.com/search/artist=the%20brakes", "rel": "self"}, "releases": [{"release": "Tale of Two Cities", "year": "2008", "link": {"uri": "http://musikshop.com/api/cmVsZWFzZXMvMQ==", "rel": "http://musikshop.com/rels/release"}}, {"release": "The Brakes", "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
- 309. 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 var jsonpath = require('JSONPath'); var version2 = {"results": { "link": {"uri": "http://musikshop.com/search/artist=the%20brakes", "rel": "http://musikshop.com/rels/self"}, "fullLengthReleases": [{"release": "Tale of Two Cities", "year": "2008", "link": {"uri": "http://musikshop.com/api/cmVsZWFzZXMvMQ==", "rel": "http://musikshop.com/rels/release"}}], "EPReleases": [{"release": "The Brakes", "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
- 310. In practice most people end up here Aim high!
- 311. This stuff is hard to change later - so do your research and pick principles that make sense for you
- 313. Summary • REST over HTTP is best - aim high! • Messaging is cool, but can be hard • Whatever you do, think lazy binding!
- 314. How To Split Services
- 316. Add to cart
- 317. Add to cart Checkout
- 318. Add to cart Checkout View Latest Releases
- 319. Add to cart Checkout View Latest Releases Search
- 320. Add to cart Checkout View Latest Releases Search Listen To Previews
- 321. Add to cart Checkout View Latest Releases Search Listen To Previews
- 322. Add to cart Checkout View Latest Releases Search Listen To Previews Shopping Cart Catalog Music Library
- 325. MusikShopMono
- 327. That was the easy bit
- 328. Enter the DB
- 330. DB MusikShopMono
- 341. Catalog Finance Line Items Ledger MusikShopMono
- 342. Catalog Finance Line Items Ledger MusikShopMono
- 343. Catalog Finance Line Items Ledger MusikShopMono
- 344. Catalog Finance Line Items Ledger MusikShopMono
- 345. Catalog Finance Line Items Ledger MusikShopMono
- 348. MusikShop System Line Items Finance ServiceCatalog Service
- 349. MusikShop System Line Items Ledger Finance ServiceCatalog Service
- 351. Catalog Finance Warehouse Country Codes Country Codes Country Codes MusikShopMono
- 354. reify
- 360. Catalog Warehouse Item MusikShop Bee Gees Hits | $4.99 | 45
- 361. Catalog Warehouse Item MusikShop Bee Gees Hits | $4.99 | 45
- 362. Catalog Warehouse Item MusikShop Bee Gees Hits | $4.99 | 45
- 363. Catalog Warehouse Catalog Item MusikShop Stock Levels
- 368. DB
- 369. DB Cost Of Change
- 370. @samnewman Summary • Split around bounded contexts • Make small, incremental changes • Split inside the process boundary before splitting out services • Start coarse-grained
- 371. CAP Theory
- 373. What is CAP theory?
- 374. 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)
- 375. 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
- 376. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer
- 377. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer
- 378. Option 1: Keep Node 2 serving traffic Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service
- 379. Option 1: Keep Node 2 serving traffic Data is potentially stale, but, we keep Node 2 up Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service
- 380. Option 1: Keep Node 2 serving traffic Data is potentially stale, but, we keep Node 2 up We have sacrificed consistency for availability Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service
- 381. Option 2: Remove Node 2 from service Node 1 Master DB Node 2 Slave DB Load Balancer Inventory Service
- 382. 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
- 383. Which is right?
- 384. What about sacrificing Partition Tolerance?
- 385. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer
- 386. Node 1 Inventory Service Master DB dc1 Node 2 Slave DB dc2 Load Balancer
- 387. So in general, we talk about CP or AP systems
- 389. Node 1 Node 1 Catalog Service Web Shop Node 1 & 2 will have the same catalog ‘eventually’
- 390. Node 1 Node 1 Catalog Service Web Shop ttl: 5 mins 12:00 Node 1 & 2 will have the same catalog ‘eventually’
- 391. Node 1 Node 1 Catalog Service Web Shop ttl: 5 mins 12:00 Update12:02 Node 1 & 2 will have the same catalog ‘eventually’
- 392. 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’
- 394. You can’t beat CAP Theory
- 397. You entire system doesn’t need to be CP or AP!
- 398. Catalog Web Shop Payment ttl: 5 mins Customer
- 399. Catalog Web Shop Payment ttl: 5 mins Customer
- 400. Catalog Web Shop Payment ttl: 5 mins Customer
- 401. Catalog Web Shop Payment ttl: 5 mins Customer
- 402. Catalog Web Shop Payment ttl: 5 mins Customer
- 403. Scary Thought
- 404. Web Shop Master DB * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx
- 405. Web Shop Master DB Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx
- 406. Web Shop Master DB Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx
- 407. Web Shop Master DB Let us consider a read * - http://blogs.msdn.com/b/pathelland/archive/2007/05/15/memories-guesses-and-apologies.aspx
- 408. 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
- 409. 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 can’t (easily ) be sure what it is now
- 411. Consistency = locks locks in distributed systems are hard and they are the enemy of scaling
- 418. Transaction Club • The first rule is…don’t! • If you really, really, really have to, consider merging services first
- 419. Summary • Understand if consistency or availability is important - and this is normally a business decision! • It isn’t all or nothing • Avoid distributed transactions if you can
- 423. 62
- 424. 62
- 425. 62 DB
- 426. 63 Small Medium Large TEST PYRAMID Increasing Scope More Confidence Faster! Better Isolation
- 438. 69 Small Medium Large Build Tests Tests Source Control Faster Feedback Binary Artifact(s) … BUILD PIPELINE
- 439. 69 Small Medium Large Build Tests Tests Source Control Faster Feedback Binary Artifact(s) … BUILD PIPELINE
- 440. 70 DB
- 441. 70 DB
- 442. 71 S/M TestsBuild Large Tests UAT Prod
- 443. 71 S/M TestsBuild Large Tests UAT Prod DB Machine CI Node Large Tests Environment Large Tests
- 444. 72 S/M TestsBuild Large Tests UAT Prod DB Machine UAT Environment Machine
- 445. 73 S/M TestsBuild Large Tests UAT Prod Master DB Machine Production Environment Machine Machine Machine Slave DB
- 446. 74 S/M TestsBuild Large Tests UAT Prod More Production Like
- 447. 74 S/M TestsBuild Large Tests UAT ProdLarge Tests More Production Like
- 448. 74 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like
- 449. 75 Customer Service
- 450. 75 Customer Service S/M TestsBuild Large Tests
- 451. 75 Customer Service S/M TestsBuild Large Tests
- 452. 75 Customer Service S/M TestsBuild Large Tests
- 459. 79 mountebank :2525
- 460. 79 mountebank :2525
- 463. 80 S/M TestsBuild Large Tests
- 464. 80 S/M TestsBuild Large Tests Customer Service Fulfilment Service Stub
- 469. 82 S/M TestsBuild Large Tests Customer Service Customer Service v1 Web Shop v1 Production
- 470. 82 S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v1 Web Shop v1 Production
- 471. 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
- 473. 83 Customer Service v1 Web Shop v1 Production S/M TestsBuild Large Tests Integration Test Customer Service Customer Service v2
- 474. 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
- 475. 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
- 476. 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 ???
- 477. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service
- 478. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service Integration Test
- 479. 84 S/M TestsBuild Large TestsWeb Shop S/M TestsBuild Large Tests Customer Service Integration Test S/M TestsBuild Large Tests Invoice Service
- 480. 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
- 481. 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 TestsFulfilment
- 482. 85
- 483. 85 Browsers
- 484. 85 Timing Browsers
- 489. 86
- 490. 86 Integration Test
- 495. 87
- 496. 87
- 497. 88 John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr
- 498. 88 John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr
- 499. 89 Integration Test Prod… v1v2 v6 v4 = v10
- 500. 89 Integration Test Prod… v1v2 v6 v4 = v10
- 502. 91 Show Tangle
- 503. 92 Golden Rule: Get good at releasing services independently
- 504. 93 SO NO INTEGRATION TESTS?
- 505. 94
- 506. 94
- 517. 97
- 525. 99 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like
- 526. 99 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like
- 527. 99 S/M TestsBuild Large Tests UAT ProdLarge Tests Faster Feedback More Production Like
- 528. 100 DB Machine CI Node Large Tests Environment S/M TestsBuild Large Tests UAT ProdLarge TestsLarge Tests
- 529. 100 DB Machine CI Node Large Tests Environment DB Machine UAT Environment Machine S/M TestsBuild Large Tests UAT ProdLarge Tests UAT
- 530. 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
- 531. 101 Faster Feedback More Production Like S/M TestsBuild Large Tests UAT ProdLarge Tests
- 532. 101 Faster Feedback More Production Like S/M TestsBuild Large Tests UAT ProdLarge Tests
- 533. 102
- 534. 103
- 543. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up
- 544. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up Provider Agnostic
- 545. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up Provider Agnostic Feedback Can Suffer
- 546. 104 Ansible Puppet Chef AWS Digital Ocean OpenStack VMWare Vagrant Immutable Servers Fast Spin-up Provider Agnostic Feedback Can Suffer Cycle Time
- 552. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests
- 553. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS
- 554. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare
- 555. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant
- 556. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant
- 557. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant
- 558. 106 S/M TestsBuild Large Tests UAT ProdLarge Tests AWS VMWare Vagrant
- 560. 107 “Machine” Service Much Easier To Reason About
- 561. 107 “Machine” Service Much Easier To Reason About Easier To Provision (Or Decommission)
- 562. 107 “Machine” Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-effects
- 563. 107 “Machine” Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-effects Cost & Management Overhead!
- 564. 107 “Machine” Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-effects Cost & Management Overhead! AWS Digital Ocean OpenStack
- 565. 107 “Machine” Service Much Easier To Reason About Easier To Provision (Or Decommission) Fewer Side-effects Cost & Management Overhead! AWS Digital Ocean OpenStack
- 573. 108 Machine Base OS Hypervisor VM OS Apps Packer Image STANDARD VIRTUALISATION
- 574. 108 Machine Base OS Hypervisor VM OS Apps VM OS Apps Packer Image STANDARD VIRTUALISATION
- 575. 108 Machine Base OS Hypervisor VM OS Apps VM OS Apps VM OS Apps Packer Image STANDARD VIRTUALISATION
- 576. 109
- 584. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION
- 586. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION Same Kernel Linux Only
- 587. 110 Machine Base OS Container OS Apps Container OS Apps Container OS Apps CONTAINER VIRTUALISATION Same Kernel Linux OnlyFine-grained control
- 588. 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
- 589. 111
- 590. 112 DOCKER
- 591. 112 DOCKER Machine
- 597. 112 DOCKER Machine Base OS Docker Apps Apps Apps Docker Image Registry
- 598. 112 DOCKER Machine Base OS Docker Apps Apps Apps Docker Image Registry
- 599. 113
- 600. 113
- 601. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests
- 602. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image
- 603. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image Registry Docker Image
- 604. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image Registry Docker Image
- 605. 114 S/M TestsBuild Large Tests UAT ProdLarge Tests Docker Image Registry Docker Image
- 606. 115
- 607. 115 Be aware of - and balance - your test Pyramid
- 608. 115 Be aware of - and balance - your test Pyramid Understand the balance between testing & rapid remediation
- 609. 115 Be aware of - and balance - your test Pyramid Understand the balance between testing & rapid remediation Deploy one thing at a time
- 610. 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
- 611. 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 differences
- 619. Alert!!!
- 627. UP
- 628. DOWN
- 629. DOWN
- 630. DOWN Too slow?
- 633. UP?
- 634. UP? DOWN?
- 635. UP? DOWN? Too slow? Where is the problem?
- 637. “it pushes the accidental complexity into the infrastructure” Martin Fowler
- 638. “it pushes the accidental complexity into the infrastructure” Martin Fowler monitoring and logging are essential
- 641. “Every socket, process, pipe, or remote procedure call can and will hang. Even database calls [...]” M. Nygard,“Release It”
- 642. 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 don’t depend on that back-end)?
- 643. Failure Types • Rejected connections • Dropped ACKs • Slow responses (these are the nasty ones!)
- 644. Defense Mechanisms • Resource pools • Timeouts • Circuit breakers • Bulkheads • Fail fast
- 645. Circuit Breakers • If a service consistently fails, stop calling it for a while!
- 646. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend ‘The Brakes’!
- 647. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend ‘The Brakes’!
- 648. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend ‘The Brakes’! We Can’t Rekomend Right Now!
- 649. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend ‘The Brakes’! We Can’t Rekomend Right Now!
- 650. MusikShop v1 Rekomender v124 www.MusikShop Take That Queens Of The Stone Age Snoop Dogg We Rekomend ‘The Brakes’!
- 651. Bulkheads • = Damage containment • Separate resource pools • Partitioned servers
- 652. 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)
- 653. Monitoring
- 658. Response time tracking Log aggregation
- 659. Response time tracking Log aggregation Monitor down-stream dependencies
- 660. Response time tracking Log aggregation Monitor down-stream dependencies
- 661. Response time tracking Log aggregation Monitor down-stream dependencies UP? DOWN? Track health
- 663. For every instance of every service…
- 664. For every instance of every service… And you want to standardize
- 665. For every instance of every service… And you want to standardize …needs to be status aware
- 672. Logstash & Kibana
- 674. ID 123
- 675. ID 123 ID 123 ID 123 ID 123
- 676. ID 123 ID 123 ID 123 ID 123
- 677. ID 123 ID 123 ID 123 ID 123 Correlation IDs
- 682. How Small?
- 683. This might be the wrong question
- 684. How many >> size
- 685. So how many is too many?
- 686. From an architectural & operations view...
- 687. How many >> how small From an architectural & operations view...
- 692. Pain?
- 693. Pain? Pain?
- 695. Summary • Complexity doesn’t 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
- 697. "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 wasn’t proved)
- 698. “If seven people create a compiler, you get a seven pass compiler” - Dan North, not quite a dude
- 707. = Pain!
- 713. #123 As a despot when I press the big red button I want...
- 714. #123 As a despot when I press the big red button I want...
- 715. 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?
- 718. Conway’s law!
- 719. #123 As a despot when I press the big red button I want...
- 720. #123 As a despot when I press the big red button I want... Problems:
- 721. #123 As a despot when I press the big red button I want... Consistency of XD Problems:
- 722. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Problems:
- 723. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Bottlenecks Problems:
- 724. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Bottlenecks Testing Problems:
- 725. #123 As a despot when I press the big red button I want... Consistency of XD Sequencing Bottlenecks TL, QA, PM Testing Problems:
- 726. 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 fine-grained orchestration of work
- 727. Security
- 730. Authentication • Starting point: HTTP Basic Authentication + SSL/TLS • It gives us: • Confidentiality and Integrity guarantees • Strong server authentication
- 731. Why start here? • Simple and secure • Stable standards with implementations that have been battle hardened • Straightforward interop between platforms
- 733. SSL everywhere?
- 734. 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
- 736. Exception 2 • Scenario: I must have strong crypto guarantees for my authentication • Use SSL/TLS with client certificates • Benefit: Strong authentication of client • Drawback: PITA to manage
- 738. 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 doesn’t need to store passwords. It instead stores a token that can be revoked on a per-device basis.
- 740. OAuth 2.0 drawbacks • It’s a “framework”, not a protocol • Interop isn't guaranteed as not all implementations support all authorisation flows and token types • Security pitfalls with some token types (bearer) and flows (implicit)
- 741. At vs inside perimeter • Services that are only consumed by services inside the firewall don’t have to use the same mechanism as services that are consumed from outside the firewall • If a service is used both inside and outside the perimeter, consider two entry points with different authentication mechanisms
- 742. 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
- 743. Confused deputy • Fool downstream service into accessing resource the user shouldn’t have access to • Harder when lots of services are involved. • Need to have sufficient authorisation information available wherever we needed to make an authorisation decision. • Usually we make this part of the payload
- 745. 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
- 746. 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.
- 747. What about S3 Auth? • HMAC-based, uses “secret key” • HTTP Authorization header/status code • Benefit: No server-side state • Drawbacks: No per service/device revocation. Requires canonicalisation. • If you want to use it, clone the AWS spec
- 751. 193
- 754. 196 Go Incremental