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
   

   View Slide

2. What Does
   
   
   Cloud native
   
   
   Mean?
   

   View Slide

3. View Slide

4. Why is
   
   
   Cloud native
   
   
   Infrastructure
   
   
   Not enough?
   

   View Slide

5. View Slide

6. View Slide

7. Managing empty boxes is
   only half of the solution,
   

   it matters equally much
   what you put inside them
   

   View Slide

8. Cloud Native Applications need both a:
   
   
   ✓ Scalable and Available Infrastructure Layer
   
   
   ✓ Scalable and Available Application Layer
   

   View Slide

9. Reactive shows the way
   

   View Slide

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
    

    View Slide

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
    

    View Slide

12. What’s the antidote?
    

    View Slide

13. Introducing the
    
    
    Reactive Principles
    https://principles.reactive.foundation
    
    
    

    View Slide

14. Introducing the
    
    
    Reactive Principles
    I. Stay Responsive
    https://principles.reactive.foundation
    
    
    

    View Slide

15. Introducing the
    
    
    Reactive Principles
    I. Stay Responsive
    II. Accept Uncertainty
    https://principles.reactive.foundation
    
    
    

    View Slide

16. Introducing the
    
    
    Reactive Principles
    I. Stay Responsive
    II. Accept Uncertainty
    III. Embrace Failure
    https://principles.reactive.foundation
    
    
    

    View Slide

17. Introducing the
    
    
    Reactive Principles
    I. Stay Responsive
    II. Accept Uncertainty
    III. Embrace Failure
    IV. Assert Autonomy
    https://principles.reactive.foundation
    
    
    

    View Slide

18. Introducing the
    
    
    Reactive Principles
    I. Stay Responsive
    II. Accept Uncertainty
    III. Embrace Failure
    IV. Assert Autonomy
    V. Tailor Consistency
    https://principles.reactive.foundation
    
    
    

    View Slide

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
    
    
    

    View Slide

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
    
    
    

    View Slide

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
    
    
    

    View Slide

22. Ⅰ
    

    View Slide

23. Ⅰ
    Stay Responsive
    
    
    Always respond in a timely manner
    

    View Slide

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

    View Slide

25. But it’s equally important to
    
    
    stay responsive in the face of
    
    
    failures, communication outages,
    
    
    and unpredictable workloads
    

    View Slide

26. View Slide

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
    

    View Slide

28. Ⅱ
    

    View Slide

29. Ⅱ
    Accept Uncertainty
    
    
    Build reliability despite unreliable foundations
    

    View Slide

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

    View Slide

31. Exploit
    
    
    Reality
    

    View Slide

32. Exploit
    
    
    Reality
    We need to
    In our design
    

    View Slide

33. Information
    
    
    Has Latency
    

    View Slide

34. Information Is Always
    
    
    From the Past
    

    View Slide

35. Time
    We cannot always trust
    Order
    Or
    

    View Slide

36. There Is No
    
    
    Now
    

    View Slide

37. We Need To Model and manage
    
    
    Uncertainty
    
    
    Directly In The Application Architecture
    

    View Slide

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
    

    View Slide

39. Ⅲ
    

    View Slide

40. Ⅲ
    Embrace Failure
    
    
    Except things to go wrong and
    
    
    design for resilience
    

    View Slide

41. View Slide

42. View Slide

43. View Slide

44. We Need To
    
    
    Manage
    
    
    Failure
    
    
    Not Try To Avoid It
    

    View Slide

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

    View Slide

46. “Accidents come from relationships
    not broken parts.”
    - Sidney dekker
    Drift into Failure - Sidney Dekker
    

    View Slide

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
    

    View Slide

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
    

    View Slide

49. Let It Crash
    
    
    To Build Self-healing Systems
    

    View Slide

50. Ⅳ
    

    View Slide

51. Ⅳ
    Assert Autonomy
    
    
    Design components
    
    
    that act independently
    
    
    And interact collaboratively
    

    View Slide

52. We need to Craft
    
    
    Autonomous Islands
    
    
    Of Determinism
    

    View Slide

53. Mutable State
    
    
    Needs To Be
    
    
    Contained
    
    
    And Non Observable
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

58. Think In Terms Of Consistency Boundaries
    
    
    Small islands of strong consistency in a
    
    
    river of constant change and uncertainty
    

    View Slide

59. Data on the inside vs Data on the outside - Pat Helland
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

63. “Autonomy makes information local,
    
    
    leading to greater certainty and stability.”
    - Mark Burgess
    In Search of Certainty - Mark Burgess
    

    View Slide

64. Ⅴ
    

    View Slide

65. Ⅴ
    Tailor Consistency
    
    
    Individualize consistency per component
    

    to balance availability and performance
    

    View Slide

66. STRONG
    Consistency
    Is the wrong default
    

    View Slide

67. “Two-phase commit is the
    anti-availability protocol.”
    - Pat Helland
    Standing on Distributed Shoulders of Giants - Pat Helland
    

    View Slide

68. Doh, you’re right.
    
    
    All those distributed
    transactions are heavy!
    Don’t carry around more guarantees than you need!!!
    

    View Slide

69. Strong Consistency Within
    

    The Consistency Boundary
    

    View Slide

70. BETWEEN
    
    
    Consistency
    
    
    Boundaries
    
    
    It Is A
    
    
    ZOO
    

    View Slide

71. BETWEEN
    
    
    Consistency
    
    
    Boundaries
    
    
    It Is A
    
    
    ZOO
    

    View Slide

72. Eventual
    
    
    Consistency
    We have to rely on
    But relax—it’s how the world works
    

    View Slide

73. “It's easier to ask for forgiveness
    
    
    than it is to get permission”
    - Grace Hopper
    

    View Slide

74. Guess.
    
    
    Apologize.
    
    
    Compensate.
    Use a protocol of
    

    View Slide

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

    View Slide

76. Ⅵ
    

    View Slide

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

    View Slide

78. “Silence is not only golden.
    

    It is seldom misquoted.”
    - Bob Monkhouse
    

    View Slide

79. Temporal
    
    
    Coupling
    Reduce
    

    View Slide

80. ✓ Efficient use of resources
    
    
    ✓ Minimized contention
    Go Async
    
    
    Don’t block needlessly
    

    View Slide

81. View Slide

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

    View Slide

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

    View Slide

84. Ⅶ
    

    View Slide

85. Ⅶ
    Decouple Space
    
    
    Create flexibility by embracing the network
    

    View Slide

86. Spatial
    
    
    Coupling
    Reduce
    

    View Slide

87. View Slide

88. Embrace The Network
    ✓Make distribution first class
    
    
    • Avoid the mistakes of EJB, CORBA,
    

    or Network Attached Disks
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

92. Location Transparency
    One abstraction for Communication
    
    
    across all dimensions of scale
    Core 㱺 Socket 㱺 CPU 㱺
    Container 㱺 Server 㱺
    

    Rack 㱺 Data Center 㱺 Global
    

    View Slide

93. Spatial
    
    
    Decoupling
    Enables Resilience
    

    View Slide

94. Ⅷ
    

    View Slide

95. Ⅷ
    Handle Dynamics
    
    
    Continuously adapt to varying
    

    demand and resources
    

    View Slide

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

    View Slide

97. When Resources
    
    
    Are Fixed
    
    
    Decrease the scope of processed Inputs
    
    
    Signal degradation to the outside
    

    View Slide

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

    View Slide

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

    View Slide

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
     

     View Slide

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
     

     View Slide

102. https://principles.reactive.foundation
     

     View Slide

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

     View Slide

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

     View Slide