How Events Are Reshaping Modern Systems Jonas Bonr @jboner Why - - PowerPoint PPT Presentation

▶
how events
SMART_READER_LITE
LIVE PREVIEW

How Events Are Reshaping Modern Systems Jonas Bonr @jboner Why - - PowerPoint PPT Presentation

Jul 18, 2023 445 likes •1.03k views

How Events Are Reshaping Modern Systems Jonas Bonr @jboner Why Should you care about Events? 1. Events drive autonomy 2. Events help reduce risk 3. Events help you move faster 4. Events Increase Loose coupling 5. Events increase stability 6.

slide-1
SLIDE 1

How Events

Are Reshaping

Modern Systems

Jonas Bonér

@jboner

slide-2
SLIDE 2
  • 1. Events drive autonomy
  • 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 about Events?

slide-3
SLIDE 3

Why Now?

  • 1. Cloud and multicore architectures
  • 2. Microservices and distributed systems
  • 3. Data-centric applications
  • 4. “We want more, of everything, and we

want it now.” -Your Customers

slide-4
SLIDE 4

What is an

Event?

slide-5
SLIDE 5

✴ Events represent Facts of 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

slide-6
SLIDE 6
  • 1. REceive and react (or not) to facts, that

are coming its way

  • 2. Publish new facts (immutable events) to

the rest of the world

  • 3. Invert the control flow to minimize

coupling and increase autonomy

Event Driven

Services

slide-7
SLIDE 7

Mutable State

Needs To Be

Contained

And Non Observable

slide-8
SLIDE 8

Publish Facts

To Outside World

slide-9
SLIDE 9

Event Driven

Services

Eventual

Consistency

Command Event Event Event

Event Stream

slide-10
SLIDE 10

Event

Stream

Use The

as the communication fabric

slide-11
SLIDE 11

Event

Stream

Use The as the integration fabric

slide-12
SLIDE 12

Event

Stream

Use The as the replication fabric

slide-13
SLIDE 13

Event

Stream

Use The

as the consensus fabric

slide-14
SLIDE 14

Event

Stream

Use The

as the Persistence fabric

slide-15
SLIDE 15

Eventual

Consistency

We have to rely on

But relax—it’s how the world works

slide-16
SLIDE 16

Information Has Latency

slide-17
SLIDE 17

Information Is Always

From the Past

slide-18
SLIDE 18

Welcome To The Wild Ocean Of

Non Determinism

Distributed Systems

slide-19
SLIDE 19

“In a system which cannot count on distributed transactions, the management

  • f uncertainty must be implemented in the

business logic.”

  • Pat Helland
Life Beyond Distributed Transactions, Pat Helland (2007)

We Need To Model

Uncertainty

slide-20
SLIDE 20

Events Can Lead To Greater

Certainty

slide-21
SLIDE 21

“An autonomus component can only promise its own behavior.” “Autonomy makes information local, leading to greater certainty and stability.”

  • Mark Burgess
In Search of Certainty, Thinking in Promises - Mark Burgess
slide-22
SLIDE 22

Events Can Help Us Craft

Autonomous Islands

Of Determinism

slide-23
SLIDE 23

“Accidents come from relationships not broken parts.”

  • Sidney dekker

Drift into Failure - Sidney Dekker

slide-24
SLIDE 24

“Complex systems run as broken systems.”

  • richard Cook

How Complex Systems Fail - Richard Cook

slide-25
SLIDE 25

Resilience

is by

Design

Photo courtesy of FEMA/Joselyne Augustino

slide-26
SLIDE 26

Events Can Help Us

Manage

Failure

Instead Of Trying To Avoid It

slide-27
SLIDE 27

Requirements for a

Sane Failure Model

  • 1. Contained—Avoid cascading failures
  • 2. Reified—as Events
  • 3. Signalled—Asynchronously
  • 4. Observed—by 1-N
  • 5. Managed—Outside failed Context

Failures need to be

slide-28
SLIDE 28

✴Async? ✴Distributed systems? ✴Eventual consistency? ✴Uncertainty? ✴Failure models?

But All This Stuff

Is Hard

slide-29
SLIDE 29

Think

In Terms Of

Workflow

slide-30
SLIDE 30

Events First

Domain Driven

Design

slide-31
SLIDE 31

“When you start modeling events, it forces you to think about the behaviour

  • f 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)
slide-32
SLIDE 32

✴ Don’t focus on the things

The Nouns The Domain Objects

✴ Focus on what happens

The Verbs The Events

slide-33
SLIDE 33

Mine the

Facts

slide-34
SLIDE 34

Event Storming

slide-35
SLIDE 35

✴ IntentS

➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer

Event Driven Design

✴ Facts

➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer

Commands Events

slide-36
SLIDE 36

✴Commands

➡ Object form of method/Action request ➡ Imperative: CreateOrder, ShipProduct

✴Reactions

➡ Represents side-effects

✴Events

➡ Represents something that has happened ➡ Past-tense: OrderCreated, ProductShipped

Event Driven Design

slide-37
SLIDE 37

Commands Events

vs

  • 1. All about 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
  • thers (0-N) to observe
  • 4. Models broadcast

(speakers corner)

  • 5. Local focus
  • 6. Autonomy
slide-38
SLIDE 38

Let the Events Define the

Bounded Context

slide-39
SLIDE 39

Inside Data

Our current present—state

Outside Data

Blast from the past—Events/facts

Between Services

Hope for the future—commands

Data on the inside vs Data on the outside - Pat Helland

slide-40
SLIDE 40

Event Based

Persistence

slide-41
SLIDE 41

✴ Maintains Integrity & consistency ✴ Is our Unit of Consistency ✴ Is our Unit of Failure ✴ Is our Unit of Determinism ✴ Is fully Autonomous

The Aggregate

slide-42
SLIDE 42

CRUD is DEAD

slide-43
SLIDE 43

“Update-in-place strikes systems designers as a cardinal sin: it violates traditional accounting practices that have been observed for hundreds of years.”

  • jim Gray
The Transaction Concept, Jim Gray (1981)
slide-44
SLIDE 44

Event Logging

The Bedrock

slide-45
SLIDE 45

“The truth is the log. The database is a cache

  • f a subset of the log.”
  • Pat Helland
Immutability Changes Everything, Pat Helland (2015)
slide-46
SLIDE 46

Event Sourcing

A Cure For the Cardinal Sin

slide-47
SLIDE 47

SAD Path - recover 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

M e m

  • r

y I m a g e

slide-48
SLIDE 48

Event Sourcing

✴ One single 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 ✴ Has good Mechanical sympathy (Single Writer Principle etc.)

slide-49
SLIDE 49

✴ Unfamiliar model ✴ Versioning of events ✴ Deletion of events (legal or moral reasons)

Disadvantages

Of Using Event Sourcing

slide-50
SLIDE 50

Events

Allow Us To Manage

Time

slide-51
SLIDE 51

“Modelling events forces you 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)
slide-52
SLIDE 52

✴ Event is a 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

slide-53
SLIDE 53

Event Sourcing

Allows For

Time Travel

✴Replay the log for historic debugging ✴Replay the log for auditing & traceability ✴Replay the log on failure ✴Replay the log for replication

slide-54
SLIDE 54

We Can Even Fork the Past ...Or Join Two Distinct Pasts

slide-55
SLIDE 55

Key Takeaways

Events-First design helps you to:

✴ Move Faster towards a Resilient architecture ✴ Design autonomous services ✴ Balance Certainty and Uncertainty ✴ reduce risk when modernizing applications

Event Logging allows you to:

✴ AVOID CRUD and ORM ✴ take control of your system’s history ✴ time-travel ✴ Balance Strong and eventual consistency

slide-56
SLIDE 56

http://akka.io

slide-57
SLIDE 57

Learn More

Download my latest book for free at:

bit.ly/reactive-microsystems