Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Collaboration of (micro-)services

407 views

Published on

Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices.
Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Collaboration of (micro-)services

  1. 1. (Micro-)service collaboration WJAX, Munic, 08th of November 2017 mail@bernd-ruecker.com | @berndruecker With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 2. Simplified example: dash button Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
  3. 3. Basic idea of dedicated, autonomous (micro-) services Checkout Payment Inventory Shipment Dedicated Application Processes Dedicated Persistence Backends Dedicated Development Teams
  4. 4. But: A lot of them… Checkout Payment Inventory Shipment The complexity moves to the collaboration of the services
  5. 5. Distributed systems
  6. 6. My plan for today: Sync -> async -> beyond request/response (just a teaser – mostly live coding)
  7. 7. Live hacking
  8. 8. Circuit Breaker Photo by CITYEDV, available under Creative Commons CC0 1.0 license.
  9. 9. Photo by Pearson Scott Foresman, available under Public Domain license.
  10. 10. Gracefully degrade instead of epic fails!
  11. 11. Ask: who is responsible to deal with problems? Order Credit Card Payment
  12. 12. A good service cares about his sh.. – especially failures. Sometimes it is better to introduce (persistent) state and handle it yourself.
  13. 13. Persist thing with Entity, Actor, … State machine or workflow engine DIY Output Mgmt PDF created How to implement long- running services?
  14. 14. State machines or workflow engines CADENCE Baker
  15. 15. Live hacking
  16. 16. But my customer wants to have the ticket right away!
  17. 17. Finally I get my boarding pass! This can also take days to complete now!
  18. 18. Fallbacks make your system more resilient
  19. 19. Synchronous request/response + Easy to do - Availability erosion, latency creep ~ Requires circuit breaker, retry, fallback, suspension, …
  20. 20. But: Beware of DOS attacks by retries!
  21. 21. Synchronous communication is the crystal meth of distributed programming Todd Montgomery and Martin Thompson in “How did we end up here” at GOTO Chicago 2015
  22. 22. Better asynchronous communication? That typically means: messaging systems.
  23. 23. Operating messaging systems is hard.
  24. 24. You could also ask for work Get work Complete/Fail Work Distribution Service
  25. 25. Live hacking
  26. 26. Design for failure! 2356143672_f5f88797d5_b.jpg Photo by GalaticWanderlust, available under Creative Commons BY 2.0 license.
  27. 27. In general, application developers simply do not implement large scalable applications assuming distributed transactions. When they attempt to use distributed transactions, the projects founder because the performance costs and fragility make them impractical. Natural selection kicks in…
  28. 28. Business transactions can work without two phase commit! Photo by Gerhard51, available under Creative Commons CC0 1.0 license.
  29. 29. The world beyond request/response
  30. 30. Request/Response: temporally coupled services Checkout Payment Inventory Shipment „The button blinks green if we can ship the item within 24 hours!“ Request Response
  31. 31. Events: temporal decoupling with read models Checkout Payment Inventory Shipment „The button blinks green if we can ship the item within 24 hours!“ Events are facts about what happened (in the past) Good Fetched Good Stored Read Model
  32. 32. Events can decrease coupling* *e.g. decentral data-management, read models, …
  33. 33. Events: peer-to-peer event choreographies Checkout Payment Inventory Shipment Order placed Payment received Good shipped „When the button is pressed, an order is placed - and fulfilled!“ Good fetched
  34. 34. Events: peer-to-peer event choreographies Please fetch the goods before waiting for payment Some customers can pay via invoice … Checkout Payment Inventory Shipment Good fetched Order placed Payment received Good shipped
  35. 35. Events can increase coupling* *e.g. complex peer-to-peer event chains
  36. 36. Extract the end-to-end responsibility Order Checkout Payment Inventory Shipment Order placed Retrieve payment Commands have an intent about what needs to happen in the future Please fetch the goods before waiting for payment Some customers can pay via invoice Payment received Retrieve payment
  37. 37. Workflows live inside service boundaries
  38. 38. Example InventoryPaymentOrder ShippingCheckout Monitor https://github.com/flowing/flowing-retail/ Human Tasks
  39. 39. Live hacking
  40. 40. Wrap-up # Understand complexity of distributed systems Sync/async, request/response, event-driven # Know strategies and tools to handle it e.g.Circuit breaker (Hystrix) State machine for visual flow, wait, timeout, retry and compensation (Camunda, Zeebe)
  41. 41. Thank you!
  42. 42. Code: https://github.com/berndruecker Slides: https://bernd-ruecker.com Blog: https://blog.bernd-ruecker.com Feedback: https://bernd-ruecker.com/feedback With thoughts from http://flowing.io @berndruecker | @martinschimak
  43. 43. Images licensed from iStock no attribution required All icons licensed from Noun Project no attribution required Own photos

×