Downloaded 22 times
Uploaded byLightbend
The Reactive Principles: Eight Tenets For Building Cloud Native Applications
The document discusses the concept of cloud-native infrastructure, emphasizing that managing only the infrastructure is insufficient without considering the applications within it. It introduces reactive principles that help address the complexities of distributed systems, such as remaining responsive, accepting uncertainty, embracing failure, and asserting autonomy. By advocating for tailored consistency and decoupling time and space, the document suggests strategies for building resilient and flexible cloud-native applications.
More Related Content
Similar to The Reactive Principles: Eight Tenets For Building Cloud Native Applications
The Reactive Principles: Eight Tenets For Building Cloud Native Applications
- 2.
- 4.
- 7. Managing empty boxesis only half of the solution, it matters equally much what you put inside them
- 8. Cloud Native Applicationsneed both a: ✓ Scalable and Available Infrastructure Layer ✓ Scalable and Available Application Layer
- 9.
- 10. Addresses the challengesof 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 challengesof 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.
- 13.
- 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 respondin a timely manner
- 24. It’s easy tostay responsive during “Blue sky” scenarios
- 25. But it’s equallyimportant to stay responsive in the face of failures, communication outages, and unpredictable workloads
- 27. “An escalator cannever 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 reliabilitydespite unreliable foundations
- 30. Welcome To TheWild Ocean Of Non Determinism Distributed Systems
- 31.
- 32. Exploit Reality We need to Inour design
- 33.
- 34. Information Is Always Fromthe Past
- 35. Time We cannot alwaystrust Order Or
- 36.
- 37. We Need ToModel and manage Uncertainty Directly In The Application Architecture
- 38. “In a systemwhich 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 thingsto go wrong and design for resilience
- 44. We Need To Manage Failure NotTry To Avoid It
- 45. Resilience is by Design Photo courtesyof FEMA/Joselyne Augustino
- 46. “Accidents come from relationships not broken parts.” - Sidney dekker Driftinto Failure - Sidney Dekker
- 47. Decoupling in space allowsthe 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 ToBe 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 ToBuild Self-healing Systems
- 50.
- 51. Ⅳ Assert Autonomy Design components thatact independently And interact collaboratively
- 52. We need toCraft Autonomous Islands Of Determinism
- 53. Mutable State Needs ToBe Contained And Non Observable
- 54. Publish Facts To OutsideWorld Using well-defined Protocols
- 55. A system ofdistributed services is a never-ending stream towards convergence
- 56. A system ofdistributed services is a never-ending stream towards convergence Always in the process of convergence Never reaching the state of convergence
- 57. There Is NoNow 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 TermsOf Consistency Boundaries Small islands of strong consistency in a river of constant change and uncertainty
- 59. Data on theinside vs Data on the outside - Pat Helland
- 60. Inside Data Our currentpresent state Data on the inside vs Data on the outside - Pat Helland
- 61. Inside Data Our currentpresent state Outside Data Blast from the past facts Data on the inside vs Data on the outside - Pat Helland
- 62. Inside Data Our currentpresent 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 informationlocal, leading to greater certainty and stability.” - Mark Burgess In Search of Certainty - Mark Burgess
- 64.
- 65. ⅤTailor Consistency Individualize consistencyper component to balance availability and performance
- 66.
- 67. “Two-phase commit isthe anti-availability protocol.” - Pat Helland Standing on Distributed Shoulders of Giants - Pat Helland
- 68. Doh, you’re right. Allthose distributed transactions are heavy! Don’t carry around more guarantees than you need!!!
- 69. Strong Consistency Within TheConsistency Boundary
- 70.
- 71.
- 72. Eventual Consistency We have torely on But relax—it’s how the world works
- 73. “It's easier toask for forgiveness than it is to get permission” - Grace Hopper
- 74.
- 75. We need Systemsthat are Decoupled in Space and Time
- 76.
- 77. Decouple Time Process asynchronouslyto avoid coordination and waiting Ⅵ
- 78. “Silence is notonly golden. It is seldom misquoted.” - Bob Monkhouse
- 79.
- 80. ✓ Efficient useof resources ✓ Minimized contention Go Async Don’t block needlessly
- 82. Needs to beasync and non-blocking all the way down
- 83. Needs to beasync and non-blocking all the way down
- 84.
- 85. ⅦDecouple Space Create flexibilityby embracing the network
- 86.
- 88. Embrace The Network ✓Makedistribution first class • Avoid the mistakes of EJB, CORBA, or Network Attached Disks
- 89. Embrace The Network ✓Makedistribution first class • Avoid the mistakes of EJB, CORBA, or Network Attached Disks ✓Go Async • Use Asynchronous IO • Use Message-Passing
- 90. Embrace The Network ✓Makedistribution 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 abstractionfor Communication across all dimensions of scale
- 92. Location Transparency One abstractionfor Communication across all dimensions of scale Core Socket CPU Container Server Rack Data Center Global
- 93.
- 94.
- 95. ⅧHandle Dynamics Continuously adaptto varying demand and resources
- 96. Be Elastic React tochanges in the input rate Increasing/decreasing resources
- 97. When Resources Are Fixed Decreasethe scope of processed Inputs Signal degradation to the outside
- 98. fast producer Should neveroverload slow consumer Always Apply Back Pressure
- 99. fast producer Should neveroverload 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. PartitionState 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.
- 103.
- 104.