Reactive Supply To Changing Demand
•
29 recomendaciones•4,803 vistas
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
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Reactive Supply To Changing Demand
Similar a Reactive Supply To Changing Demand (20)
Más de Jonas Bonér
Más de Jonas Bonér (14)
Último
Último (20)
Reactive Supply To Changing Demand
- 1. Reactive Supply to Changing Demand Building Elastic Reactive Systems Jonas Bonér Typesafe CTO & co-founder @jboner
- 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
- 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. Why do we need to Scale on Demand?
- 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
- 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
- 45. Common points of 22 contention Physical Application
- 46. 23 Never
- 47. 23 Neevveerr
- 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 Producers IO device SERIAL & CONTENDED
- 55. 27 Single Writer Principle Producers IO device SERIAL & CONTENDED Producers Actor or Queue IO device 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. Scale OUT
- 66. Scale OUT 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. 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
- 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
- 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
- 80. Minimize Contention (Coordination in the Cluster)
- 81. 44 CAP Theorem
- 82. 44 CAP Theorem
- 85. 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
- 86. 48 Domain Events “State transitions are an important part of our problem space and should be modeled within our domain.” - Greg Young
- 87. 49 The Event Log "The database is a cache of a subset of the log.” - Pat Helland
- 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
- 92. 54
- 93. 54
- 94. 55
- 95. 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
- 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 Building Elastic Reactive Systems Jonas Bonér Typesafe CTO & co-founder @jboner