The Reactive Principles: Design Principles For Cloud Native Applications

Slide 1

Slide 1 text

The Reactive Principles Jonas Bonér @jboner Design Principles For Cloud Native Applications

Slide 2

Slide 2 text

What Does Cloud native Mean?

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Why is Cloud native Infrastructure Not enough?

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

Managing empty boxes is only half of the solution,   it matters equally much what you put inside them

Slide 8

Slide 8 text

Cloud Native Applications need both a: ✓ Scalable and Available Infrastructure Layer ✓ Scalable and Available Application Layer

Slide 9

Slide 9 text

Reactive shows the way

Slide 10

Slide 10 text

Addresses the challenges of distributed systems directly   in its abstractions, programming/data models,   protocols, interaction schemes, and error handling Reactive shows the way The Reactive Application

Slide 11

Slide 11 text

Addresses the challenges of distributed systems directly   in its abstractions, programming/data models,   protocols, interaction schemes, and error handling Not as an afterthought   not as operational or infrastructure problems   that are dealt with via increasingly complex tech stacks,   wrappers, workarounds, and leaky abstractions Reactive shows the way The Reactive Application

Slide 12

Slide 12 text

What’s the antidote?

Slide 13

Slide 13 text

Introducing the Reactive Principles https://principles.reactive.foundation

Slide 14

Slide 14 text

Introducing the Reactive Principles I. Stay Responsive https://principles.reactive.foundation

Slide 15

Slide 15 text

Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty https://principles.reactive.foundation

Slide 16

Slide 16 text

Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure https://principles.reactive.foundation

Slide 17

Slide 17 text

Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy https://principles.reactive.foundation

Slide 18

Slide 18 text

Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy V. Tailor Consistency https://principles.reactive.foundation

Slide 19

Slide 19 text

Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy V. Tailor Consistency VI. Decouple Time https://principles.reactive.foundation

Slide 20

Slide 20 text

Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy V. Tailor Consistency VI. Decouple Time VII. Decouple Space https://principles.reactive.foundation

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Ⅰ

Slide 23

Slide 23 text

Ⅰ Stay Responsive Always respond in a timely manner

Slide 24

Slide 24 text

It’s easy to stay responsive during “Blue sky” scenarios

Slide 25

Slide 25 text

But it’s equally important to stay responsive in the face of failures, communication outages, and unpredictable workloads

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

“An escalator can never break:   it can only become stairs.   You should never see an   Escalator Temporarily Out Of Order sign,   just Escalator Temporarily Stairs.   Sorry for the convenience.” - Mitch Hedberg

Slide 28

Slide 28 text

Ⅱ

Slide 29

Slide 29 text

Ⅱ Accept Uncertainty Build reliability despite unreliable foundations

Slide 30

Slide 30 text

Welcome To The Wild Ocean Of Non Determinism Distributed Systems

Slide 31

Slide 31 text

Exploit Reality

Slide 32

Slide 32 text

Exploit Reality We need to In our design

Slide 33

Slide 33 text

Information Has Latency

Slide 34

Slide 34 text

Information Is Always From the Past

Slide 35

Slide 35 text

Time We cannot always trust Order Or

Slide 36

Slide 36 text

There Is No Now

Slide 37

Slide 37 text

We Need To Model and manage Uncertainty Directly In The Application Architecture

Slide 38

Slide 38 text

“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 and manage Uncertainty Directly In The Application Architecture

Slide 39

Slide 39 text

Ⅲ

Slide 40

Slide 40 text

Ⅲ Embrace Failure Except things to go wrong and design for resilience

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

We Need To Manage Failure Not Try To Avoid It

Slide 45

Slide 45 text

Resilience is by Design Photo courtesy of FEMA/Joselyne Augustino

Slide 46

Slide 46 text

“Accidents come from relationships not broken parts.” - Sidney dekker Drift into Failure - Sidney Dekker

Slide 47

Slide 47 text

Decoupling in space   allows the failure to be kept inside designated failure zones (bulkheads) Decoupling in time   enables other components to reliably detect   and handle failures even when they cannot   be explicitly communicated

Slide 48

Slide 48 text

Failures Need To Be 1. Contained—Avoid cascading failures 2. Reified—as values 3. Signalled—Asynchronously 4. Observed—by 1-N 5. Managed—Outside failed Context

Slide 49

Slide 49 text

Let It Crash To Build Self-healing Systems

Slide 50

Slide 50 text

Ⅳ

Slide 51

Slide 51 text

Ⅳ Assert Autonomy Design components that act independently And interact collaboratively

Slide 52

Slide 52 text

We need to Craft Autonomous Islands Of Determinism

Slide 53

Slide 53 text

Mutable State Needs To Be Contained And Non Observable

Slide 54

Slide 54 text

Publish Facts To Outside World Using well-defined Protocols

Slide 55

Slide 55 text

A system of distributed services is a never-ending stream towards convergence

Slide 56

Slide 56 text

A system of distributed services is a never-ending stream towards convergence Always in the process of convergence Never reaching the state of convergence

Slide 57

Slide 57 text

There Is No Now A system of distributed services is a never-ending stream towards convergence Always in the process of convergence Never reaching the state of convergence

Slide 58

Slide 58 text

Think In Terms Of Consistency Boundaries Small islands of strong consistency in a river of constant change and uncertainty

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Inside Data Our current present 㱺 state Data on the inside vs Data on the outside - Pat Helland

Slide 61

Slide 61 text

Inside Data Our current present 㱺 state Outside Data Blast from the past 㱺 facts Data on the inside vs Data on the outside - Pat Helland

Slide 62

Slide 62 text

Inside Data Our current present 㱺 state Outside Data Blast from the past 㱺 facts Between Services Hope for the future 㱺 commands Data on the inside vs Data on the outside - Pat Helland

Slide 63

Slide 63 text

“Autonomy makes information local, leading to greater certainty and stability.” - Mark Burgess In Search of Certainty - Mark Burgess

Slide 64

Slide 64 text

Ⅴ

Slide 65

Slide 65 text

Ⅴ Tailor Consistency Individualize consistency per component   to balance availability and performance

Slide 66

Slide 66 text

STRONG Consistency Is the wrong default

Slide 67

Slide 67 text

“Two-phase commit is the anti-availability protocol.” - Pat Helland Standing on Distributed Shoulders of Giants - Pat Helland

Slide 68

Slide 68 text

Doh, you’re right. All those distributed transactions are heavy! Don’t carry around more guarantees than you need!!!

Slide 69

Slide 69 text

Strong Consistency Within   The Consistency Boundary

Slide 70

Slide 70 text

BETWEEN Consistency Boundaries It Is A ZOO

Slide 71

Slide 71 text

BETWEEN Consistency Boundaries It Is A ZOO

Slide 72

Slide 72 text

Eventual Consistency We have to rely on But relax—it’s how the world works

Slide 73

Slide 73 text

“It's easier to ask for forgiveness than it is to get permission” - Grace Hopper

Slide 74

Slide 74 text

Guess. Apologize. Compensate. Use a protocol of

Slide 75

Slide 75 text

We need Systems that are Decoupled in Space and Time

Slide 76

Slide 76 text

Ⅵ

Slide 77

Slide 77 text

Decouple Time Process asynchronously to avoid coordination and waiting Ⅵ

Slide 78

Slide 78 text

“Silence is not only golden.   It is seldom misquoted.” - Bob Monkhouse

Slide 79

Slide 79 text

Temporal Coupling Reduce

Slide 80

Slide 80 text

✓ Efficient use of resources ✓ Minimized contention Go Async Don’t block needlessly

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

Needs to be async and non-blocking all the way down

Slide 83

Slide 83 text

Needs to be async and non-blocking all the way down

Slide 84

Slide 84 text

Ⅶ

Slide 85

Slide 85 text

Ⅶ Decouple Space Create flexibility by embracing the network

Slide 86

Slide 86 text

Spatial Coupling Reduce

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

Embrace The Network ✓Make distribution first class • Avoid the mistakes of EJB, CORBA,   or Network Attached Disks

Slide 89

Slide 89 text

Embrace The Network ✓Make distribution first class • Avoid the mistakes of EJB, CORBA,   or Network Attached Disks ✓Go Async • Use Asynchronous IO • Use Message-Passing

Slide 90

Slide 90 text

Embrace The Network ✓Make distribution first class • Avoid the mistakes of EJB, CORBA,   or Network Attached Disks ✓Go Async • Use Asynchronous IO • Use Message-Passing ✓Leverage Location Transparency • Mobility, Virtual Addressing

Slide 91

Slide 91 text

Location Transparency One abstraction for Communication across all dimensions of scale

Slide 92

Slide 92 text

Location Transparency One abstraction for Communication across all dimensions of scale Core 㱺 Socket 㱺 CPU 㱺 Container 㱺 Server 㱺   Rack 㱺 Data Center 㱺 Global

Slide 93

Slide 93 text

Spatial Decoupling Enables Resilience

Slide 94

Slide 94 text

Ⅷ

Slide 95

Slide 95 text

Ⅷ Handle Dynamics Continuously adapt to varying   demand and resources

Slide 96

Slide 96 text

Be Elastic React to changes in the input rate Increasing/decreasing resources

Slide 97

Slide 97 text

When Resources Are Fixed Decrease the scope of processed Inputs Signal degradation to the outside

Slide 98

Slide 98 text

fast producer Should never overload slow consumer Always Apply Back Pressure

Slide 99

Slide 99 text

fast producer Should never overload slow consumer Always Apply Back Pressure

Slide 100

Slide 100 text

The Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy V. Tailor Consistency VI. Decouple Time VII. Decouple Space VIII. Handle Dynamics

Slide 101

Slide 101 text

Reactive Patterns 1. Partition State 2. Communicate Facts 3. Isolate Mutations 4. Coordinate Dataflow 5. Localize State 6. Observe Communications 7. TBD (help out) We also have a growing catalog of