Abstract: The demands and expectations for applications have changed dramatically in recent years. Applications today are deployed on a wide range of infrastructure; from mobile devices up to thousands of nodes running in the cloud—all powered by multi-core processors. They need to be rich and collaborative, have a real-time feel with millisecond response time and should never stop running. Additionally, modern applications are a mashup of external services that need to be consumed and composed to provide the features at hand. We are seeing a new type of applications emerging to address these new challenges—these are being called Reactive Applications. In this talk we will discuss four key traits of Reactive; Responsive, Resilient, Elastic and Message-Driven—how they impact application design, how they interact, their supporting technologies and techniques, how to think when designing and building them—all to make it easier for you and your team to Go Reactive. Intended Audience: Programmers, architects, CIO/CTOs and everyone with a desire to challenge the status quo and expand their horizons on how to tackle the current and future challenges in the computing industry.

1. Go Reactive
Building Responsive, Resilient,
Elastic & Message-Driven Systems
Jonas Bonér
CTO Typesafe
@jboner

3. The rules of the game
have changed

4. 3
Yesterday Today

5. 3
Yesterday Today
Single machines Clusters of machines

6. 3
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors

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

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

9. 3
Yesterday Today
Single machines Clusters of machines
Single core processors Multicore processors
Expensive RAM Cheap RAM
Expensive disk Cheap disk
Slow networks Fast networks

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

11. 3
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. 3
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. Reactive
“Readily responsive to a stimulus”
- Merriam Webster

15. The Principles of Reactive Systems
Reactive
Applications
6

17. http://reactivemanifesto.org

18. Responsive
“Quick to respond or react appropriately”
- Merriam Webster

19. 9
The system should
always be responsive

20. 9
The system should
always be responsive
1. Blue skies
2. Heavy load
3. Failures

21. Resilient
“The ability of a substance or object to spring back into shape”
“The capacity to recover quickly from difficulties”
- Merriam Webster

22. Think Vending Machine

23. Think Vending Machine
Coffee
Programmer Machine

24. Think Vending Machine
Coffee
Inserts coins
Programmer Machine

25. Think Vending Machine
Coffee
Inserts coins
Add more coins
Programmer Machine

26. Think Vending Machine
Coffee
Inserts coins
Add more coins
Programmer Machine
Gets coffee

27. Think Vending Machine
Coffee
Programmer Machine

28. Think Vending Machine
Coffee
Inserts coins
Programmer Machine

29. Think Vending Machine
Coffee
Inserts coins
Out of coffee beans error
Programmer Machine

30. Think Vending Machine
Coffee
Inserts coins
Out of coffee beans error WRONG
Programmer Machine

31. Think Vending Machine
Coffee
Inserts coins
Programmer Machine

32. Think Vending Machine
Coffee
Inserts coins
Out of
coffee beans
failure
Programmer Machine

33. Think Vending Machine
Service
Guy
Coffee
Inserts coins
Out of
coffee beans
failure
Programmer Machine

34. Think Vending Machine
Service
Guy
Coffee
Inserts coins
Out of
coffee beans
failure
Programmer Machine
Adds
more
beans

35. Think Vending Machine
Service
Guy
Coffee
Inserts coins
Programmer Machine
Gets coffee
Out of
coffee beans
failure
Adds
more
beans

36. The Right Way
Client Service

37. The Right Way
Request
Client Service

38. The Right Way
Request
Client Service
Response

39. The Right Way
Request
Validation Error
Client Service
Response

40. The Right Way
Request
Validation Error
Client Service
Response
Application
Failure

41. The Right Way
Supervisor
Request
Validation Error
Client Service
Response
Application
Failure

42. The Right Way
Supervisor
Request
Validation Error
Client Service
Response
Application
Failure
Manages
Failure

44. Resilience Is
By Design

46. Use Bulkheads
1. Isolate the failure
2. Compartmentalize
3. Manage failure locally
4. Avoid cascading failures

47. Use Bulkheads
1. Isolate the failure
2. Compartmentalize
3. Manage failure locally
4. Avoid cascading failures

48. Enter Supervision

49. Supervisor hierarchies
A
Foo Bar
B
C
B
E
A
D
C
Automatic and mandatory supervision

50. Supervisor hierarchies
A
Foo Bar
B
C
E
A
D
C
Automatic and mandatory supervision
B

51. Supervision in Akka
Every single actor has a
default supervisor strategy.
Which is usually sufficient.
But it can be overridden.
19

52. Supervision in Akka
class Supervisor extends AbstractActor {
private SupervisorStrategy strategy = new OneForOneStrategy(
10, Duration.create(1, TimeUnit.MINUTES),
DirectiveBuilder.
match(ArithmeticException.class, e -> resume()).
match(NullPointerException.class, e -> restart()).
matchAny( e -> escalate()).
build());
… // rest of actor omitted
}
}
19

54. Resilience requires a
Message-Driven
Architecture

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

56. UP Scale

57. UP Scale
and down

58. 1. Minimize Contention
2. Maximize Locality of Reference
23
We need to

59. Common points of
contention
Physical Application

60. 25
GO

61. Async
25
GO

62. 26
Never

63. 26
Neevveerr

64. Block
26
Neevveerr

65. 27
NOTHING share

66. Needs to be async and non-blocking
28
all the way down…

67. Needs to be async and non-blocking
28
all the way down…

68. 29
Single Writer Principle

69. 29
Single Writer Principle
Producers IO device
SERIAL &
CONTENDED

70. 29
Single Writer Principle
Producers IO device
SERIAL &
CONTENDED
Producers Actor or Queue IO device
BATCHED &
UNCONTENDED

71. The Role of Immutable State
30

72. The Role of Immutable State
30

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

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

75. Divide & Conquer
31

76. 32
Pipelining

77. ON DEMAND
33
scale

78. Scale
OUT

79. Scale
OUT
and in

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

81. What is the essence of
distributed systems?
36

82. What is the essence of
distributed systems?
To try to overcome that
1. Information travels at the speed of light
2. Independent things fail independently
36

83. No difference
Between a
Slow node
Dead node
37
and a

84. The network is
38

85. The network is
38
Inherently Unreliable
http://aphyr.com/posts/288-the-network-is-reliable

86. 39
Graveyard of distributed systems

87. 39
Graveyard of distributed systems
• Distributed Shared Mutable State
EVIL N
• (where N is number of nodes)

88. 39
Graveyard of distributed systems
• Distributed Shared Mutable State
EVIL N
• (where N is number of nodes)
• Serializable Distributed Transactions

89. 39
Graveyard of distributed systems
• Distributed Shared Mutable State
EVIL N
• (where N is number of nodes)
• Serializable Distributed Transactions
• Synchronous RPC

90. 39
Graveyard of distributed systems
• Distributed Shared Mutable State
EVIL N
• (where N is number of nodes)
• Serializable Distributed Transactions
• Synchronous RPC
• Guaranteed Delivery

91. 39
Graveyard of distributed systems
• Distributed Shared Mutable State
EVIL N
• (where N is number of nodes)
• Serializable Distributed Transactions
• Synchronous RPC
• Guaranteed Delivery
• Distributed Objects
• “Sucks like an inverted hurricane” - Martin Fowler

92. Instead
40

93. Instead
Embrace the Network
40
and be done with it
Use
Asynchronous
Message
Passing

94. TRANSPARENCY
41
location

95. 42

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

98. Elasticity requires a
Message-Driven
Architecture

100. Asynchronous
Message-Passing
is the enabler

101. 45
Typesafe Reactive Platform
• Purely asynchronous and non-blocking
web framework
• No container required, no inherent
bottlenecks in session management
• Actors are lightweight, isolated and and
communicate via asynchronous message
passing
• Supervision and clustering in support of
fault tolerance
• Asynchronous and immutable
programming constructs
• Composable abstractions enabling
simpler concurrency and parallelism

102. Typesafe Activator
http://typesafe.com/platform/getstarted

103. 47
Finance Internet/Social Media Mfg/Hardware Government Retail

104. Go Reactive
Building Responsive, Resilient,
Elastic & Message-Driven Systems
Jonas Bonér
CTO Typesafe
@jboner