Uploaded byBernd Ruecker
MuCon London 2017: Break your event chains
- The document discusses breaking event chains, decentralizing control, and alternatives to workflow engines for orchestrating microservices. It argues that events can decrease coupling but also increase it, and that central control should be avoided but important long-running capabilities still need ownership. Lightweight workflow engines are presented as a better alternative to DIY orchestration since they address hard problems and can run decentralized.
More Related Content
Similar to MuCon London 2017: Break your event chains
MuCon London 2017: Break your event chains
- 1. Break your eventchains MuCon, November 6th 2017, London mail@bernd-ruecker.com martin.schimak@plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak
- 2. Bernd Rücker Consultant &Dev. Advocate 10+ years workflow Co-founder Camunda http://bernd-ruecker.com/ Martin Schimak Developer & Trainer, 10+ years (de-)coding domain knowledge DDDesign, TDD/BDD, EDA http://plexiti.com/ http://flowing.io/
- 3. 3 common hypotheseswe check today: # Events decrease coupling # Central control needs to be avoided # Workflow engines are painful
- 5. Simplified example: dash button Photoby 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
- 6.
- 7.
- 8. Basic idea ofdedicated, autonomous (micro-) services Checkout Payment Inventory Shipment Dedicated Application Processes Dedicated Persistence Backends Dedicated Development Teams
- 9.
- 10. Request/Response: temporally coupledservices Checkout Payment Inventory Shipment „The button blinks green if we can ship the item within 24 hours!“ Request Response
- 11. Events: temporal decouplingwith 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
- 12. Events: Extract cross-cuttingaspects Checkout Payment Inventory Shipment „Inform the customer about steps he is interested in!“ Order placed Payment received Good shipped Notify me when … Order placed Payment received Good fetched Good shipped Customer Mailings Good fetched
- 13. Events can decreasecoupling* *e.g. decentral data-management, read models, extract cross-cutting aspects
- 14. Events: peer-to-peer eventchoreographies Checkout Payment Inventory Shipment Order placed Payment received Good shipped „When the button is pressed, an order is placed - and fulfilled!“ Good fetched
- 15. Events: peer-to-peer eventchoreographies Fetch the goods before retrieving the payment Some customers can pay via invoice … Checkout Payment Inventory Shipment Good fetched Order placed Payment received Good shipped
- 16. Extract the end-to-endresponsibility Order Checkout Payment Inventory Shipment Order placed Retrieve payment Commands have an intent about what needs to happen in the future Fetch the goods before retrieving the payment Some customers can pay via invoice Payment received Retrieve payment
- 17. Events can increasecoupling* *e.g. complex peer-to-peer event chains
- 18. Commands can decreasecoupling* *e.g. to avoid complex peer-to-peer event chains
- 19. Central control needsto be avoided
- 20.
- 21. Checkout Payment Inventory Shipment Order Dumb pipes „Smart endpointsand dumb pipes!” Martin Fowler
- 22. The danger ofgod services Checkout Payment Inventory Shipment Order „A few smart god services tell anemic CRUD services what to do!” Sam Newman „Central“ order service as bad as central ESB logic?
- 23. A god serviceis only created with bad API design Checkout Payment Inventory Shipment Order „Smart endpoints and dumb pipes!” Martin Fowler Smart endpoints take care of a business capability their client does not need to understand.
- 24. Ask: who isresponsible to deal with problems? Order Credit Card Retrieve Payment Expired A single central client of dumb endpoints becomes a god service. Better: we create several decentral, smart endpoints. „If the credit card expired, the customer gets another chance to provide new card details!“
- 25. Ask: who isresponsible to deal with problems? Order Credit Card „If the credit card expired, the customer gets another chance to provide new card details!“ Expired „Smart endpoints are potentially long-running.” Payment Retrieve Payment Payment received „The client of a smart endpoint remains lean.”
- 26. Be sceptical aboutcentral control!* *e.g. centralized ESB-like components or god services which heavily interact with dumb endpoints
- 27. But don‘t giveup control!* *e.g. miss to extract and control important potentially long-running business capabilities
- 28. The problem isnot to command services! The problem is bad API design.
- 29. Workflow engines arepainful
- 30. Persist thing with Entity,Actor, … State machine or workflow engine DIY Order Credit Card Payment Payment received How to implement long- running services?
- 31.
- 32. Workflow engines solvesome hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
- 33.
- 34. Workflow engines solvesome hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
- 35.
- 38. Bpmn.createProcess("order").executable() //... .sendTask().name("Retrieve payment").camundaClass(RetrievePayme .receiveTask().name("Payment received").message("PaymentReceive //... { "name":"retrieve_payment", "tasks": [ { "name": "Retrieve Payment", "taskReferenceName": "payment", "type": "SIMPLE", ... Do you prefer coded or graphical DSLs? * BPMN - ISO notation for modeling and executing long-running processes and flows
- 39.
- 40.
- 41. Living documentation forlong-running behaviour
- 42. Focus on long-runningbehaviour - requiring state
- 43. A visual HTMLreport for a specific test case
- 44. Workflows live insideservice boundaries
- 45. Explicit flows helpseparate domain and infrastructure Infrastructure Aggregates, Domain Events, Domain Services, etc … + the flow Workflow Engine Payment Application Domain
- 46. Lightweight workflow enginesare great (and much better than DIY)* *e.g. enabling potentially long-running services, solving hard developer problems, can run decentralized
- 47. Workflow engines cando (service) orchestration.* Orchestration is not about synchronous request/response! *We are not talking about container orchestration
- 49. # Events decreasecoupling: sometimes read-models, no complex peer-to-peer event chains, don‘t forget commands # Central control needs to be avoided: sometimes no ESB, smart endpoints/dumb pipes, important capabilities need a home # Workflow engines are painful: some of them lightweight engines are easy to use and can run decentralized, they solve hard developer problems, don‘t DIY
- 50. Need some code? InventoryPaymentOrderShippingCheckout Monitor https://github.com/flowing/flowing-retail/ Human Tasks
- 51.
- 52. Code online: https://github.com/flowing Slides &Blog: https://bernd-ruecker.com https://plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies
- 53. Images licensed fromiStock no attribution required All icons licensed from Noun Project no attribution required Images licensed under Creative Commons license Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/2987 3149904/