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

The Reactive Principles: Design Principles For ...

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.

Jonas Bonér

December 03, 2020
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

Transcript

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


    it matters equally much what you put inside them
  2. Cloud Native Applications need both a: ✓ Scalable and Available

    Infrastructure Layer ✓ Scalable and Available Application Layer
  3. 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
  4. 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
  5. Introducing the Reactive Principles I. Stay Responsive II. Accept Uncertainty

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

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

    III. Embrace Failure IV. Assert Autonomy V. Tailor Consistency https://principles.reactive.foundation
  8. 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
  9. 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
  10. 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
  11. But it’s equally important to stay responsive in the face

    of failures, communication outages, and unpredictable workloads
  12. “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
  13. “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
  14. 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
  15. 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
  16. A system of distributed services is a never-ending stream towards

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

    consistency in a river of constant change and uncertainty
  19. Inside Data Our current present 㱺 state Data on the

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

    from the past 㱺 facts Data on the inside vs Data on the outside - Pat Helland
  21. 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
  22. “It's easier to ask for forgiveness than it is to

    get permission” - Grace Hopper
  23. Embrace The Network ✓Make distribution first class • Avoid the

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

    scale Core 㱺 Socket 㱺 CPU 㱺 Container 㱺 Server 㱺 
 Rack 㱺 Data Center 㱺 Global
  27. 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
  28. 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