Go Reactive: Building Responsive, Resilient, Elastic & Message-Driven Systems

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.

Transcript

1. Jonas Bonér CTO Typesafe @jboner Go Reactive Building Responsive, Resilient, Elastic & Message-Driven Systems
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. Reactive  Applications The Principles of Reactive Systems 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 1. Blue skies 2. Heavy load 3. Failures The system should always be responsive
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. Coffee Machine Programmer Think Vending Machine
24. Coffee Machine Programmer Inserts coins Think Vending Machine
25. Coffee Machine Programmer Inserts coins Add more coins Think Vending Machine
26. Coffee Machine Programmer Inserts coins Gets coffee Add more coins Think Vending Machine
27. Coffee Machine Programmer Think Vending Machine
28. Coffee Machine Programmer Inserts coins Think Vending Machine
29. Coffee Machine Programmer Inserts coins Think Vending Machine Out of coffee beans error
30. Coffee Machine Programmer Inserts coins Think Vending Machine Out of coffee beans error WRONG
31. Coffee Machine Programmer Inserts coins Think Vending Machine
32. Coffee Machine Programmer Inserts coins Out of coffee beans failure Think Vending Machine
33. Coffee Machine Programmer Service Guy Inserts coins Out of coffee beans failure Think Vending Machine
34. Coffee Machine Programmer Service Guy Inserts coins Out of coffee beans failure Adds more beans Think Vending Machine
35. Coffee Machine Programmer Service Guy Inserts coins Gets coffee Out of coffee beans failure Adds more beans Think Vending Machine
36. The Right Way Service Client
37. The Right Way Service Client Request
38. The Right Way Service Client Request Response
39. The Right Way Service Client Request Response Validation Error
40. The Right Way Service Client Request Response Validation Error Application Failure
41. The Right Way Service Client Supervisor Request Response Validation Error Application Failure
42. The Right Way Service Client Supervisor Request Response Validation Error Application Failure Manages Failure
44. Resilience Is By Design
46. 1. Isolate the failure 2. Compartmentalize 3. Manage failure locally 4. Avoid cascading failures Use Bulkheads
47. 1. Isolate the failure 2. Compartmentalize 3. Manage failure locally 4. Avoid cascading failures Use Bulkheads
48. Enter Supervision
49. A B Bar Foo C B E A D C Automatic and mandatory supervision Supervisor hierarchies
50. A B Bar Foo C E A D C Automatic and mandatory supervision Supervisor hierarchies B
51. 19 Every single actor has a default supervisor strategy. Which is usually sufficient. But it can be overridden. Supervision in Akka
52. 19 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 } } Supervision in Akka
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 Application Physical contention
60. 25 GO
61. Async 25 GO
62. 26 Never ever
63. 26 Never ever
64. Block 26 Never ever
65. 27 NOTHING share
66. 28 Needs to be async and non-blocking all the way down…
67. 28 Needs to be async and non-blocking all the way down…
68. 29 Single Writer Principle
69. 29 Single Writer Principle IO device Producers SERIAL & CONTENDED
70. 29 Single Writer Principle IO device Producers SERIAL & CONTENDED IO device Producers Actor or Queue 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. OUT Scale
79. OUT Scale 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. Slow node Dead node No difference 37 and a Between a
84. The network is 38
85. The network is 38 http://aphyr.com/posts/288-the-network-is-reliable Inherently Unreliable
86. 39 Graveyard of distributed systems
87. 39 Graveyard of distributed systems • Distributed Shared Mutable State • EVIL (where N is number of nodes) N
88. 39 Graveyard of distributed systems • Distributed Shared Mutable State • EVIL (where N is number of nodes) N • Serializable Distributed Transactions
89. 39 Graveyard of distributed systems • Distributed Shared Mutable State • EVIL (where N is number of nodes) N • Serializable Distributed Transactions • Synchronous RPC
90. 39 Graveyard of distributed systems • Distributed Shared Mutable State • EVIL (where N is number of nodes) N • Serializable Distributed Transactions • Synchronous RPC • Guaranteed Delivery
91. 39 Graveyard of distributed systems • Distributed Shared Mutable State • EVIL (where N is number of nodes) N • Serializable Distributed Transactions • Synchronous RPC • Guaranteed Delivery • Distributed Objects • “Sucks like an inverted hurricane” - Martin Fowler
92. Instead 40
93. Embrace the Network Instead 40 and be done with it Use Asynchronous Message Passing
94. TRANSPARENCY 41 location
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 • Actors are lightweight, isolated and and communicate via asynchronous message passing • Supervision and clustering in support of fault tolerance • Purely asynchronous and non-blocking web framework • No container required, no inherent bottlenecks in session management • 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. Jonas Bonér CTO Typesafe @jboner Go Reactive Building Responsive, Resilient, Elastic & Message-Driven Systems