Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Reactive Principles: Design Principles For Cloud Native Applications

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.

  • Be the first to comment

The Reactive Principles: Design Principles For Cloud Native Applications

  1. 1. The Reactive Principles Jonas Bonér @jboner Design Principles For Cloud  Native Applications
  2. 2. What Does Cloud native Mean?
  3. 3. Why is Cloud native Infrastructure Not enough?
  4. 4. Managing empty boxes is only half of the solution, 
 it matters equally much what you put inside them
  5. 5. Cloud Native Applications need both a: ✓ Scalable and Available Infrastructure Layer ✓ Scalable and Available Application Layer
  6. 6. Reactive shows the way
  7. 7. 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
  8. 8. 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
  9. 9. What’s the antidote?
  10. 10. Introducing the Reactive Principles https://principles.reactive.foundation
  11. 11. Introducing the Reactive Principles I. Stay Responsive https://principles.reactive.foundation
  12. 12. Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty https://principles.reactive.foundation
  13. 13. Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure https://principles.reactive.foundation
  14. 14. Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy https://principles.reactive.foundation
  15. 15. Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty III. Embrace Failure IV. Assert Autonomy V. Tailor Consistency https://principles.reactive.foundation
  16. 16. 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
  17. 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 https://principles.reactive.foundation
  18. 18. 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
  19. 19.
  20. 20. ⅠStay Responsive Always respond in a timely manner
  21. 21. It’s easy to stay responsive during “Blue sky” scenarios
  22. 22. But it’s equally important to stay responsive in the face of failures, communication outages, and unpredictable workloads
  23. 23. “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
  24. 24.
  25. 25. ⅡAccept Uncertainty Build reliability despite unreliable foundations
  26. 26. Welcome To The Wild Ocean Of Non Determinism Distributed Systems
  27. 27. Exploit Reality
  28. 28. Exploit Reality We need to In our design
  29. 29. Information Has Latency
  30. 30. Information Is Always From the Past
  31. 31. Time We cannot always trust Order Or
  32. 32. There Is No Now
  33. 33. We Need To Model and manage Uncertainty Directly In The Application Architecture
  34. 34. “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
  35. 35.
  36. 36. ⅢEmbrace Failure Except things to go wrong and design for resilience
  37. 37. We Need To Manage Failure Not Try To Avoid It
  38. 38. Resilience is by Design Photo courtesy of FEMA/Joselyne Augustino
  39. 39. “Accidents come from relationships  not broken parts.” - Sidney dekker Drift into Failure - Sidney Dekker
  40. 40. 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
  41. 41. 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
  42. 42. Let It Crash To Build Self-healing Systems
  43. 43.
  44. 44. Ⅳ Assert Autonomy Design components that act independently And interact collaboratively
  45. 45. We need to Craft Autonomous Islands Of Determinism
  46. 46. Mutable State Needs To Be Contained And Non Observable
  47. 47. Publish Facts To Outside World Using well-defined Protocols
  48. 48. A system of distributed services is a never-ending stream towards convergence
  49. 49. 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. 50. 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
  51. 51. Think In Terms Of Consistency Boundaries Small islands of strong consistency in a river of constant change and uncertainty
  52. 52. Data on the inside vs Data on the outside - Pat Helland
  53. 53. Inside Data Our current present state Data on the inside vs Data on the outside - Pat Helland
  54. 54. Inside Data Our current present state Outside Data Blast from the past facts Data on the inside vs Data on the outside - Pat Helland
  55. 55. 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
  56. 56. “Autonomy makes information local, leading to greater certainty and stability.” - Mark Burgess In Search of Certainty - Mark Burgess
  57. 57.
  58. 58. ⅤTailor Consistency Individualize consistency per component 
 to balance availability and performance
  59. 59. STRONG Consistency Is the wrong default
  60. 60. “Two-phase commit is the anti-availability protocol.” - Pat Helland Standing on Distributed Shoulders of Giants - Pat Helland
  61. 61. Doh, you’re right. All those distributed transactions are heavy! Don’t carry around more guarantees than you need!!!
  62. 62. Strong Consistency Within 
 The Consistency Boundary
  63. 63. BETWEEN Consistency Boundaries It Is A ZOO
  64. 64. BETWEEN Consistency Boundaries It Is A ZOO
  65. 65. Eventual Consistency We have to rely on But relax—it’s how the world works
  66. 66. “It's easier to ask for forgiveness than it is to get permission” - Grace Hopper
  67. 67. Guess. Apologize. Compensate. Use a protocol of
  68. 68. We need Systems that are Decoupled in Space and Time
  69. 69.
  70. 70. Decouple Time Process asynchronously to avoid coordination and waiting Ⅵ
  71. 71. “Silence is not only golden. 
 It is seldom misquoted.” - Bob Monkhouse
  72. 72. Temporal Coupling Reduce
  73. 73. ✓ Efficient use of resources ✓ Minimized contention Go Async Don’t block needlessly
  74. 74. Needs to be async and non-blocking all the way down
  75. 75. Needs to be async and non-blocking all the way down
  76. 76.
  77. 77. ⅦDecouple Space Create flexibility by embracing the network
  78. 78. Spatial Coupling Reduce
  79. 79. Embrace The Network ✓Make distribution first class • Avoid the mistakes of EJB, CORBA, 
 or Network Attached Disks
  80. 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
  81. 81. 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
  82. 82. Location Transparency One abstraction for Communication across all dimensions of scale
  83. 83. Location Transparency One abstraction for Communication across all dimensions of scale Core Socket CPU Container Server 
 Rack Data Center Global
  84. 84. Spatial Decoupling Enables Resilience
  85. 85.
  86. 86. ⅧHandle Dynamics Continuously adapt to varying 
 demand and resources
  87. 87. Be Elastic React to changes in the input rate Increasing/decreasing resources
  88. 88. When Resources Are Fixed Decrease the scope of processed Inputs Signal degradation to the outside
  89. 89. fast producer Should never overload slow consumer Always Apply Back Pressure
  90. 90. fast producer Should never overload slow consumer Always Apply Back Pressure
  91. 91. 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
  92. 92. 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
  93. 93. https://principles.reactive.foundation
  94. 94. Learn More https://principles.reactive.foundation
  95. 95. Learn More https://principles.reactive.foundation Help OUT

×