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
   

   View Slide

2. View Slide

3. The rules of the game
   have changed
   

   View Slide

4. 3
   Yesterday Today
   

   View Slide

5. 3
   Yesterday Today
   Single machines Clusters of machines
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

13. View Slide

14. Reactive
    “Readily responsive to a stimulus”
    - Merriam Webster
    

    View Slide

15. Reactive  Applications
    The Principles of Reactive Systems
    6
    

    View Slide

16. View Slide

17. http://reactivemanifesto.org
    

    View Slide

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

    View Slide

19. 9
    The system should
    always be responsive
    

    View Slide

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

    View Slide

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

    View Slide

22. Think Vending Machine
    

    View Slide

23. Coffee
    Machine
    Programmer
    Think Vending Machine
    

    View Slide

24. Coffee
    Machine
    Programmer
    Inserts coins
    Think Vending Machine
    

    View Slide

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

    View Slide

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

    View Slide

27. Coffee
    Machine
    Programmer
    Think Vending Machine
    

    View Slide

28. Coffee
    Machine
    Programmer
    Inserts coins
    Think Vending Machine
    

    View Slide

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

    View Slide

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

    View Slide

31. Coffee
    Machine
    Programmer
    Inserts coins
    Think Vending Machine
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

36. The Right Way
    Service
    Client
    

    View Slide

37. The Right Way
    Service
    Client
    Request
    

    View Slide

38. The Right Way
    Service
    Client
    Request
    Response
    

    View Slide

39. The Right Way
    Service
    Client
    Request
    Response
    Validation Error
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

43. View Slide

44. Resilience Is
    By Design
    

    View Slide

45. View Slide

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

    View Slide

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

    View Slide

48. Enter Supervision
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

53. View Slide

54. Resilience requires a
    Message-Driven
    Architecture
    

    View Slide

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

    View Slide

56. UP
    Scale
    

    View Slide

57. UP
    Scale
    and down
    

    View Slide

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

    View Slide

59. Common points of
    Application
    Physical
    contention
    

    View Slide

60. 25
    GO
    

    View Slide

61. Async
    25
    GO
    

    View Slide

62. 26
    Never
    ever
    

    View Slide

63. 26
    Never
    ever
    

    View Slide

64. Block
    26
    Never
    ever
    

    View Slide

65. 27
    NOTHING
    share
    

    View Slide

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

    View Slide

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

    View Slide

68. 29
    Single Writer Principle
    

    View Slide

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

    View Slide

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

    View Slide

71. The Role of Immutable State
    30
    

    View Slide

72. The Role of Immutable State
    30
    

    View Slide

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

    View Slide

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
    

    View Slide

75. Divide & Conquer
    31
    

    View Slide

76. 32
    Pipelining
    

    View Slide

77. ON DEMAND
    33
    scale
    

    View Slide

78. OUT
    Scale
    

    View Slide

79. OUT
    Scale
    and in
    

    View Slide

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

    View Slide

81. What is the essence of
    distributed systems?
    36
    

    View Slide

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
    

    View Slide

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

    View Slide

84. The network is
    38
    

    View Slide

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

    View Slide

86. 39
    Graveyard of distributed systems
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

92. Instead
    40
    

    View Slide

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

    View Slide

94. TRANSPARENCY
    41
    location
    

    View Slide

95. View Slide

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

    View Slide

97. View Slide

98. Elasticity requires a
    Message-Driven
    Architecture
    

    View Slide

99. View Slide

100. Asynchronous
     Message-Passing
     is the enabler
     

     View Slide

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
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide