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

Reactive Supply To Changing Demand

Reactive Supply To Changing Demand

Reactive applications need to be able to respond to demand, be elastic and ready to scale up, down, in and out—taking full advantage of mobile, multi-core and cloud computing architectures—in real time.

In this talk we will discuss the guiding principles making this possible through the use of share-nothing and non-blocking designs, applied all the way down the stack. We will learn how to deliver systems that provide reactive supply to changing demand.

I gave this talk at React Conf 2014 in London. Recording available here: https://www.youtube.com/watch?v=mBFdj7w4aFA

E0b5787d1a1935a2800e0bbffc81c196?s=128

Jonas Bonér

July 15, 2014
Tweet

Transcript

  1. Reactive Supply to Changing Demand Jonas Bonér Typesafe CTO &

    co-founder @jboner Building Elastic Reactive Systems
  2. Outline 1. Introduction 2. Scale Up 3. Scale Out 4.

    Bring It Together 2
  3. Outline 1. Introduction 2. Scale Up 3. Scale Out 4.

    Bring It Together 3
  4. The rules of the game have changed

  5. 5 Yesterday Today

  6. 5 Yesterday Today Single machines

  7. 5 Yesterday Today Single machines Clusters of machines

  8. 5 Yesterday Today Single machines Clusters of machines Single core

    processors
  9. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors
  10. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM
  11. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM
  12. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk
  13. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk
  14. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks
  15. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks
  16. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users
  17. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users Lots of concurrent users
  18. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users Lots of concurrent users Small data sets
  19. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users Lots of concurrent users Small data sets Large data sets
  20. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users Lots of concurrent users Small data sets Large data sets Latency in seconds
  21. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks Few concurrent users Lots of concurrent users Small data sets Large data sets Latency in seconds Latency in milliseconds
  22. None
  23. Cost Gravity is at Work 7

  24. Cost Gravity is at Work 7

  25. The Principles of Reactive Systems

  26. The Principles of Reactive Systems

  27. Elastic “Capable of ready change or easy expansion or contraction”

    - Merriam Webster
  28. Scale on Demand? Why do we need to

  29. scalability? what is

  30. 12 “Capable of being easily expanded or upgraded on demand”

    - Merriam Webster Dictionary
  31. 13 “The house in which Amdahl wakes up very early

    each day and rules with an iron fist.” - Martin Thompson (originally Gil Tene)
  32. 13 “The house in which Amdahl wakes up very early

    each day and rules with an iron fist.” - Martin Thompson (originally Gil Tene)
  33. 14 “A service is said to be scalable if when

    we increase the resources in a system, it results in increased performance in a manner proportional to resources added.” - Werner Vogels
  34. vs Scalability Performance

  35. Outline 1. Introduction 2. Scale Up 3. Scale Out 4.

    Bring It Together 16
  36. UP Scale

  37. UP Scale and down

  38. 18 Modern CPU architecture

  39. 18 Modern CPU architecture

  40. 18 Modern CPU architecture

  41. 18 Modern CPU architecture

  42. The CPU is gambling—taking bets 19

  43. Maximize Locality of Reference

  44. Minimize Contention

  45. Common points of Application Physical contention

  46. 23 Never ever

  47. 23 Never ever

  48. Block 23 Never ever

  49. 24 GO

  50. Async 24 GO

  51. 25 NOTHING share

  52. Divide & Conquer 26

  53. 27 Single Writer Principle

  54. 27 Single Writer Principle IO device Producers SERIAL & CONTENDED

  55. 27 Single Writer Principle IO device Producers SERIAL & CONTENDED

    IO device Producers Actor or Queue BATCHED & UNCONTENDED
  56. 28

  57. 29 Needs to be async and non-blocking all the way

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

    down
  59. The Role of Immutable State 30

  60. The Role of Immutable State 30

  61. The Role of Immutable State • Great to represent facts

    • Messages and Events • Database snapshots • Representing the succession of time 30
  62. The Role of Immutable State • Great to represent facts

    • Messages and Events • Database snapshots • Representing the succession of time • Mutable State is ok if local and contained • Allows Single-threaded processing • Allows single writer principle • Feels more natural • Publish the results to the world as Immutable State 30
  63. on Demand Scale

  64. Outline 1. Introduction 2. Scale Up 3. Scale Out 4.

    Bring It Together 32
  65. OUT Scale

  66. OUT Scale and in

  67. • Mobile • Cloud Services, REST etc. • NOSQL DBs

    • Big Data • etc 34 Distributed Computing is the new normal
  68. What is the essence of distributed computing? 35 To try

    to overcome that
  69. What is the essence of distributed computing? 1. Information travels

    at the speed of light 2. Independent things fail independently 35 To try to overcome that
  70. 36

  71. Node Node Node 36 Node

  72. Middleware Node Node Node 36 Node

  73. Cluster/Rack/Datacenter Cluster/Rack/Datacenter Cluster/Rack/Datacenter Middleware Node Node Node 36 Node

  74. 37 1. The network is reliable 2. Latency is zero

    3. Bandwidth is infinite 4. The network is secure 5. Topology doesn't change 6. There is one administrator 7. Transport cost is zero 8. The network is homogeneous Peter Deutsch’s 8 Fallacies of Distributed Computing
  75. The Graveyard of Distributed Systems • Distributed Shared Mutable State

    • 㱺 EVIL (where N is number of nodes) • Serializable Distributed Transactions • Synchronous RPC • Guaranteed Delivery • Distributed Objects • “Sucks like an inverted hurricane” - Martin Fowler 38 N
  76. Maximize Locality of Reference

  77. Strong Consistency

  78. 41 Linearizability “Under linearizable consistency, all operations appear to have

    executed atomically in an order that is consistent with the global real-time ordering of operations.” - Herlihy & Wing 1991
  79. Strong Consistency Protocols

  80. (Coordination in the Cluster) Minimize Contention

  81. 44 CAP Theorem

  82. 44 CAP Theorem

  83. Consistency Eventual

  84. 46 CRDT CvRDTs/CmRDTs

  85. 47 “In general, application developers simply do not implement large

    scalable applications assuming distributed transactions.” -­‐  Pat Helland Life beyond Distributed Transactions: an Apostate’s Opinion
  86. 48 “State transitions are an important part of our problem

    space and should be modeled within our domain.”   - Greg Young Domain Events
  87. 49 "The database is a cache of a subset of

    the log.” - Pat Helland The Event Log
  88. The Event Log • Append-Only Logging • Database of Facts

    • Two models: • One single Event Log • Strong Consistency • Multiple sharded Event Logs • Strong + Eventual Consistency 50
  89. Outline 1. Introduction 2. Scale Up 3. Scale Out 4.

    Bring It Together 51
  90. NOTHING 52 share

  91. TRANSPARENCY 53 location

  92. 54

  93. 54

  94. 55

  95. Data Center 55 Data Center Cluster Cluster Machine Machine JVM

    JVM Node Node Thread Thread CPU CPU CPU Socket CPU Socket CPU Core CPU Core CPU L1/L2 Cache CPU L1/L2 Cache
  96. 56 Scaling Up and Out is essentially the same thing

  97. 56 Scaling Up and Out is essentially the same thing

  98. None
  99. Elasticity requires a Message-Driven Architecture

  100. Questions?

  101. Reactive Supply to Changing Demand Jonas Bonér Typesafe CTO &

    co-founder @jboner Building Elastic Reactive Systems