The Reactive Principles: Design Principles For Cloud Native Applications
•
2 likes•1,325 views
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.
More Related Content
What's hot
What's hot (20)
Similar to The Reactive Principles: Design Principles For Cloud Native Applications
Similar to The Reactive Principles: Design Principles For Cloud Native Applications (20)
More from Jonas Bonér
More from Jonas Bonér (18)
Recently uploaded
Recently uploaded (20)
The Reactive Principles: Design Principles For Cloud Native Applications
- 1. The Reactive Principles Jonas Bonér @jboner Design Principles For Cloud Native Applications
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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