Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Reactive Principles: Design Principles For Cloud Native Applications

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.

E0b5787d1a1935a2800e0bbffc81c196?s=128

Jonas Bonér

December 03, 2020
Tweet

Transcript

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

    Native Applications
  2. What Does Cloud native Mean?

  3. None
  4. Why is Cloud native Infrastructure Not enough?

  5. None
  6. None
  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. Ⅰ Stay Responsive Always respond in a timely manner

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

  24. But it’s equally important to stay responsive in the face

    of failures, communication outages, and unpredictable workloads
  25. None
  26. “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
  27. Ⅱ Accept Uncertainty Build reliability despite unreliable foundations

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

  29. Exploit Reality

  30. Exploit Reality We need to In our design

  31. Information Has Latency

  32. Information Is Always From the Past

  33. Time We cannot always trust Order Or

  34. There Is No Now

  35. We Need To Model and manage Uncertainty Directly In The

    Application Architecture
  36. “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
  37. Ⅲ Embrace Failure Except things to go wrong and design

    for resilience
  38. None
  39. None
  40. None
  41. We Need To Manage Failure Not Try To Avoid It

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

  43. “Accidents come from relationships not broken parts.” - Sidney dekker

    Drift into Failure - Sidney Dekker
  44. 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
  45. 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
  46. Let It Crash To Build Self-healing Systems

  47. Ⅳ Assert Autonomy Design components that act independently And interact

    collaboratively
  48. We need to Craft Autonomous Islands Of Determinism

  49. Mutable State Needs To Be Contained And Non Observable

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

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

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

    convergence Always in the process of convergence Never reaching the state of convergence
  53. 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
  54. Think In Terms Of Consistency Boundaries Small islands of strong

    consistency in a river of constant change and uncertainty
  55. Data on the inside vs Data on the outside -

    Pat Helland
  56. Inside Data Our current present 㱺 state Data on the

    inside vs Data on the outside - Pat Helland
  57. Inside Data Our current present 㱺 state Outside Data Blast

    from the past 㱺 facts Data on the inside vs Data on the outside - Pat Helland
  58. 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
  59. “Autonomy makes information local, leading to greater certainty and stability.”

    - Mark Burgess In Search of Certainty - Mark Burgess
  60. Ⅴ Tailor Consistency Individualize consistency per component 
 to balance

    availability and performance
  61. STRONG Consistency Is the wrong default

  62. “Two-phase commit is the anti-availability protocol.” - Pat Helland Standing

    on Distributed Shoulders of Giants - Pat Helland
  63. Doh, you’re right. All those distributed transactions are heavy! Don’t

    carry around more guarantees than you need!!!
  64. Strong Consistency Within 
 The Consistency Boundary

  65. BETWEEN Consistency Boundaries It Is A ZOO

  66. BETWEEN Consistency Boundaries It Is A ZOO

  67. Eventual Consistency We have to rely on But relax—it’s how

    the world works
  68. “It's easier to ask for forgiveness than it is to

    get permission” - Grace Hopper
  69. Guess. Apologize. Compensate. Use a protocol of

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

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

  72. “Silence is not only golden. 
 It is seldom misquoted.”

    - Bob Monkhouse
  73. Temporal Coupling Reduce

  74. ✓ Efficient use of resources ✓ Minimized contention Go Async

    Don’t block needlessly
  75. None
  76. Needs to be async and non-blocking all the way down

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

  78. Ⅶ Decouple Space Create flexibility by embracing the network

  79. Spatial Coupling Reduce

  80. None
  81. Embrace The Network ✓Make distribution first class • Avoid the

    mistakes of EJB, CORBA, 
 or Network Attached Disks
  82. 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
  83. 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
  84. Location Transparency One abstraction for Communication across all dimensions of

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

    scale Core 㱺 Socket 㱺 CPU 㱺 Container 㱺 Server 㱺 
 Rack 㱺 Data Center 㱺 Global
  86. Spatial Decoupling Enables Resilience

  87. Ⅷ Handle Dynamics Continuously adapt to varying 
 demand and

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

    resources
  89. When Resources Are Fixed Decrease the scope of processed Inputs

    Signal degradation to the outside
  90. fast producer Should never overload slow consumer Always Apply Back

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

    Pressure
  92. 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
  93. 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
  94. https://principles.reactive.foundation

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

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