Reactive Summit Keynote 2020: https://www.youtube.com/watch?v=e5kek8vx2ws Abstract: Building applications for the cloud means embracing a radically different architecture than that of a traditional single-machine monolith, requiring new tools, practices, and design patterns. The cloud’s distributed nature brings its own set of concerns–building a Cloud Native, Edge Native, or Internet of Things (IoT) application means building and running a distributed system on unreliable hardware and across unreliable networks. In this keynote session by Jonas Bonér, creator of Akka, founder/CTO of Lightbend, and Chair of the Reactive Foundation, we’ll review a set of Reactive Principles that enable the design and implementation of Cloud Native applications–applications that are highly concurrent, distributed, performant, scalable, and resilient, while at the same time conserving resources when deploying, operating, and maintaining them.

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

2. What Does
Cloud native
Mean?

4. Why is
Cloud native
Infrastructure
Not enough?

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

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

9. Reactive shows the way

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

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

12. What’s the antidote?

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

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

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

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

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

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

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

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

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

22. Ⅰ

23. ⅠStay Responsive
Always respond in a timely manner

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

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

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

28. Ⅱ

29. ⅡAccept Uncertainty
Build reliability despite unreliable foundations

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

31. Exploit
Reality

32. Exploit
Reality
We need to
In our design

33. Information
Has Latency

34. Information Is Always
From the Past

35. Time
We cannot always trust
Order
Or

36. There Is No
Now

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

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

39. Ⅲ

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

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

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

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

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

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

49. Let It Crash
To Build Self-healing Systems

50. Ⅳ

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

52. We need to Craft
Autonomous Islands
Of Determinism

53. Mutable State
Needs To Be
Contained
And Non Observable

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

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

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

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

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

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

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

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

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

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

64. Ⅴ

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

66. STRONG
Consistency
Is the wrong default

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

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

69. Strong Consistency Within
The Consistency Boundary

70. BETWEEN
Consistency
Boundaries
It Is A
ZOO

71. BETWEEN
Consistency
Boundaries
It Is A
ZOO

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

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

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

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

76. Ⅵ

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

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

79. Temporal
Coupling
Reduce

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

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

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

84. Ⅶ

85. ⅦDecouple Space
Create flexibility by embracing the network

86. Spatial
Coupling
Reduce

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

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

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

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

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

93. Spatial
Decoupling
Enables Resilience

94. Ⅷ

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

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

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

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

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

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

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

102. https://principles.reactive.foundation

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

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