Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reactive Supply To Changing Demand

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

Jonas Bonér

July 15, 2014
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

Transcript

  1. Reactive Supply to Changing Demand Jonas Bonér Typesafe CTO &

    co-founder @jboner Building Elastic Reactive Systems
  2. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM
  3. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM
  4. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk
  5. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk
  6. 5 Yesterday Today Single machines Clusters of machines Single core

    processors Multicore processors Expensive RAM Cheap RAM Expensive disk Cheap disk Slow networks
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 13 “The house in which Amdahl wakes up very early

    each day and rules with an iron fist.” - Martin Thompson (originally Gil Tene)
  15. 13 “The house in which Amdahl wakes up very early

    each day and rules with an iron fist.” - Martin Thompson (originally Gil Tene)
  16. 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
  17. 27 Single Writer Principle IO device Producers SERIAL & CONTENDED

    IO device Producers Actor or Queue BATCHED & UNCONTENDED
  18. 28

  19. The Role of Immutable State • Great to represent facts

    • Messages and Events • Database snapshots • Representing the succession of time 30
  20. 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
  21. • Mobile • Cloud Services, REST etc. • NOSQL DBs

    • Big Data • etc 34 Distributed Computing is the new normal
  22. 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
  23. 36

  24. 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
  25. 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
  26. 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
  27. 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
  28. 48 “State transitions are an important part of our problem

    space and should be modeled within our domain.”   - Greg Young Domain Events
  29. 49 "The database is a cache of a subset of

    the log.” - Pat Helland The Event Log
  30. 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
  31. 54

  32. 54

  33. 55

  34. 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
  35. Reactive Supply to Changing Demand Jonas Bonér Typesafe CTO &

    co-founder @jboner Building Elastic Reactive Systems