Downloaded 68 times
Uploaded byJonas Bonér
How Events Are Reshaping Modern Systems
The document discusses how event-driven architecture and event-based design principles are reshaping modern systems. Some key points: - Events increase autonomy, reduce risk, help systems move faster, improve loose coupling, stability, scalability, resilience and traceability. - Modern architectures like cloud, microservices and distributed systems benefit from event-driven approaches. Events also help with data-centric applications and meeting increasing customer demands. - High-level abstractions powered by message-driven fabrics are needed to address limitations of low-level event loops and callbacks. Event-driven services publish facts as events and use event streams for integration. - Thinking in terms of immutable events and promises can help increase certainty
More Related Content
Similar to How Events Are Reshaping Modern Systems
How Events Are Reshaping Modern Systems
- 1. How Events Are Reshaping ModernSystems Jonas Bonér @jboner
- 3.
- 4. 1. Events driveautonomy 2. Events help reduce risk 3. Events help you move faster 4. Events Increase Loose coupling 5. Events increase stability 6. Events increase scalability 7. Events increase resilience 8. Events increase traceability 9. Events allow for time-travel Why Should you care?
- 5. 1. Cloud andmulticore architectures 2. Microservices and distributed systems 3. Data-centric applications 4. “We want more, of everything, and we want it now.” - Your Customers
- 6. Why Now? 1. Cloudand multicore architectures 2. Microservices and distributed systems 3. Data-centric applications 4. “We want more, of everything, and we want it now.” - Your Customers
- 7. Do Not SettleFor Microliths
- 8. Do Not SettleFor Microliths
- 9. “Event-Driven Architecture (EDA) isa design paradigm in which a software component executes in response to receiving one or more event notifications.” - Gartner Event Driven Architecture To The Rescue
- 11.
- 12. Event “Something that happens.” -Merriam Webster
- 13. The Nature ofEvents
- 14. ✴Events represent Factsof information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow The Nature of Events
- 15. ✴Events represent Factsof information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored The Nature of Events
- 16. ✴Events represent Factsof information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored ✴ Events/Facts Can not be retracted (once accepted) The Nature of Events
- 17. ✴Events represent Factsof information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored ✴ Events/Facts Can not be retracted (once accepted) ✴ Events/Facts Can not be deleted (once accepted) ➡ Might be needed for legal or moral reasons The Nature of Events
- 18. ✴Events represent Factsof information ➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow ✴ Events/Facts can be disregarded/Ignored ✴ Events/Facts Can not be retracted (once accepted) ✴ Events/Facts Can not be deleted (once accepted) ➡ Might be needed for legal or moral reasons ✴ Events/Facts (new) can invalidate existing Facts The Nature of Events
- 19. Event Loop What MakesEvent Tick
- 20. ✴ Queue +anonymous Callbacks ✴ The Hollywood principle ✴ At-Most-Once delivery guarantees ✴ Local context only ✴ Sync or AsynC ✴ Limited and quite powerless The Event Loop
- 21. ✴ Queue +anonymous Callbacks ✴ The Hollywood principle ✴ At-Most-Once delivery guarantees ✴ Local context only ✴ Sync or AsynC ✴ Limited and quite powerless The Event Loop * * Too limited as a general model of computation, and programming model for modern distributed systems. But is a useful building block.
- 22. ✴ Ephemeral andanonymous ✴ No sane failure model Error Channel - console.log(‘4/0=err’, err) ✴ No composition Signature: Input => Side-effect - (Any => Unit) ✴ Hard to Debug ✴ Hard to reason about ✴ Leads to Callback hell The Problem With Event Callbacks
- 23.
- 25. ✴Patterns Observer, Pub-Sub, Broadcast,… ✴Futures & PRomises ✴Dataflow Variables ✴Stream Processing ✴ Event-driven Microservices ✴ FaaS We Need High Level Abstractions
- 26. Unified Event DrivenAbstractions Powered By Message Driven Fabric Ladder of abstraction
- 27. Unified Event DrivenAbstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction
- 28. Unified Event DrivenAbstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction
- 29. Unified Event DrivenAbstractions Powered By Message Driven Fabric Network Boundary Ladder of abstraction
- 30. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Network Boundary Ladder of abstraction
- 31. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Network Boundary Event 1Ladder of abstraction
- 32. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Network Boundary Event 1Ladder of abstraction
- 33. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Network Boundary Event 1Ladder of abstraction
- 34. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Distribution Fabric Network Boundary Message Passing Event 1Ladder of abstraction
- 35. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1Ladder of abstraction
- 36. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1Ladder of abstraction
- 37. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1Ladder of abstraction
- 38. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1 Reactive Systems is doing the heavy lifting Ladder of abstraction
- 39. Unified Event DrivenAbstractions Powered By Message Driven Fabric Unified API (Event-driven Microservices, Patterns, Streams, Futures, FaaS,…) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1 Reactive Systems is doing the heavy lifting Ladder of abstraction Reactive Programming
- 40. 1. REceive andreact to facts (or not), that are coming its way 2. Publish new facts (as events) to the rest of the world 3. Invert the control flow to minimize coupling and increase autonomy Event Driven Services
- 41. Mutable State Needs ToBe Contained And Non Observable
- 42.
- 43.
- 44. Event Stream Use The as theintegration fabric
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59. Eventual Consistency No One Wants It’sa necessery evil
- 60. But Relax It IsHow The World Works
- 61.
- 62. Information Is Always Fromthe Past
- 63. Welcome To TheWild Ocean Of Non Determinism Distributed Systems
- 64. “In a systemwhich cannot count on distributed transactions, the management of uncertainty must be implemented in the business logic.” - Pat Helland Life Beyond Distributed Transactions - An Apostate’s Opinion, Pat Helland (2007) We Need To Model Uncertainty
- 65.
- 66. Exploit Reality We need to Inour design
- 67. Events Can LeadTo Greater Certainty
- 68. Events Can HelpUs Craft Autonomous Islands Of Determinism
- 70. What does itmean to be Automonous?
- 71. From greek: Auto-nomos ✴Auto meaning self ✴ Nomos meaning Law Autonomy
- 72.
- 73.
- 74. ✴Impositions diverge into unpredictableoutcomes from definite beginnings Distributed information Decreased certainty Convergence vs. Divergence of information ✴Promises converge towards a definite outcome from unpredictable beginnings Local information Improved certainty
- 75. “Autonomy makes informationlocal, leading to greater certainty and stability.” “An autonomus component can only promise its own behavior.” - Mark Burgess In Search of Certainty, Thinking in Promises - Mark Burgess
- 76. Benefits of Thinkingin Promises
- 77. ✴ If aservice only promises its own behavior Then all information needed to ➡ Resolve a conflict ➡ Repair under failure ➡ Is available within the service itself Benefits of Thinking in Promises
- 78. ✴ If aservice only promises its own behavior Then all information needed to ➡ Resolve a conflict ➡ Repair under failure ➡ Is available within the service itself ✴ Promises remove the need for needless 1. Communication 2. Coordination 3. Consensus Benefits of Thinking in Promises
- 79. “The first principleof successful scalability is to batter the consistency mechanisms down to a minimum.” - James Hamilton As transcribed in: Toward a Cloud Computing Research Agenda. SIGACT News, 40(2):68–80, June 2009.
- 80. Events First Design DrivesAutonomy
- 81.
- 82. “When you startmodeling events, it forces you to think about the behavior of the system. As opposed to thinking about the structure of the system.” - Greg Young A Decade of DDD, CQRS, Event Sourcing, Greg Young (Presentation from 2016)
- 83. ✴ Don’t focuson the things The Nouns The Domain Objects ✴ Focus on what happens The Verbs The Events
- 84.
- 86.
- 87.
- 88. ✴ IntentS ➡ Communication ➡Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design
- 89. ✴ IntentS ➡ Communication ➡Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer
- 90. ✴ IntentS ➡ Communication ➡Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer Commands
- 91. ✴ IntentS ➡ Communication ➡Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design ✴ Facts ➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer Commands Events
- 92.
- 93. ✴Commands ➡ Object formof method/Action request ➡ Imperative: CreateOrder, ShipProduct Event Driven Design
- 94. ✴Commands ➡ Object formof method/Action request ➡ Imperative: CreateOrder, ShipProduct ✴Reactions ➡ Represents side-effects Event Driven Design
- 95. ✴Commands ➡ Object formof method/Action request ➡ Imperative: CreateOrder, ShipProduct ✴Reactions ➡ Represents side-effects ✴Events ➡ Represents something that has happened ➡ Past-tense: OrderCreated, ProductShipped Event Driven Design
- 96.
- 97. Commands Eventsvs 1. Allabout intent 1. Intentless
- 98. Commands Eventsvs 1. Allabout intent 2. Directed 1. Intentless 2. Anonymous
- 99. Commands Eventsvs 1. Allabout intent 2. Directed 3. Single addressable destination 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe
- 100. Commands Eventsvs 1. Allabout intent 2. Directed 3. Single addressable destination 4. Models personal communication 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe 4. Models broadcast (speakers corner)
- 101. Commands Eventsvs 1. Allabout intent 2. Directed 3. Single addressable destination 4. Models personal communication 5. Distributed focus 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe 4. Models broadcast (speakers corner) 5. Local focus
- 102. Commands Eventsvs 1. Allabout intent 2. Directed 3. Single addressable destination 4. Models personal communication 5. Distributed focus 6. Command & Control 1. Intentless 2. Anonymous 3. Just happens - for others (0-N) to observe 4. Models broadcast (speakers corner) 5. Local focus 6. Autonomy
- 103. Let the EventsDefine the Bounded Context
- 104. Principles For Promise TheoryDriven Protocol Design
- 105. 1. Convergency Promises shouldreach a desired state, a stable outcome - idempotent behavior Principles For Promise Theory Driven Protocol Design
- 106. 1. Convergency Promises shouldreach a desired state, a stable outcome - idempotent behavior 2. Embracing Failure Expect things to go wrong Promises may or may not be kept Principles For Promise Theory Driven Protocol Design
- 107. 1. Convergency Promises shouldreach a desired state, a stable outcome - idempotent behavior 2. Embracing Failure Expect things to go wrong Promises may or may not be kept 3. Autonomy You can’t rely on other services Principles For Promise Theory Driven Protocol Design
- 108. ✴ Maintains Integrity& consistency ✴ Is our Unit of Consistency ✴ Is our Unit of Failure ✴ Is our Unit of Determinism ✴ Is fully Autonomous The Aggregate
- 109. Enough Talk Show MeThe Code Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a Sample in Scala: https://gist.github.com/jboner/dea4aa819e127d543d684208d74081b5
- 110. Enough Talk Show MeThe Code Sample in Java: https://gist.github.com/jboner/4361c710d2e2386be8bddc39edb0528a Sample in Scala: https://gist.github.com/jboner/dea4aa819e127d543d684208d74081b5
- 111. Are we donenow?
- 112. Are we donenow? Perhaps. We have come a long way.
- 113. Are we donenow? Perhaps. We have come a long way. But events can also be used for:
- 114. Are we donenow? Perhaps. We have come a long way. But events can also be used for: ➡ Persistence
- 115. Are we donenow? Perhaps. We have come a long way. But events can also be used for: ➡ Persistence ➡ Managing time
- 116.
- 117. “Update-in-place strikes systems designersas a cardinal sin: it violates traditional accounting practices that have been observed for hundreds of years.” - jim Gray The Transaction Concept, Jim Gray (1981)
- 118.
- 119. Event Sourcing A CureFor the Cardinal Sin
- 120. “The truth isthe log. The database is a cache of a subset of the log.” - Pat Helland Immutability Changes Everything, Pat Helland (2015)
- 121.
- 122.
- 123. Happy Path Event Sourced Services 1) Receiveand verify Command (“ApprovePayment”)
- 124. Happy Path Event Sourced Services 2) Createnew Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”)
- 125. Happy Path Event Sourced Services 2) Createnew Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log
- 126. Happy Path Event Sourced Services 2) Createnew Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state
- 127. Happy Path Event Sourced Services 5) Runside-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state
- 128. SAD Path -recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state
- 129. SAD Path -recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state 1) Rehydrate Events from Event Log
- 130. SAD Path -recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state 1) Rehydrate Events from Event Log 2) Update internal component state
- 131. SAD Path -recovering from failure Happy Path Event Sourced Services 5) Run side-effects (approve the payment) 2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state 1) Rehydrate Events from Event Log 2) Update internal component state Memory Image
- 132. Event Sourcing ✴ Onesingle Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state ✴ Avoids the Object-relational mismatch ✴ Allows others to Subscribe to state changes ✴ Mechanical sympathy (Single Writer Principle etc.)
- 133. ✴ Unfamiliar model ✴Versioning of events ✴ Deletion of events (legal or moral reasons) Disadvantages Of Using Event Sourcing
- 134. EventsAllow Us ToManage Time
- 135. “Modeling events forcesyou to have a temporal focus on what’s going on in the system. Time becomes a crucial factor of the system.” - Greg Young A Decade of DDD, CQRS, Event Sourcing, Greg Young (Presentation from 2016)
- 137. But, What isTime Really?
- 138. Causality How We MakeSense Of The World
- 139. Time Is theSuccession Of Causally Related Events
- 140. ✴ Event isa snapshot in time ✴ Event ID is an index for time ✴ Event Log is our full history The database of Our past The path to Our present Event Sourcing Allows Us To Model Time
- 141.
- 142.
- 143. Event Sourcing Allows For TimeTravel ✴Replay the log for historic debugging ✴Replay the log for auditing & traceability ✴Replay the log on failure ✴Replay the log for replication
- 144. “The future isa function of the past.” - A. P. Robertson
- 145. “The (local) presentis a merge function of multiple concurrent pasts.” - me
- 146. val newLocalPresent =observedPasts. foldLeft(oldLocalPresent) { _ merge _ }
- 147. We need toexplicitly model the local present as facts derived from the merging of multiple concurrent pasts
- 148. We Can EvenFork the Past ...Or Join Two Distinct Pasts
- 149. Let Make OurDemo Event Sourced
- 150. Untangle Your Read andWrite Models With CQRS
- 151.
- 152.
- 153.
- 154. CQRS Write Side Model Writeto Event Log Commands
- 155. CQRS Write Side Model Events Writeto Event Log Commands
- 156. CQRS Write Side Model Events Events Writeto Event Log Commands
- 157. CQRS Read Side Model WriteSide Model Events Events Read Data Store Write to Event Log Commands
- 158. CQRS Read Side Model WriteSide Model Events Queries Events Read Data Store Write to Event Log Commands
- 159. CQRS Read Side Model WriteSide Model Events Queries Events Read Data Store Write to Event Log Eventual Consistency Commands
- 160. ✴ Temporal Decoupling ✴Increased Resilience ✴ Increased Scalability ✴ Allows for Multiple Event subscribers ✴ Allows for Polyglot Persistence Advantages Of Using CQRS
- 161. ✴ More infrastructureto manage ✴ 2 data models (or more) to maintain ✴ Eventual Consistency Disadvantages Of Using CQRS
- 162.
- 163. Key Takeaways Event drivendesign helps you to: ✴ Design autonomous services ✴ Move Faster towards a Reactive architecture ✴ reduce risk when modernizing applications ✴ Balance Certainty and Uncertainty
- 164. Key Takeaways Event drivendesign helps you to: ✴ Design autonomous services ✴ Move Faster towards a Reactive architecture ✴ reduce risk when modernizing applications ✴ Balance Certainty and Uncertainty Event Logging allows you to: ✴ take control of your system’s history ✴ time-travel ✴ Balance Strong and eventual consistency
- 165. Learn More Download mylatest book for free at: bit.ly/reactive-microsystems