1.
What Does
Cloud native
Mean?

2.
Why is
Cloud native
Infrastructure
Not enough?

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

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

5.
Reactive shows the way

6.
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

7.
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

8.
What’s the antidote?

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

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

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

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

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

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

15.
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

16.
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

17.
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
VIII. Handle Dynamics
https://principles.reactive.foundation

18.
Ⅰ

19.
ⅠStay Responsive
Always respond in a timely manner

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

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

22.
“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

23.
Ⅱ

24.
ⅡAccept Uncertainty
Build reliability despite unreliable foundations

25.
Welcome To The Wild Ocean Of
Non Determinism
Distributed Systems

26.
Exploit
Reality

27.
Exploit
Reality
We need to
In our design

28.
Information
Has Latency

29.
Information Is Always
From the Past

30.
Time
We cannot always trust
Order
Or

31.
There Is No
Now

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

33.
“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

34.
Ⅲ

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

36.
We Need To
Manage
Failure
Not Try To Avoid It

37.
Resilience
is by
Design
Photo courtesy of FEMA/Joselyne Augustino

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

39.
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

40.
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

41.
Let It Crash
To Build Self-healing Systems

42.
Ⅳ

43.
Ⅳ
Assert Autonomy
Design components
that act independently
And interact collaboratively

44.
We need to Craft
Autonomous Islands
Of Determinism

45.
Mutable State
Needs To Be
Contained
And Non Observable

46.
Publish Facts
To Outside World
Using well-defined Protocols

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

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

49.
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

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

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

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

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

54.
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

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

56.
Ⅴ

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

58.
STRONG
Consistency
Is the wrong default

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

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

61.
Strong Consistency Within
The Consistency Boundary

62.
BETWEEN
Consistency
Boundaries
It Is A
ZOO

63.
BETWEEN
Consistency
Boundaries
It Is A
ZOO

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

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

66.
Guess.
Apologize.
Compensate.
Use a protocol of

67.
We need Systems that are Decoupled in
Space and Time

68.
Ⅵ

69.
Decouple Time
Process asynchronously to
avoid coordination and waiting
Ⅵ

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

71.
Temporal
Coupling
Reduce

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

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

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

75.
Ⅶ

76.
ⅦDecouple Space
Create flexibility by embracing the network

77.
Spatial
Coupling
Reduce

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

79.
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

80.
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

81.
Location Transparency
One abstraction for Communication
across all dimensions of scale

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

83.
Spatial
Decoupling
Enables Resilience

84.
Ⅷ

85.
ⅧHandle Dynamics
Continuously adapt to varying
demand and resources

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

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

88.
fast producer
Should never overload
slow consumer
Always Apply
Back Pressure

89.
fast producer
Should never overload
slow consumer
Always Apply
Back Pressure

90.
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

91.
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

92.
https://principles.reactive.foundation

93.
Learn More
https://principles.reactive.foundation

94.
Learn More
https://principles.reactive.foundation
Help OUT