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.

Reactive Summit 2020 - How state helps you to stay reactive

Slides from my talk at Reactive Summit November 10th 2020

  • Be the first to comment

  • Be the first to like this

Reactive Summit 2020 - How state helps you to stay reactive

  1. 1. @berndruecker How State Helps you to Stay Reactive Orchestration, Conversations and the Saga Pattern
  2. 2. Setting the scene. Example Checkout Payment Inventory Shipment @berndruecker
  3. 3. Order Placed Payment Received Goods Shipped Notification Event-driven & Reactive @berndruecker Checkout Payment Inventory Shipment
  4. 4. But there is also trouble in reactive land! Event chains that implement processes How to implement long running behavior
  5. 5. Peer-to-peer event chains Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched @berndruecker
  6. 6. Peer-to-peer event chains Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched @berndruecker
  7. 7. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. https://martinfowler.com/articles/201701-event-driven.html @berndruecker
  8. 8. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. https://martinfowler.com/articles/201701-event-driven.html @berndruecker
  9. 9. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. https://martinfowler.com/articles/201701-event-driven.html @berndruecker
  10. 10. Phil Calcado at QCon NYC 2019
  11. 11. Notification Checkout Payment Inventory Shipment Pinball Machine Architecture „What the hell just happened?“ @berndruecker
  12. 12. Peer-to-peer event chains Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched Fetch the goods before the payment @berndruecker
  13. 13. Peer-to-peer event chains Checkout Payment Inventory Shipment Fetch the goods before the payment Goods fetched Order placed Payment received Goods shipped @berndruecker
  14. 14. What we wanted Photo by Lijian Zhang, under Creative Commons SA 2.0 License and Wikimedia Commons / CC BY-SA 4.0 @berndruecker Choreography
  15. 15. Order Decide about responsibility Checkout Payment Inventory ShipmentPayment received Order placed Retrieve payment @berndruecker
  16. 16. Order Decide about responsibility Checkout Payment Inventory ShipmentPayment received Order placed Retrieve payment @berndruecker This is choreography This is orchestration
  17. 17. Order Decide about responsibility Checkout Payment Inventory Shipment Order placed Retrieve payment It can still be messaging! @berndruecker
  18. 18. Order Checkout Payment Inventory Shipment Stateful orchestration This orchestration requires state @berndruecker
  19. 19. Long running behavior
  20. 20. Warning: Contains Opinion @berndruecker
  21. 21. mail@berndruecker.io @berndruecker http://berndruecker.io/ Bernd Ruecker Co-founder and Chief Technologist of Camunda
  22. 22. Order Checkout Payment Inventory Shipment @berndruecker
  23. 23. Glue code (e.g. Java) https://github.com/berndruecker/flowing- retail/blob/master/kafka/java/order- zeebe/src/main/java/io/flowing/retail/kafka/or der/flow/FetchGoodsAdapter.java
  24. 24. Using a workflow engine Workflow Engine Scheduler Durable State Glue Code Whatever you need… Workflow Definition Workflow Engine: Is stateful Can wait Can retry Can escalate Can compensate Provides visibility
  25. 25. Now it is easy to change the process flow @berndruecker
  26. 26. Long Running Capabilities Solve Problems Long Running Technical Process Automation
  27. 27. Long Running Capabilities Solve Problems Long Running Technical Business Process Automation
  28. 28. Example Order Payment Credit Card Retrieve Payment @berndruecker
  29. 29. Example Order Payment Credit Card Retrieve Payment Rejected @berndruecker
  30. 30. Example Order Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Rejected @berndruecker
  31. 31. Payment failed Who is responsible? Order Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Payment received @berndruecker
  32. 32. Payment failed Long running services Order Payment Credit Card Retrieve Payment Rejected Payment received @berndruecker
  33. 33. Long running services Order Payment Credit Card @berndruecker
  34. 34. Extending Payment Options @berndruecker
  35. 35. Extending Payment Options begin commit {local TX} Customer Credit Service begin commit {local TX} Credit Card Service @berndruecker
  36. 36. Distributed transactions using compensation * Compensation @berndruecker
  37. 37. Long Running Capabilities Solve Problems Long Running Technical Business Transactions, Saga Process Automation
  38. 38. Compensation – the classical example Saga book hotel book car book flight cancel hotel cancel car 1. 2. 3. 5.6. In case of failure trigger compensations book trip
  39. 39. 2 alterntive approaches: choreography & orchestration @berndruecker
  40. 40. Event-driven choreography Hotel Flight Car Trip Trip booked Flight booked Trip requested Hotel booked Car booked Request trip @berndruecker
  41. 41. Event-driven choreography Hotel Flight Car Trip Trip failed Trip requested Hotel booked Car booked Request trip Flight failed Car canceled Hotel canceled Perform undo (cancel car booking) Perform undo (cancel hotel) @berndruecker
  42. 42. If your transaction involves 2 to 4 steps, choreography might be a very good fit. However, this approach can rapidly become confusing if you keep adding extra steps in your transaction as it is difficult to track which services listen to which events. Moreover, it also might add a cyclic dependency between services as they have to subscribe to one another’s events. Denis Rosa Couchbase https://blog.couchbase.com/saga-pattern-implement-business-transactions-using-microservices-part/ @berndruecker
  43. 43. Implementing changes in the process Hotel Flight Car Trip Trip failed Trip requested Hotel booked Car booked Request trip Flight failed Car canceled Hotel canceled We have a new basic agreement with the car rental agency and can cancel for free within 1 hour – do that first! @berndruecker
  44. 44. Implementing changes in the process Hotel Flight Car Trip Trip failed Trip requested Hotel booked Car booked Request trip Flight failed Car canceled Hotel canceled You have to adjust all services and redeploy at the same time! We have a new basic agreement with the car rental agency and can cancel for free within 1 hour – do that first! @berndruecker
  45. 45. Orchestration Hotel Flight Car Trip Trip booked Request trip Book hotel Hotel booked Car booked Flight booked Book car Book flight @berndruecker
  46. 46. Orchestration Hotel Flight Car Trip Trip booked Request trip Book hotel Hotel booked Car booked Flight booked Book car Book flight We have a new basic agreement with the car rental agency and can cancel for free within 1 hour – do that first! You have to adjust one service and redeploy only this one! @berndruecker
  47. 47. Describe orchestration with BPMN Trip Trip booked Request trip @berndruecker
  48. 48. Code examples https://github.com/berndruecker/trip-booking-saga-java https://github.com/berndruecker/trip-booking-saga-serverless https://github.com/berndruecker/flowing-trip-booking-saga-c-sharp @berndruecker
  49. 49. The workflow is domain logic as part of the service Trip @berndruecker
  50. 50. The workflow is domain logic as part of the service Trip Payment Payment could be one step in the Trip Saga @berndruecker
  51. 51. Graphical models? @berndruecker
  52. 52. Clemens Vasters Architect at Microsoft http://vasters.com/archive/Sagas.html
  53. 53. Clemens Vasters Architect at Microsoft http://vasters.com/archive/Sagas.html
  54. 54. BPMN Business Process Model and Notation ISO Standard @berndruecker
  55. 55. Living documentation for long-running behaviour @berndruecker
  56. 56. Visual HTML reports for test cases @berndruecker
  57. 57. BizDevOps @berndruecker
  58. 58. Consistency decisions need to be elevated to the business level!
  59. 59. Long Running Capabilities Solve Problems Long Running Technical Business Transactions, Saga Visibility Process Automation
  60. 60. Recap • You need capabilities for long running behavior for technical and business reasons • Workflow engines are a great fit – make sure you use a developer friendly one • Balance Orchestration (coordination) and choreography (reactive) @berndruecker
  61. 61. Want to learn more? https://learning.oreilly.com/get-learning/?code=PPAER20
  62. 62. Thank you! @berndruecker
  63. 63. mail@berndruecker.io @berndruecker https://berndruecker.io https://medium.com/berndruecker https://github.com/berndruecker https://www.infoq.com/articles/events- workflow-automation Contact: Slides: Blog: Code: https://www.infoworld.com/article/3254777/ application-development/ 3-common-pitfalls-of-microservices- integrationand-how-to-avoid-them.html https://thenewstack.io/5-workflow-automation- use-cases-you-might-not-have-considered/

×