Reactive Supply To Changing Demand

4,025 views

Published on

Abstract:
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

Published in: Engineering
0 Comments
28 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,025
On SlideShare
0
From Embeds
0
Number of Embeds
927
Actions
Shares
0
Downloads
85
Comments
0
Likes
28
Embeds 0
No embeds

No notes for slide

Reactive Supply To Changing Demand

  1. 1. Reactive Supply to Changing Demand Building Elastic Reactive Systems Jonas Bonér Typesafe CTO & co-founder @jboner
  2. 2. Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 2
  3. 3. Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 3
  4. 4. The rules of the game have changed
  5. 5. 5 Yesterday Today
  6. 6. 5 Yesterday Today Single machines
  7. 7. 5 Yesterday Today Single machines Clusters of machines
  8. 8. 5 Yesterday Today Single machines Clusters of machines Single core processors
  9. 9. 5 Yesterday Today Single machines Clusters of machines Single core processors Multicore processors
  10. 10. 5 Yesterday Today Single machines Clusters of machines Single core processors Multicore processors Expensive RAM
  11. 11. 5 Yesterday Today Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM
  12. 12. 5 Yesterday Today Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk
  13. 13. 5 Yesterday Today Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk
  14. 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. 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. 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. 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. 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. 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. 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. 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. 22. Cost Gravity is at Work 7
  23. 23. Cost Gravity is at Work 7
  24. 24. The Principles of Reactive Systems
  25. 25. The Principles of Reactive Systems
  26. 26. Elastic “Capable of ready change or easy expansion or contraction” - Merriam Webster
  27. 27. Why do we need to Scale on Demand?
  28. 28. what is scalability?
  29. 29. 12 “Capable of being easily expanded or upgraded on demand” - Merriam Webster Dictionary
  30. 30. 13 “The house in which Amdahl wakes up very early each day and rules with an iron fist.” - Martin Thompson (originally Gil Tene)
  31. 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. 32. 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
  33. 33. Scalability vs Performance
  34. 34. Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 16
  35. 35. UP Scale
  36. 36. UP Scale and down
  37. 37. 18 Modern CPU architecture
  38. 38. 18 Modern CPU architecture
  39. 39. 18 Modern CPU architecture
  40. 40. 18 Modern CPU architecture
  41. 41. The CPU is gambling—taking bets 19
  42. 42. Maximize Locality of Reference
  43. 43. Minimize Contention
  44. 44. Common points of 22 contention Physical Application
  45. 45. 23 Never
  46. 46. 23 Neevveerr
  47. 47. Block 23 Neevveerr
  48. 48. 24 GO
  49. 49. Async 24 GO
  50. 50. 25 NOTHING share
  51. 51. Divide & Conquer 26
  52. 52. 27 Single Writer Principle
  53. 53. 27 Single Writer Principle Producers IO device SERIAL & CONTENDED
  54. 54. 27 Single Writer Principle Producers IO device SERIAL & CONTENDED Producers Actor or Queue IO device BATCHED & UNCONTENDED
  55. 55. 28
  56. 56. 29 Needs to be async and non-blocking all the way down
  57. 57. 29 Needs to be async and non-blocking all the way down
  58. 58. The Role of Immutable State 30
  59. 59. The Role of Immutable State 30
  60. 60. The Role of Immutable State • Great to represent facts • Messages and Events • Database snapshots • Representing the succession of time 30
  61. 61. 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
  62. 62. on Demand Scale
  63. 63. Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 32
  64. 64. Scale OUT
  65. 65. Scale OUT and in
  66. 66. • Mobile • Cloud Services, REST etc. • NOSQL DBs • Big Data • etc 34 Distributed Computing is the new normal
  67. 67. What is the essence of distributed computing? 35 To try to overcome that
  68. 68. 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
  69. 69. 36
  70. 70. Node Node Node 36 Node
  71. 71. Middleware Node Node Node 36 Node
  72. 72. Cluster/Rack/Datacenter Cluster/Rack/Datacenter Cluster/Rack/Datacenter Middleware Node Node Node 36 Node
  73. 73. 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 37 Peter Deutsch’s 8 Fallacies of Distributed Computing
  74. 74. 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
  75. 75. Maximize Locality of Reference
  76. 76. Strong Consistency
  77. 77. 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
  78. 78. Strong Consistency Protocols
  79. 79. Minimize Contention (Coordination in the Cluster)
  80. 80. 44 CAP Theorem
  81. 81. 44 CAP Theorem
  82. 82. Eventual Consistency
  83. 83. 46 CRDT CvRDTs/CmRDTs
  84. 84. Life beyond Distributed Transactions: 47 an Apostate’s Opinion “In general, application developers simply do not implement large scalable applications assuming distributed transactions.” -­‐ Pat Helland
  85. 85. 48 Domain Events “State transitions are an important part of our problem space and should be modeled within our domain.” - Greg Young
  86. 86. 49 The Event Log "The database is a cache of a subset of the log.” - Pat Helland
  87. 87. 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
  88. 88. Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 51
  89. 89. NOTHING 52 share
  90. 90. TRANSPARENCY 53 location
  91. 91. 54
  92. 92. 54
  93. 93. 55
  94. 94. CPU L1/CPU L2 Cache Core CPU CPU L1/CPU L2 Cache Core Socket ThreTahreadd CPUCPU CPU MachMiacnhinee NodNeode ClustCleusterr JVMJVM Data Center 55 Data Socket Center
  95. 95. 56 Scaling Up and Out is essentially the same thing
  96. 96. 56 Scaling Up and Out is essentially the same thing
  97. 97. Elasticity requires a Message-Driven Architecture
  98. 98. Questions?
  99. 99. Reactive Supply to Changing Demand Building Elastic Reactive Systems Jonas Bonér Typesafe CTO & co-founder @jboner

×