Reactive Systems Dave Farley http://www.davefarley.net - - PowerPoint PPT Presentation

reactive systems
SMART_READER_LITE
LIVE PREVIEW

Reactive Systems Dave Farley http://www.davefarley.net - - PowerPoint PPT Presentation

Reactive Systems Dave Farley http://www.davefarley.net @davefarley77 Reactive Systems 21st Century Architecture for 21st Century Problems Dave Farley http://www.davefarley.net @davefarley77 http://www.continuous-delivery.co.uk Our World Is


slide-1
SLIDE 1

Reactive Systems

Dave Farley

http://www.davefarley.net @davefarley77

slide-2
SLIDE 2
slide-3
SLIDE 3

Dave Farley

http://www.davefarley.net @davefarley77 http://www.continuous-delivery.co.uk

Reactive Systems

21st Century Architecture for 21st Century Problems

slide-4
SLIDE 4

Our World Is Changing

Large Applications circa 2005:

  • 10’s of Servers
  • Seconds of Response Time
  • Hours of Offline Maintenance
  • Gigabytes of Data


Large Applications Now:

  • Handheld Devices to 1000’s of multi-core

processors

  • Millisecond Response Time
  • 100% Uptime
  • Petabytes of Data
slide-5
SLIDE 5

Our World Is Changing

slide-6
SLIDE 6

The Reactive Manifesto

Responsive Elastic Resilient Message Driven

“21st Century Problems are not best solved with 20th Century Software Architectures” The Evolution of modern hardware has changed many of the common assumptions of software development

Source: www.reactivemanifesto.org

slide-7
SLIDE 7

Reactive Systems Are:

Responsive:

  • Responds in a Timely Manner
  • Cornerstone of Usability
  • Also Quick to Detect Problems
slide-8
SLIDE 8

Reactive Systems Are:

Resilient:

  • Remains Responsive in the Face of Failure
  • Resilience Depends on - Replication,

Containment, Isolation and Delegation

slide-9
SLIDE 9

Reactive Systems Are:

Elastic:

  • Remains Responsive Under

Varying Workload

  • Responds to Change in the

Input Rate By Increasing or Decreasing Resources that Service the Input

  • Decentralised Architecture,

No Contention Points, No Central Bottlenecks

slide-10
SLIDE 10

Reactive Systems Are:

Message Driven:

  • Asynchronous Message Passing is the foundation

for all of these properties

  • Loose-Coupling, Isolation, Location Transparency
  • Ability to Delegate Errors
slide-11
SLIDE 11

Properties of Reactive Systems

  • Flexible
  • Loosely-Coupled
  • Scalable
  • Easier to Develop
  • More Tolerant of Failure
  • Respond to Failure Gracefully
  • Responsive to Users
slide-12
SLIDE 12

Fractal Architecture

  • Large Systems Are Composed of Smaller Ones
  • They Depend on the Reactive Properties of Their

Constituents

  • These Benefits Operate At All Scales
  • Such Systems are Composable
slide-13
SLIDE 13

Failure Modes in Synchronous Messaging

Component ‘B’ Component ‘A’

slide-14
SLIDE 14

Synch Messaging Breeds Complexity

Component ‘B’ Component ‘A’

Synchronous Comms Increases Coupling in Location and Time

slide-15
SLIDE 15

Synch Messaging Breeds Complexity

Component ‘B’ Component ‘A’

?

slide-16
SLIDE 16

Component ‘A’

The Benefits of Asynchrony

Component ‘B’

Single Threaded! Single Threaded!

slide-17
SLIDE 17

An Example

Component ‘B’ Component ‘A’ BookStore Inventory

Order(“Continuous Delivery”) Reserve(“Continuous Delivery”) Order(“Continuous Delivery”) Reserve(“Continuous Delivery”) Ordered(“Continuous Delivery”) Ordered(“Continuous Delivery”)

slide-18
SLIDE 18

An Example

BookStore Inventory

reserving

  • rdered

reserving

Order(“Continuous Delivery”) Reserve(“Continuous Delivery”) Ordered(“Continuous Delivery”) Ordered(“Continuous Delivery”) Order(“Better Aerobatics”) Reserve(“Better Aerobatics”) Ordered(“Better Aerobatics”)

  • rdered

Ordered(“Better Aerobatics”)

slide-19
SLIDE 19

5

An Example of Idempotence

Component ‘B’

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 Expected(3) 3 4 3 4 3 3 4 1 2

Component ‘A’

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 5

slide-20
SLIDE 20

Isolation

  • Decoupling in Time and Space
  • Time - Sender and Receiver have independent lifecycle
  • Space - Location Transparency
  • Share Nothing!
  • Built on Inter-Component Communication over

Well Defined Protocols

slide-21
SLIDE 21

Isolation

Component ‘A’ Component ‘B’

slide-22
SLIDE 22

Share Nothing

Component ‘A’ Component ‘B’

slide-23
SLIDE 23

Back-Pressure

  • You Can’t Isolate Stress
  • The System as a Whole Needs to Respond

Sensibly

  • Unacceptable For a Stressed Component to Fail

Catastrophically or Loose Messages

  • Queues Represent An Unstable State - Load
  • Components Under Stress Need to Reflect This

By Applying Back-Pressure, Slowing Upstream Inputs

slide-24
SLIDE 24

Queues Represent an Unstable State

Component ‘B’ Component ‘A’

Queues are always full or always empty. Anything else is transitional, on its way to full or empty.

Slightly Faster Slightly Slower

Always Empty!

slide-25
SLIDE 25

Queues Represent an Unstable State

Queues are always full or always empty. Anything else is transitional, on its way to full or empty.

Component ‘B’ Component ‘A’ Slightly Faster Slightly Slower

Always Full!

?

slide-26
SLIDE 26

Back-Pressure

Component ‘B’ Component ‘A’ Slightly Faster Slightly Slower

Always Full!

Back-Pressure!

Component ‘n’

re!

slide-27
SLIDE 27

Eventual Consistency

Component ‘A’ Component ‘B’

slide-28
SLIDE 28

Location Transparency

  • Elastic Systems Need To React To Changes In Demand
  • We Are All Doing Distributed Computing
  • Embracing This Means There Is No Difference Between

Horizontal (Cluster) and Vertical (Multicore) Scalability

  • Components Should Be Mobile
  • One Pattern For Communications
  • Local Communications Is An Optimisation
slide-29
SLIDE 29

Linear Scalability Through Sharding

Component ‘A’ Component ‘B’

slide-30
SLIDE 30

Component ‘B2’ Component ‘B1’

Linear Scalability Through Sharding

Component ‘A’

slide-31
SLIDE 31

Modern Hardware Should Change Our Assumptions

  • For Efficient Software, The Biggest Cost is Shifting Data
  • RAM is Not Random Access
  • Disk is Not Random Access
  • SSD is Not Random Access
  • RAM is Slow, Network is Slow, Disk is Slower
slide-32
SLIDE 32

Conway’s Law

Siloed Teams Rigid Architecture

DB

UI Specialists Middleware Specialists DB Specialists

slide-33
SLIDE 33

Conway’s Law

Cross-Functional Teams Organised by Business Function Distributed Service Architecture

slide-34
SLIDE 34

Bounded Contexts

  • Each Component Is Autonomous and Isolated
  • It Only Communicates Through Well Defined Protocols
  • Works Best When Components Are Aligned With Bounded

Contexts

  • Bounded Contexts Are A Concept From Domain Drive Design

(DDD) - Eric Evans

  • Bounded Context:
  • The Context Within Which A Model Of the Problem Domain Make Sense
  • There Should Be ‘Translations’ Between Bounded Contexts - No “One Model To

Rule Them All”

  • Bounded Contexts Tend To Align With Business Functions
  • Best Way To Decompose Organisations And Systems
slide-35
SLIDE 35

Example Reactive, MicroService architecture

Public API

Notification Service Market Management Application Customer Service Application TFX Application Public Web App Contact Service Trade Report Service Account Service Customer Service Market Management Payment Service Market Makers FIX Gateways Instrument Service Notification Service Market Data Consumers Clearing Gateways Public Message Bus Execution Venue Execution Venue Execution Venue (Markets & Matching) Execution Management Service Execution Management Service Execution Management Service (Accounts & Positions)

Core Services General Services Gateway Services Gateway Services

Control Message Bus

slide-36
SLIDE 36

Where to start?

slide-37
SLIDE 37

Q&A

http://www.continuous-delivery.co.uk Dave Farley http://www.davefarley.net @davefarley77

slide-38
SLIDE 38