Reactive Supply To Changing Demand

download Reactive Supply To Changing Demand

of 114

  • date post

    19-Aug-2014
  • Category

    Engineering

  • view

    818
  • download

    12

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

Transcript of Reactive Supply To Changing Demand

  • Reactive Supply to Changing Demand Jonas Bonr Typesafe CTO & co-founder @jboner Scalable Trait: React 2014
  • Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 2
  • Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 3
  • 4
  • 4
  • What is Scalability?
  • 6 The house in which Amdahl wakes up very early each day and rules with an iron fist. - Martin Thompson (originally Gil Tene)
  • 6 The house in which Amdahl wakes up very early each day and rules with an iron fist. - Martin Thompson (originally Gil Tene)
  • 7 Capable of being easily expanded or upgraded on demand - Merriam Webster Dictionary
  • 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
  • Scalability vs Performance
  • Why do we need to Scale on Demand?
  • The rules of the game have changed
  • 12 Apps in the 60s-90s were written for Apps today are written for
  • 12 Apps in the 60s-90s were written for Apps today are written for Single machines
  • 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines
  • 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors
  • 12 Apps in the 60s-90s were written for Apps today are written for Single machines Clusters of machines Single core processors Multicore processors
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 14
  • 14
  • 14
  • 14
  • Cost Gravity is at Work 15
  • Cost Gravity is at Work 15
  • Outline 1. Introduction 2. Scale Up 3. Scale Out 4. Bring It Together 16
  • UP Scale
  • 18 Modern CPU architecture
  • 18 Modern CPU architecture
  • 18 Modern CPU architecture
  • The CPU is gambling. Taking bets. 19
  • Maximize Locality of Reference
  • Minimize Contention
  • Common points of ApplicationPhysical contention
  • 23 Neverever
  • 23 Never ever
  • Block 23 Never ever
  • 24 GO
  • Async 24 GO
  • Divide & Conquer 25
  • 26
  • 27 Single Writer Principle
  • 27 Single Writer Principle IO deviceProducers SERIAL & CONTENDED
  • 27 Single Writer Principle IO deviceProducers SERIAL & CONTENDED IO deviceProducers Actor or Queue BATCHED & UNCONTENDED
  • The Role of Immutable State 28
  • The Role of Immutable State 28
  • The Role of Immutable State Great to represent facts Events Database snapshots 28
  • 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
  • 29 Needs to be async and non-blocking all the way down
  • 29 Needs to be async and non-blocking all the way down or Amdahls Law will hunt you down
  • 29 Needs to be async and non-blocking all the way down or Amdahls Law will hunt you down