Reactive Supply To Changing Demand

download

of 114

  • date post

    19-Aug-2014
  • Category

    Engineering
  • view

    770
  • download

    11

Embed Size (px)

description

This is the talk I gave at React Conf 2014 in London. Recording available here: https://www.youtube.com/watch?v=mBFdj7w4aFA Abstract: Reactive applications need to be able to respond to demand, be elastic and ready to scale up, down, in and outtaking full advantage of mobile, multi-core and cloud computing architecturesin 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.

transcript

<ul><li> Reactive Supply to Changing Demand Jonas Bonr Typesafe CTO &amp; co-founder @jboner Scalable Trait: React 2014 </li> <li> Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 2 </li> <li> Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 3 </li> <li> 4 </li> <li> 4 </li> <li> What is Scalability? </li> <li> 6 The house in which Amdahl wakes up very early each day and rules with an iron fist. - Martin Thompson (originally Gil Tene) </li> <li> 6 The house in which Amdahl wakes up very early each day and rules with an iron fist. - Martin Thompson (originally Gil Tene) </li> <li> 7 Capable of being easily expanded or upgraded on demand - Merriam Webster Dictionary </li> <li> 8 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 </li> <li> Scalability vs Performance </li> <li> Why do we need to Scale on Demand? </li> <li> The rules of the game have changed </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors Expensive RAM </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks Fast networks </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for 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 </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for 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 </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for 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 </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for 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 </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for 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 </li> <li> 12 Apps in the 60s-90s were written for Apps today are written for 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 </li> <li> 14 </li> <li> 14 </li> <li> 14 </li> <li> 14 </li> <li> Cost Gravity is at Work 15 </li> <li> Cost Gravity is at Work 15 </li> <li> Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 16 </li> <li> UP Scale </li> <li> 18 Modern CPU architecture </li> <li> 18 Modern CPU architecture </li> <li> 18 Modern CPU architecture </li> <li> The CPU is gambling. Taking bets. 19 </li> <li> Maximize Locality of Reference </li> <li> Minimize Contention </li> <li> Common points of ApplicationPhysical contention </li> <li> 23 Neverever </li> <li> 23 Never ever </li> <li> Block 23 Never ever </li> <li> 24 GO </li> <li> Async 24 GO </li> <li> Divide &amp; Conquer 25 </li> <li> 26 </li> <li> 27 Single Writer Principle </li> <li> 27 Single Writer Principle IO deviceProducers SERIAL &amp; CONTENDED </li> <li> 27 Single Writer Principle IO deviceProducers SERIAL &amp; CONTENDED IO deviceProducers Actor or Queue BATCHED &amp; UNCONTENDED </li> <li> The Role of Immutable State 28 </li> <li> The Role of Immutable State 28 </li> <li> The Role of Immutable State Great to represent facts Events Database snapshots 28 </li> <li> The Role of Immutable State Great to represent facts Events Database snapshots Less ideal for a working data set Persistent data structures can increase contention Instead use a Share Nothing Architecture with mutable state within each isolated processing unit 28 </li> <li> 29 Needs to be async and non-blocking all the way down </li> <li> 29 Needs to be async and non-blocking all the way down or Amdahls Law will hunt you down </li> <li> 29 Needs to be async and non-blocking all the way down or Amdahls Law will hunt you down </li> <li> 30 NOTHING share </li> <li> Scale on Demand </li> <li> Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 32 </li> <li> OUT Scale </li> <li> Distributed Computing is the ! Mobile Cloud Services, REST etc. NOSQL DBs Big Data 34 NEW NORMAL </li> <li> What is the essence of distributed computing? 35 </li> <li> What is the essence of distributed computing? To try to overcome that 1. Information travels at the speed of light 2. Independent things fail independently 35 </li> <li> 36 </li> <li> Node Node Node 36 Node </li> <li> Middleware Node Node Node 36 Node </li> <li> Cluster/Rack/Datacenter Cluster/Rack/Datacenter Cluster/Rack/Datacenter Middleware Node Node Node 36 Node </li> <li> 37 Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 37 1. The network is reliable Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 37 1. The network is reliable 2. Latency is zero Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 37 1. The network is reliable 2. Latency is zero 3. Bandwidth is infinitePeter Deutschs 8 Fallacies of Distributed Computing </li> <li> 37 1. The network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. The network is secure Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 37 1. The network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. The network is secure 5. Topology doesn't change Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 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 Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 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 Peter Deutschs 8 Fallacies of Distributed Computing </li> <li> 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 Deutschs 8 Fallacies of Distributed Computing </li> <li> 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 </li> <li> Maximize Locality of Reference </li> <li> 40 Sticky Load Balancing &amp; Sharding </li> <li> 40 </li> <li> 41 Buddy Replication </li> <li> 41 </li> <li> 42 Consistent Hashing </li> <li> 42 </li> <li> Minimize Contention (Coordination in the Cluster) </li> <li> Strong Consistency </li> <li> 45 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 &amp; Wing 1991 </li> <li> Strong Consistency Protocols </li> <li> 47 CAPTheorem </li> <li> 47 CAPTheorem </li> <li> Eventual Consistency </li> <li> 49 CRDTCvRDTs/CmRDTs </li> <li> 50 In general, application developers simply do not implement large scalable applications assuming distributed transactions. - Pat Helland Life beyond Distributed Transactions: an Apostates Opinion </li> <li> 51 State transitions are an important part of our problem space and should be modeled within our domain. - Greg Young Domain Events </li> <li> 52 "The database is a cache of a s...</li></ul>