Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

Jonas Bonér

October 01, 2014
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

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

    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