WJAX Munich 2017: Break your event chains!

https://jax.de/microservices/break-your-event-chains/

Transcript

1. Break your event chains! W-JAX, November 8th, 2017, Munich martin.schimak@plexiti.com With thoughts from http://flowing.io @martinschimak | @berndruecker
2. 3 common hypotheses we check today… 1. Events decrease coupling! 2. Central control should be avoided! 3. Workflow engines are painful!
4. Simplified example: a dash button Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
5. Three steps…
6. Who is involved? Checkout Payment Inventory Shipment
7. Basic idea of dedicated, autonomous (micro-) services Checkout Payment Inventory Shipment Dedicated Application Processes Dedicated Persistence Backends Dedicated Development Teams
8. Events decrease coupling!
9. Request/Response: temporally coupled services Checkout Payment Inventory Shipment „The button blinks green if we can ship the item within 24 hours!“ Request Response
10. 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
11. Events: extracting or adding cross-cutting aspects Checkout Payment Inventory Shipment „Inform the customer about steps s/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
12. Events can decrease coupling!* *e.g. when used to generate read models or to extract cross-cutting aspects
13. Events: peer-to-peer choreographies Checkout Payment Inventory Shipment Order placed Payment received Good shipped „When the button is pressed, an order is placed - and fulfilled!“ Good fetched
14. Events: peer-to-peer 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
15. Extracting 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
16. Events can increase coupling* *e.g. complex peer-to-peer event chains
17. Commands can decrease coupling, too!* *e.g. when used to avoid complex peer-to-peer event chains
18. Are you Event- or Command-Oriented?
19. Central control should be avoided!
20. Checkout Payment Inventory Shipment Order Order placed Payment received Good fetched Good shipped Smart ESB-like middleware
21. Checkout Payment Inventory Shipment Order „Dumb“ messaging „Smart endpoints and dumb pipes!” Martin Fowler
22. The danger of god 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 service is created by bad APIs Checkout Payment Inventory Shipment Order „Smart endpoints and dumb pipes!” Martin Fowler Checkout Payment Inventory Shipment Smart endpoints take care of a business capability their client does not need to understand.
24. Ask: who is responsible to deal with problems? Order Credit Card Retrieve Payment Expired The client of a dumb service is forced to deal with problems which may actually be none of his business. „If the credit card expired, the customer gets another chance to provide new card details!“
25. Ask: who is responsible to deal with problems? Order Credit Card „If the credit card expired, the customer gets another chance to provide new card details!“ Expired Smart services are potentially long-running. Payment Retrieve Payment Payment received The client of a smart service remains lean.
26. Be skeptical about central control!* *e.g. when used as ESB-like „smart pipes“or when „god services“ heavily interact with dumb endpoints
27. But don‘t give up any form of „central“ control!* *e.g. by missing to extract important business capabilities which are better dealt with by dedicated, „smart“ services
28. Do you like or dislike central control? Berlin Munich
29. Do you like or dislike central control? Brussels Berlin Munich @martinschimak J
30. Workflow engines are painful!
31. Workflow and BPM
32. … and death by properties panel The story of BPM: Shiny vendors promised zero-code … proprietary, alien like tools …
33. The DDD* idea of ubiquitous language needs boundaries Checkout Payment Inventory Shipment Ubiquitous Language Software Experts Domain Experts Useful models capturing an “ubiquitous language” need boundaries. * Domain-Driven Design, by Eric Evans
34. When reaching out for DDD, do not violate the bounded contexts! Order Inventory Payment
35. Workflow can be painful!* *e.g. when advertised as „zero-coding“ or when violating „bounded contexts“
36. Persist state with Entity, Actor, … State machine or workflow engine DIY Order Credit Card Payment Payment received But then: how to implement long- running services?
37. State machines or workflow engines CADENCE Baker
38. Workflow engines solve some hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
39. 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
40. Do you need a timeout?
41. Do you need a compensation? *
42. Focus on long-running behaviour - requiring state
43. Specifying and testing long-running behaviour
44. A visual test report for example #1 (Balance = 50, Amount = 70)
45. A visual test report for example #3 (Balance = 50, Amount = 30)
46. Living documentation for long-running behaviour
47. Workflows live inside service boundaries
48. Explicit flows help separate domain and infrastructure Infrastructure Aggregates, Domain Events, Domain Services, etc … + the flow Workflow Engine Payment Application Domain
49. Lightweight workflow is great! *e.g. developing and testing long-running service behaviour, solving hard developer problems, running decentralized
50. Do you like or dislike workflow?
51. Don‘t use formal notations for domain exploration.
52. Include people with accessible methods one can learn on the go.
53. Consider workflow engines and state machines to code complex event flows
54. Need some code?
55. Need some code? Inventory Payment Order Shipping Checkout Monitor https://github.com/flowing/flowing-retail/ Human Tasks
57. 1. Events decrease coupling? Sometimes! e.g. for read-models and cross-cutting concerns, but: be careful to introduce complex peer-to-peer event chains – consider commands 2. Central control needs to be avoided? Sometimes! e.g. ESB smartness, god services, but: important business capabilities need a home 3. Workflow engines are painful? Some of them! e.g. with „zero coding“, when violating bounded contexts, but: lightweight engines enable long-running services, run decentralized, solve hard developer problems
58. Thank you!
59. Code online: https://github.com/flowing Slides & Blog: https://plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies
60. Images licensed from iStock 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/ Images licensed from Shutterstock no attribution required