The Reactive Principles: Design Principles For Cloud Native Applications

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.

Transcript

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