Reactive Supply to
Changing Demand
Jonas Bonér
Typesafe
CTO & co-founder
@jboner
Building Elastic Reactive Systems
Slide 2
Slide 2 text
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
2
Slide 3
Slide 3 text
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
3
Slide 4
Slide 4 text
The rules of the game
have changed
Slide 5
Slide 5 text
5
Yesterday Today
Slide 6
Slide 6 text
5
Yesterday Today
Single machines
Slide 7
Slide 7 text
5
Yesterday Today
Single machines Clusters of machines
Slide 8
Slide 8 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors
Slide 9
Slide 9 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Slide 10
Slide 10 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Expensive RAM
Slide 11
Slide 11 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Slide 12
Slide 12 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk
Slide 13
Slide 13 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
Slide 14
Slide 14 text
5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
Slow networks
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
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
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
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
Slide 21
Slide 21 text
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
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
Cost Gravity is at Work
7
Slide 24
Slide 24 text
Cost Gravity is at Work
7
Slide 25
Slide 25 text
The Principles of Reactive Systems
Slide 26
Slide 26 text
The Principles of Reactive Systems
Slide 27
Slide 27 text
Elastic
“Capable of ready change or easy expansion or contraction”
- Merriam Webster
Slide 28
Slide 28 text
Scale on Demand?
Why do we need to
Slide 29
Slide 29 text
scalability?
what is
Slide 30
Slide 30 text
12
“Capable of being easily expanded or upgraded on demand”
- Merriam Webster Dictionary
Slide 31
Slide 31 text
13
“The house in which Amdahl wakes up very early each day and
rules with an iron fist.”
- Martin Thompson (originally Gil Tene)
Slide 32
Slide 32 text
13
“The house in which Amdahl wakes up very early each day and
rules with an iron fist.”
- Martin Thompson (originally Gil Tene)
Slide 33
Slide 33 text
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
Slide 34
Slide 34 text
vs
Scalability
Performance
Slide 35
Slide 35 text
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
16
Slide 36
Slide 36 text
UP
Scale
Slide 37
Slide 37 text
UP
Scale
and down
Slide 38
Slide 38 text
18
Modern CPU architecture
Slide 39
Slide 39 text
18
Modern CPU architecture
Slide 40
Slide 40 text
18
Modern CPU architecture
Slide 41
Slide 41 text
18
Modern CPU architecture
Slide 42
Slide 42 text
The CPU is gambling—taking bets
19
Slide 43
Slide 43 text
Maximize
Locality of Reference
Slide 44
Slide 44 text
Minimize
Contention
Slide 45
Slide 45 text
Common points of
Application
Physical
contention
Slide 46
Slide 46 text
23
Never
ever
Slide 47
Slide 47 text
23
Never
ever
Slide 48
Slide 48 text
Block
23
Never
ever
Slide 49
Slide 49 text
24
GO
Slide 50
Slide 50 text
Async
24
GO
Slide 51
Slide 51 text
25
NOTHING
share
Slide 52
Slide 52 text
Divide & Conquer
26
Slide 53
Slide 53 text
27
Single Writer Principle
Slide 54
Slide 54 text
27
Single Writer Principle
IO device
Producers
SERIAL &
CONTENDED
Slide 55
Slide 55 text
27
Single Writer Principle
IO device
Producers
SERIAL &
CONTENDED
IO device
Producers Actor or Queue
BATCHED &
UNCONTENDED
Slide 56
Slide 56 text
28
Slide 57
Slide 57 text
29
Needs to be async and non-blocking
all the way down
Slide 58
Slide 58 text
29
Needs to be async and non-blocking
all the way down
Slide 59
Slide 59 text
The Role of Immutable State
30
Slide 60
Slide 60 text
The Role of Immutable State
30
Slide 61
Slide 61 text
The Role of Immutable State
• Great to represent facts
• Messages and Events
• Database snapshots
• Representing the succession of time
30
Slide 62
Slide 62 text
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
Slide 63
Slide 63 text
on Demand
Scale
Slide 64
Slide 64 text
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
32
Slide 65
Slide 65 text
OUT
Scale
Slide 66
Slide 66 text
OUT
Scale
and in
Slide 67
Slide 67 text
• Mobile
• Cloud Services, REST etc.
• NOSQL DBs
• Big Data
• etc
34
Distributed Computing is the
new normal
Slide 68
Slide 68 text
What is the essence of
distributed computing?
35
To try to overcome that
Slide 69
Slide 69 text
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
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
Slide 75
Slide 75 text
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
Slide 76
Slide 76 text
Maximize
Locality of Reference
Slide 77
Slide 77 text
Strong
Consistency
Slide 78
Slide 78 text
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
Slide 79
Slide 79 text
Strong Consistency Protocols
Slide 80
Slide 80 text
(Coordination in the Cluster)
Minimize
Contention
Slide 81
Slide 81 text
44
CAP
Theorem
Slide 82
Slide 82 text
44
CAP
Theorem
Slide 83
Slide 83 text
Consistency
Eventual
Slide 84
Slide 84 text
46
CRDT
CvRDTs/CmRDTs
Slide 85
Slide 85 text
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
Slide 86
Slide 86 text
48
“State transitions are an important part of our problem
space and should be modeled within our domain.”
- Greg Young
Domain Events
Slide 87
Slide 87 text
49
"The database is a cache of a subset of the log.”
- Pat Helland
The Event Log
Slide 88
Slide 88 text
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
Slide 89
Slide 89 text
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
51
Slide 90
Slide 90 text
NOTHING
52
share
Slide 91
Slide 91 text
TRANSPARENCY
53
location
Slide 92
Slide 92 text
54
Slide 93
Slide 93 text
54
Slide 94
Slide 94 text
55
Slide 95
Slide 95 text
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
Slide 96
Slide 96 text
56
Scaling Up and Out is essentially
the same thing
Slide 97
Slide 97 text
56
Scaling Up and Out is essentially
the same thing
Slide 98
Slide 98 text
No content
Slide 99
Slide 99 text
Elasticity requires a
Message-Driven
Architecture
Slide 100
Slide 100 text
Questions?
Slide 101
Slide 101 text
Reactive Supply to
Changing Demand
Jonas Bonér
Typesafe
CTO & co-founder
@jboner
Building Elastic Reactive Systems