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. I gave this talk at React Conf 2014 in London. Recording available here: https://www.youtube.com/watch?v=mBFdj7w4aFA

1. Reactive Supply to
Changing Demand
Building Elastic Reactive Systems
Jonas Bonér
Typesafe
CTO & co-founder
@jboner

2. Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
2

3. Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
3

4. The rules of the game
have changed

5. 5
Yesterday Today

6. 5
Yesterday Today
Single machines

7. 5
Yesterday Today
Single machines Clusters of machines

8. 5
Yesterday Today
Single machines Clusters of machines
Single core processors

9. 5
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors

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

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

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

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

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

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

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

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

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

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

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

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

23. Cost Gravity is at Work
7

24. Cost Gravity is at Work
7

25. The Principles of Reactive Systems

26. The Principles of Reactive Systems

27. Elastic
“Capable of ready change or easy expansion or contraction”
- Merriam Webster

28. Why do we need to
Scale on Demand?

29. what is
scalability?

30. 12
“Capable of being easily expanded or upgraded on demand”
- Merriam Webster Dictionary

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

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

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

34. Scalability
vs
Performance

35. Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
16

36. UP Scale

37. UP Scale
and down

38. 18
Modern CPU architecture

39. 18
Modern CPU architecture

40. 18
Modern CPU architecture

41. 18
Modern CPU architecture

42. The CPU is gambling—taking bets
19

43. Maximize Locality of Reference

44. Minimize
Contention

45. Common points of
22
contention
Physical Application

46. 23
Never

47. 23
Neevveerr

48. Block
23
Neevveerr

49. 24
GO

50. Async
24
GO

51. 25
NOTHING share

52. Divide & Conquer
26

53. 27
Single Writer Principle

54. 27
Single Writer Principle
Producers IO device
SERIAL &
CONTENDED

55. 27
Single Writer Principle
Producers IO device
SERIAL &
CONTENDED
Producers Actor or Queue IO device
BATCHED &
UNCONTENDED

56. 28

57. 29
Needs to be async and non-blocking
all the way down

58. 29
Needs to be async and non-blocking
all the way down

59. The Role of Immutable State
30

60. The Role of Immutable State
30

61. The Role of Immutable State
• Great to represent facts
• Messages and Events
• Database snapshots
• Representing the succession of time
30

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

63. on Demand Scale

64. Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
32

65. Scale
OUT

66. Scale
OUT
and in

67. • Mobile
• Cloud Services, REST etc.
• NOSQL DBs
• Big Data
• etc
34
Distributed Computing is the new normal

68. What is the essence of
distributed computing?
35
To try to overcome that

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

70. 36

71. Node Node Node
36
Node

72. Middleware
Node Node Node
36
Node

73. Cluster/Rack/Datacenter
Cluster/Rack/Datacenter
Cluster/Rack/Datacenter
Middleware
Node Node Node
36
Node

74. 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
37
Peter Deutsch’s
8 Fallacies of
Distributed
Computing

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

76. Maximize Locality of Reference

77. Strong
Consistency

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

79. Strong Consistency Protocols

80. Minimize
Contention
(Coordination in the Cluster)

81. 44
CAP Theorem

82. 44
CAP Theorem

83. Eventual
Consistency

84. 46
CRDT CvRDTs/CmRDTs

85. Life beyond Distributed Transactions:
47
an Apostate’s Opinion
“In general, application developers simply do not
implement large scalable applications assuming
distributed transactions.”
-­‐
Pat Helland

86. 48
Domain Events
“State transitions are an important part of our problem
space and should be modeled within our domain.”
- Greg Young

87. 49
The Event Log
"The database is a cache of a subset of the log.”
- Pat Helland

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

89. Outline
1. Introduction
2. Scale Up
3. Scale Out
4. Bring It Together
51

90. NOTHING
52
share

91. TRANSPARENCY
53
location

92. 54

93. 54

94. 55

95. CPU
L1/CPU
L2
Cache
Core
CPU
CPU
L1/CPU
L2
Cache
Core
Socket
ThreTahreadd CPUCPU CPU
MachMiacnhinee NodNeode ClustCleusterr JVMJVM Data
Center
55
Data
Socket
Center

96. 56
Scaling Up and Out is essentially
the same thing

97. 56
Scaling Up and Out is essentially
the same thing

99. Elasticity requires a
Message-Driven
Architecture

100. Questions?

101. Reactive Supply to
Changing Demand
Building Elastic Reactive Systems
Jonas Bonér
Typesafe
CTO & co-founder
@jboner