reactive supply to changing demand
Post on 21-Apr-2017
4.055 Views
Preview:
TRANSCRIPT
Reactive Supply to Changing Demand
Jonas Bonér Typesafe
CTO & co-founder @jboner
Building Elastic Reactive Systems
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
The rules of the game
have changed
5
Yesterday Today
5
Yesterday TodaySingle machines
5
Yesterday TodaySingle machines Clusters of machines
5
Yesterday TodaySingle machines Clusters of machines
Single core processors
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
Slow networks
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
Slow networks Fast networks
5
Yesterday TodaySingle machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
Slow networks Fast networks
Few concurrent users
5
Yesterday TodaySingle 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
5
Yesterday TodaySingle 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
5
Yesterday TodaySingle 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
5
Yesterday TodaySingle 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
5
Yesterday TodaySingle 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
Cost Gravity is at Work
7
Cost Gravity is at Work
7
The Principles of Reactive Systems
The Principles of Reactive Systems
Elastic “Capable of ready change or easy expansion or contraction”
- Merriam Webster
Scale on Demand?Why do we need to
scalability?what is
12
“Capable of being easily expanded or upgraded on demand” - Merriam Webster Dictionary
13
“The house in which Amdahl wakes up very early each day and
rules with an iron fist.” - Martin Thompson (originally Gil Tene)
13
“The house in which Amdahl wakes up very early each day and
rules with an iron fist.” - Martin Thompson (originally Gil Tene)
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
vs Scalability Performance
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
16
UPScale
UPScale
and down
18
Modern CPU architecture
18
Modern CPU architecture
18
Modern CPU architecture
18
Modern CPU architecture
The CPU is gambling—taking bets
19
MaximizeLocality of Reference
MinimizeContention
Common points of
22
ApplicationPhysical
contention
23
Neverever
23
Neverever
Block
23
Neverever
24
GO
Async
24
GO
25
NOTHINGshare
Divide & Conquer
26
27
Single Writer Principle
27
Single Writer PrincipleIO deviceProducers
SERIAL & CONTENDED
27
Single Writer PrincipleIO deviceProducers
SERIAL & CONTENDED
IO deviceProducers Actor or Queue
BATCHED & UNCONTENDED
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
The Role of Immutable State
30
The Role of Immutable State
30
The Role of Immutable State• Great to represent facts
• Messages and Events
• Database snapshots
• Representing the succession of time
30
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
on DemandScale
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
32
OUTScale
OUTScale
and in
• Mobile
• Cloud Services, REST etc.
• NOSQL DBs
• Big Data
• etc
34
Distributed Computing is the
new normal
What is the essence of distributed computing?
35
To try to overcome that
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
36
Node Node Node
36
Node
Middleware
Node Node Node
36
Node
Cluster/Rack/Datacenter
Cluster/Rack/Datacenter
Cluster/Rack/Datacenter
Middleware
Node Node Node
36
Node
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
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
MaximizeLocality of Reference
Strong Consistency
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
Strong Consistency Protocols
(Coordination in the Cluster)
MinimizeContention
44
CAPTheorem
44
CAPTheorem
ConsistencyEventual
46
CRDTCvRDTs/CmRDTs
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
48
“State transitions are an important part of our problem
space and should be modeled within our domain.” - Greg Young
Domain Events
49
"The database is a cache of a subset of the log.” - Pat Helland
The Event Log
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
Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
51
NOTHING
52
share
TRANSPARENCY
53
location
54
54
55
Data Center
55
Data Center
ClusterClusterMachineMachineJVMJVMNodeNodeThreadThreadCPUCPUCPU Socket
CPU Socket
CPU Core
CPU Core
CPU L1/L2 Cache
CPU L1/L2 Cache
56
Scaling Up and Out is essentially
the same thing
56
Scaling Up and Out is essentially
the same thing
Elasticity requires aMessage-DrivenArchitecture
Questions?
Reactive Supply to Changing Demand
Jonas Bonér Typesafe
CTO & co-founder @jboner
Building Elastic Reactive Systems
top related