Pragmatic Event Driven Microservices
- 3. ‘Normal’ SQL QUERY 22 JOINS 6 SUBQUERIES
- 4. Layered architecture User Interface Service Layer Data Access Layer DomainModel Method invocation Cache Worker pools Web Cache Session replication Distributed 2nd level cache Query Cache
- 10. Monoliths St Breock Downs Monolith - www.cornwalls.co.uk
- 11. Microservices vs Monoliths Microservices system Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. Monoliths Almost all the successful microservice stories have started with a monolith that got too big and was broken up Martin Fowler Source: http://martinfowler.com/bliki/MonolithFirst.html
- 12. Are you tall enough? Source: martinfowler.com/bliki/MicroservicePrerequisites.html
- 13. Noun Driven Design Noun? Service!
- 19. $
- 20. Location transparency A Component should not be aware, nor make any assumptions, of the location of Components it interacts with A component should neither be aware of nor make any assumptions about the location of components it interacts with. Location transparency starts with good API design (but doesn’t end there)
- 21. ‘Event-Driven’ Microservices • Event Something has happened
- 22. ‘Event-Driven’ Microservices Need to know ordered items Order service OrderCreated ItemAdded ItemRemoved OrderConfirmed
- 23. Or worse… Shipping Service Order service OrderCreated InventoryConfirmed ReadyForShipping OrderShipped Payment service OrderPaid ReadyForPayment
- 24. Reasons to send a message • Event Something has happened • Command I want the system to do something • Query I want to know something
- 25. Something has happened - Event • Data change • Deadline passing • Or anything else that’s relevant in the domain
- 26. Want to know Want to know Want to know Something happened! Publish-subscribe
- 27. One of us wants to know Want to know One of us wants to know Something happened! Exclusive consumers
- 28. One of us wants to know Want to know One of us wants to know Something happened! Competing consumers
- 29. One of us wants to know Want to know One of us wants to know Something happened! Balanced consumers If (%)
- 30. I want something done - Command • Request-a-side-effect • Change data / application state • Send email • Exactly 1 destination • OK / NOK reply • Maybe some data
- 31. Can do something Can do something Can do something Do something! Command Routing
- 32. Can do something Can do something Can do something Do something! Command Routing if (%)
- 33. I want to know something - Query • Desire for information • The response has more value than the question • (Usually) side-effect free • Different messaging patterns • Single destination • Scatter – gather query • Subscription
- 34. Price = 49Result = Price Query – point to point
- 35. Price = 199 If (…) Price = 149 Query – scatter-gather Result = Min(Price) (wait 100ms)
- 36. Price = 199 If (…) Price = 149 If (…) Price = 99 Query – scatter-gather Result = Min(Price) (wait 100ms)
- 37. Query – subscription Price = 49 Result = Price + sum(Δ) Price = 39 Δ = -10
- 38. OrderConfirmed ‘Event-Driven’ Microservices Need to know ordered items Order service ItemAdded ItemRemoved OrderConfirmed OrderCreated GetOrderDetails OrderDetails
- 39. Events retain value Event Sourcing is an Architectural pattern in which Events are considered the “source of truth”, based on which components (re)build their internal state.
- 40. Event Store An Event Store stores the published events to be retrieved both by consumers as well as the publishing component itself.
- 41. OrderConfirmed Event Sourcing Some smart analytics Order service ItemRemoved OrderCreated OrderDetails
- 42. Event Store operations • Append • Validate ‘sequence’
- 43. Event Store operations • Full sequential read
- 44. Event Store operations • Read aggregate’s events
- 45. 1. Define which routing patterns to apply 2. Choose technology/protocol accordingly
- 46. At scale, different rules apply
- 47. How do you route all these events to all components? How will this scale?
- 49. Unmanageable mess Order Created Item Added to Order Shipping Address Added Billing Address Added Order Confirmed As shipping module, I want to know when an order is placed
- 50. Bounded context Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
- 51. Within a context, share ‘everything’
- 52. Between contexts, share ‘consciously’ As shipping module, I want to know when an order is placed Order Created Item Added to Order Shipping Address Added Billing Address Added Order Confirmed Order Created + Item Added + Order Confirmed Order Placed
- 53. Between contexts, share ‘consciously’ As shipping module, I want to know when an order is placed Order Created Item Added to Order Shipping Address Added Billing Address Added Order Confirmed Order Confirmed + Get Order Details Order Placed
- 54. Where does AxonFramework fit? • Inside each component in bounded context • Axon provides the Java APIs towards platform • EventBus, CommandBus, QueryBus • Separation of business logic and infrastructure logic
- 56. “Just enough” intelligence dumb smart Message Broker Sends messages. Main value add is reliability. Enterprise Service Bus Understands message content. Hard to configure and maintain. AxonHub Understands difference between Commands, Events, Queries and their routing patterns. Does not care about the content of these messages.
- 57. Our mission Provide the APIs and implementations necessary for event- driven microservices to cooperate harmoniously, allowing each of them to focus on the business logic.