Reactive Microsystems The Evolution of Microservices at Scale - - PowerPoint PPT Presentation

▶
reactive microsystems
SMART_READER_LITE
LIVE PREVIEW

Reactive Microsystems The Evolution of Microservices at Scale - - PowerPoint PPT Presentation

Nov 13, 2022 383 likes •1.66k views

Reactive Microsystems The Evolution of Microservices at Scale Jonas Bonr @jboner Microservices Are Hyped So You Want To strangle The Almighty Monolith And Move Towards Microservices? Do Not Settle For Microliths Microlith Single

slide-1
SLIDE 1

Reactive Microsystems

The Evolution of Microservices at Scale

Jonas Bonér

@jboner

slide-2
SLIDE 2

Microservices

Are Hyped

slide-3
SLIDE 3

So You Want To strangle The

Almighty Monolith

And Move Towards Microservices?

slide-4
SLIDE 4

Do Not Settle For

Microliths

slide-5
SLIDE 5

Microlith

Single instance microservice, communicating over blocking protocols

slide-6
SLIDE 6

Microlith

Single instance microservice, communicating over blocking protocols

Not Resilient

slide-7
SLIDE 7

Microlith

Single instance microservice, communicating over blocking protocols

Not Resilient Not Scalable

slide-8
SLIDE 8

“Event-Driven Architecture (EDA) is a design paradigm in which a software component executes in response to receiving one or more event notifications.”

  • Gartner

Event Driven

Architecture

To The Rescue

slide-9
SLIDE 9

The Nature of Events

slide-10
SLIDE 10

✴ Events represent Facts of information

➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow

The Nature of Events

slide-11
SLIDE 11

✴ Events represent Facts of information

➡ Facts are immutable ➡ Facts Accrue - Knowledge can only grow

✴ Events/Facts can be disregarded/Ignored

The Nature of Events

slide-12
SLIDE 12

✴ 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)

The Nature of Events

slide-13
SLIDE 13

✴ 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

The Nature of Events

slide-14
SLIDE 14

✴ 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-15
SLIDE 15
  • 1. REceive and react (or not) to facts, that

are coming its way

  • 2. Publish new facts (as events) to the rest
  • f the world
  • 3. Invert the control flow to minimize

coupling and increase autonomy

Event Driven

Services

slide-16
SLIDE 16

Practice

Reactive

Design

slide-17
SLIDE 17

✴Efficient use of resources ✴Minimizes contention

Go Async

Never Block

slide-18
SLIDE 18

A fast system

Should not overload

A slow system

Always Apply

Back Pressure

slide-19
SLIDE 19

A fast system

Should not overload

A slow system

Always Apply

Back Pressure

slide-20
SLIDE 20

Microservices

Come In Systems

slide-21
SLIDE 21

Event

Stream

slide-22
SLIDE 22

Event

Stream

Use The as the integration fabric

slide-23
SLIDE 23

Event Driven

Services

slide-24
SLIDE 24

Event Driven

Services

slide-25
SLIDE 25

Event Driven

Services

Command

slide-26
SLIDE 26

Event Driven

Services

Command

slide-27
SLIDE 27

Event Driven

Services

Command

slide-28
SLIDE 28

Event Driven

Services

Command Event

Event Stream

slide-29
SLIDE 29

Event Driven

Services

Command Event Event Event

Event Stream

slide-30
SLIDE 30

Event Driven

Services

Command Event Event Event

Event Stream

slide-31
SLIDE 31

Event Driven

Services

Command Event Event Event

Event Stream

slide-32
SLIDE 32

Event Driven

Services

Command Event Event Event

Event Stream

slide-33
SLIDE 33

Event Driven

Services

Command Event Event Event

Event Stream

slide-34
SLIDE 34

Event Driven

Services

Eventual

Consistency

Command Event Event Event

Event Stream

slide-35
SLIDE 35

Eventual

Consistency

slide-36
SLIDE 36

Eventual

Consistency

No One Wants It’s a necessAry evil

slide-37
SLIDE 37

Information Has Latency

slide-38
SLIDE 38

Information Is Always

From the Past

slide-39
SLIDE 39

Welcome To The Wild Ocean Of

Non Determinism

Distributed Systems

slide-40
SLIDE 40

“In a system which 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

slide-41
SLIDE 41

Exploit

Reality

slide-42
SLIDE 42

Exploit

Reality

We need to In our design

slide-43
SLIDE 43

Events Can Lead To Greater

Certainty

slide-44
SLIDE 44

Events Can Help Us Craft

Autonomous Islands

Of Determinism

slide-45
SLIDE 45

Mutable State

Needs To Be

Contained

And Non Observable

slide-46
SLIDE 46

Publish Facts

To Outside World

slide-47
SLIDE 47

Microservices

Come As Systems

slide-48
SLIDE 48

Each microservice needs to be designed as a distributed system

A Microsystem

slide-49
SLIDE 49

Event Driven Microservices

Powered By

Reactive Systems Fabric

Ladder of abstraction

slide-50
SLIDE 50

Event Driven Microservices

Powered By

Reactive Systems Fabric

Network Boundary Ladder of abstraction

slide-51
SLIDE 51

Event Driven Microservices

Powered By

Reactive Systems Fabric

Network Boundary Ladder of abstraction

slide-52
SLIDE 52

Event Driven Microservices

Powered By

Reactive Systems Fabric

Network Boundary Ladder of abstraction

slide-53
SLIDE 53

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Network Boundary Ladder of abstraction

slide-54
SLIDE 54

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Network Boundary Event 1 Ladder of abstraction

slide-55
SLIDE 55

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Local Event Loop Network Boundary Event 1 Ladder of abstraction

slide-56
SLIDE 56

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Local Event Loop Distribution Fabric Network Boundary Event 1 Ladder of abstraction

slide-57
SLIDE 57

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Local Event Loop Distribution Fabric Distribution Fabric Network Boundary Message Passing Event 1 Ladder of abstraction

slide-58
SLIDE 58

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Ladder of abstraction

slide-59
SLIDE 59

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Ladder of abstraction

slide-60
SLIDE 60

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) Local Event Loop Distribution Fabric Local Event Loop Distribution Fabric Network Boundary Message Passing Event 1 Event 1 Ladder of abstraction

slide-61
SLIDE 61

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) 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

slide-62
SLIDE 62

Event Driven Microservices

Powered By

Reactive Systems Fabric

Event-driven Microservices (Pub/Sub, Point-to-Point, Streaming) 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 maintains a simple programming model

slide-63
SLIDE 63

Events First

Domain Driven

Design

slide-64
SLIDE 64

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

  • 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-65
SLIDE 65

✴ Don’t focus on the things

The Nouns The Domain Objects

✴ Focus on what happens

The Verbs The Events

slide-66
SLIDE 66

Mine the

Facts

slide-67
SLIDE 67
slide-68
SLIDE 68

Event Storming

slide-69
SLIDE 69

Event Driven Design

slide-70
SLIDE 70

✴ IntentS

➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design

slide-71
SLIDE 71

✴ IntentS

➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design

✴ Facts

➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer

slide-72
SLIDE 72

✴ IntentS

➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design

✴ Facts

➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer

Commands

slide-73
SLIDE 73

✴ IntentS

➡ Communication ➡ Conversations ➡ Expectations ➡ Contracts ➡ Control Transfer Event Driven Design

✴ Facts

➡ State ➡ History ➡ Causality ➡ Notifications ➡ State Transfer

Commands Events

slide-74
SLIDE 74

Event Driven Design

slide-75
SLIDE 75

✴Commands

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

Event Driven Design

slide-76
SLIDE 76

✴Commands

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

✴Reactions

➡ Represents side-effects

Event Driven Design

slide-77
SLIDE 77

✴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-78
SLIDE 78

Commands Events

vs

slide-79
SLIDE 79

Commands Events

vs

  • 1. All about intent
  • 1. Intentless
slide-80
SLIDE 80

Commands Events

vs

  • 1. All about intent
  • 2. Directed
  • 1. Intentless
  • 2. Anonymous
slide-81
SLIDE 81

Commands Events

vs

  • 1. All about intent
  • 2. Directed
  • 3. Single addressable

destination

  • 1. Intentless
  • 2. Anonymous
  • 3. Just happens - for
  • thers (0-N) to observe
slide-82
SLIDE 82

Commands Events

vs

  • 1. All about intent
  • 2. Directed
  • 3. Single addressable

destination

  • 4. Models personal

communication

  • 1. Intentless
  • 2. Anonymous
  • 3. Just happens - for
  • thers (0-N) to observe
  • 4. Models broadcast

(speakers corner)

slide-83
SLIDE 83

Commands Events

vs

  • 1. All about intent
  • 2. Directed
  • 3. Single addressable

destination

  • 4. Models personal

communication

  • 5. Distributed focus
  • 1. Intentless
  • 2. Anonymous
  • 3. Just happens - for
  • thers (0-N) to observe
  • 4. Models broadcast

(speakers corner)

  • 5. Local focus
slide-84
SLIDE 84

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-85
SLIDE 85

Let the Events Define the

Bounded Context

slide-86
SLIDE 86

Are we done now?

  • Perhaps. We have come a long way.

But events can also be used for:

➡ Persistence ➡ Managing time

slide-87
SLIDE 87

Event Based

Persistence

slide-88
SLIDE 88

“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-89
SLIDE 89

Event Logging

The Bedrock

slide-90
SLIDE 90

“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-91
SLIDE 91

The Log

A Database Of the Past

Not Just the Present

slide-92
SLIDE 92

Event Sourcing

A Cure For the Cardinal Sin

slide-93
SLIDE 93

Event

Sourced

Services

slide-94
SLIDE 94

Happy Path

Event

Sourced

Services

slide-95
SLIDE 95

Happy Path

Event

Sourced

Services

1) Receive and verify Command (“ApprovePayment”)

slide-96
SLIDE 96

Happy Path

Event

Sourced

Services

2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”)

slide-97
SLIDE 97

Happy Path

Event

Sourced

Services

2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log

slide-98
SLIDE 98

Happy Path

Event

Sourced

Services

2) Create new Event (“PaymentApproved”) 1) Receive and verify Command (“ApprovePayment”) 3) Append Event to Event Log 4) Update internal component state

slide-99
SLIDE 99

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

slide-100
SLIDE 100

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

slide-101
SLIDE 101

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

slide-102
SLIDE 102

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

slide-103
SLIDE 103

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

M e m

  • r

y I m a g e

slide-104
SLIDE 104

Benefits Of using

Event Sourcing

slide-105
SLIDE 105

Benefits Of using

Event Sourcing

✴ One single Source of Truth with All history

slide-106
SLIDE 106

Benefits Of using

Event Sourcing

✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state

slide-107
SLIDE 107

Benefits Of using

Event Sourcing

✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state ✴ Avoids the Object-relational Impedence mismatch

slide-108
SLIDE 108

Benefits Of using

Event Sourcing

✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state ✴ Avoids the Object-relational Impedence mismatch ✴ Allows others to Subscribe to state changes

slide-109
SLIDE 109

Benefits Of using

Event Sourcing

✴ One single Source of Truth with All history ✴ Allows for Memory Image - durable in-memory state ✴ Avoids the Object-relational Impedence mismatch ✴ Allows others to Subscribe to state changes ✴ Mechanical sympathy (Single Writer Principle etc.)

slide-110
SLIDE 110

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

Disadvantages

Of Using Event Sourcing

slide-111
SLIDE 111

Events

Allow Us To Manage

Time

slide-112
SLIDE 112

“Modeling 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-113
SLIDE 113

✴ 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-114
SLIDE 114

Event Sourcing

Allows For

Time Travel

slide-115
SLIDE 115

Event Sourcing

Allows For

Time Travel

slide-116
SLIDE 116

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-117
SLIDE 117

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

slide-118
SLIDE 118

Key Takeaways

slide-119
SLIDE 119

Key Takeaways

  • 1. Don’t build Microliths
slide-120
SLIDE 120

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
slide-121
SLIDE 121

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
  • 3. Microservices come as (micro)systems
slide-122
SLIDE 122

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
  • 3. Microservices come as (micro)systems
  • 4. Embrace the Reactive Principles
slide-123
SLIDE 123

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
  • 3. Microservices come as (micro)systems
  • 4. Embrace the Reactive Principles
  • 5. Embrace Events-first Domain Driven Design
slide-124
SLIDE 124

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
  • 3. Microservices come as (micro)systems
  • 4. Embrace the Reactive Principles
  • 5. Embrace Events-first Domain Driven Design
  • 6. Embrace Event-driven Architecture
slide-125
SLIDE 125

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
  • 3. Microservices come as (micro)systems
  • 4. Embrace the Reactive Principles
  • 5. Embrace Events-first Domain Driven Design
  • 6. Embrace Event-driven Architecture
  • 7. Embrace Event-driven Persistence
slide-126
SLIDE 126

Key Takeaways

  • 1. Don’t build Microliths
  • 2. Microservices come in (distributed) systems
  • 3. Microservices come as (micro)systems
  • 4. Embrace the Reactive Principles
  • 5. Embrace Events-first Domain Driven Design
  • 6. Embrace Event-driven Architecture
  • 7. Embrace Event-driven Persistence
  • 8. Profit!!!
slide-127
SLIDE 127

Learn More

Download my latest book for free at:

bit.ly/reactive-microsystems