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

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