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

Reactive Microsystems: The Evolution of Microservices at Scale

Jonas Bonér
October 03, 2017

Reactive Microsystems: The Evolution of Microservices at Scale

Everyone is talking about Microservices and there is more confusion than ever about what the promise of Microservices really means—and how to deliver on it. To address this situation, we will explore Microservices from first principles, distill their essence and put them in their true context: Distributed Systems.

Distributed Systems is very hard and we—system developers—have been spoiled by centralized servers for too long. Slicing an existing system into various REST services and wiring them back together again with synchronous protocols and traditional enterprise tools—designed for Monolithic architectures—will set us up for failure. 

As if that wasn’t enough, we can’t only think about systems of Microservices. In order to make each Microservice scalable and resilient in and of itself, we have to design each Microservice as a Distributed System—a «Microsystem»—architected from the ground up using the Reactive principles and Events-first Domain Driven Design. 

In this talk I’ll walk you through the evolution of such a system, discussing what you need to know in order to design a Scalable Microservices Architecture.

Jonas Bonér

October 03, 2017
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

Transcript

  1. REACTIVE MICROSYSTEMS
    THE EVOLUTION OF MICROSERVICES AT SCALE
    JONAS BONÉR
    @JBONER

    View Slide

  2. WE HAVE BEEN SPOILED BY
    THE ALMIGHTY
    MONOLITH

    View Slide

  3. KNOCK, KNOCK. WHO’S THERE?
    REALITY

    View Slide

  4. View Slide

  5. WE CAN'T MAKE THE HORSE FASTER

    View Slide

  6. WE NEED CARS FOR WHERE WE ARE GOING

    View Slide

  7. BUT DON'T JUST DRINK THE
    THINK FOR YOURSELF

    View Slide

  8. NO ONE WANTS
    MICROSERVICES
    IT'S A NECCESSARY EVIL

    View Slide

  9. ARCHITECTURAL CONTEXT OF MICROSERVICES:
    DISTRIBUTED SYSTEMS

    View Slide

  10. TODAY'S JOURNEY

    View Slide

  11. LET'S SAY THAT WE WANT TO SLICE THIS MONOLITH UP

    View Slide

  12. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS

    View Slide

  13. MICROLITH:
    SINGLE INSTANCE
    MICROSERVICE
    -NOT RESILIENT
    -NOT ELASTIC

    View Slide

  14. One actor is no actor.
    Actors come in systems.
    — Carl Hewitt

    View Slide

  15. MICROSERVICES
    COME IN SYSTEMS

    View Slide

  16. 3 HELPFUL TOOLS
    1. EVENTS-FIRST DDD
    2. REACTIVE DESIGN
    3. EVENT-BASED PERSISTENCE

    View Slide

  17. PRACTICE
    EVENTS-FIRST
    DOMAIN-DRIVEN DESIGN

    View Slide

  18. DON'T FOCUS ON THE THINGS
    the nouns
    the domain objects
    FOCUS ON WHAT HAPPENS
    the verbs
    the events

    View Slide

  19. When you start modeling events,
    it forces you to think about the
    behavior of the system,
    as opposed to thinking about
    structure inside the system.
    — Greg Young

    View Slide

  20. LET THE
    EVENTS DEFINE
    THE BOUNDED CONTEXT

    View Slide

  21. EVENTS REPRESENT FACTS

    View Slide

  22. To condense fact from
    the vapor of nuance
    — Neal Stephenson, Snow Crash

    View Slide

  23. WHAT ARE THE FACTS?

    View Slide

  24. TRY OUT
    EVENT STORMING

    View Slide

  25. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED
    HOW FACTS FLOW IN THE SYSTEM

    View Slide

  26. THINK IN TERMS OF
    CONSISTENCY BOUNDARIES

    View Slide

  27. WE NEED TO
    CONTAIN MUTABLE STATE &
    PUBLISH FACTS

    View Slide

  28. AGGREGATE
    㱺 UNIT OF CONSISTENCY
    㱺 UNIT OF FAILURE

    View Slide

  29. PRACTICE
    REACTIVE DESIGN

    View Slide

  30. REACTIVE PROGRAMMING
    VS
    REACTIVE SYSTEMS

    View Slide

  31. REACTIVE PROGRAMMING
    CAN HELP US MAKE THE
    INDIVIDUAL INSTANCE
    HIGHLY PERFORMANT & EFFICIENT

    View Slide

  32. GO
    ASYNCHRONOUS

    View Slide

  33. ASYNCHRONOUS
    & NON-BLOCKING
    - MORE EFFICIENT USE OF RESOURCES
    - MINIMIZES CONTENTION ON SHARED
    RESOURCES

    View Slide

  34. ALWAYS APPLY BACKPRESSURE
    A FAST SYSTEM
    SHOULD NOT OVERLOAD
    A SLOW SYSTEM

    View Slide

  35. BACKPRESSURE

    View Slide

  36. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS

    View Slide

  37. WE'RE GETTING THERE, BUT WE STILL HAVE A
    SINGLE INSTANCE MICROSERVICE
    㱺 NOT SCALABLE
    㱺 NOT RESILIENT

    View Slide

  38. REACTIVE SYSTEMS
    CAN HELP US BUILD
    DISTRIBUTED SYSTEMS THAT ARE
    ELASTIC & RESILIENT

    View Slide

  39. REACTIVE SYSTEMS ARE BASED ON
    ASYNCHRONOUS
    MESSAGE-PASSING

    View Slide

  40. ALLOWS DECOUPLING IN
    SPACE
    AND
    TIME

    View Slide

  41. ALLOWS FOR LOCATION TRANSPARENCY
    ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
    CORE 㱺 SOCKET 㱺 CPU 㱺
    CONTAINER 㱺 SERVER 㱺 RACK 㱺
    DATA CENTER 㱺 SYSTEM

    View Slide

  42. SELF-HEALING THROUGH BULKHEADING

    View Slide

  43. SELF-HEALING THROUGH SUPERVISION

    View Slide

  44. MICROSERVICES
    COME AS SYSTEMS

    View Slide

  45. EACH MICROSERVICE
    NEEDS BE DESIGNED AS
    A DISTRIBUTED SYSTEM
    A MICROSYSTEM

    View Slide

  46. WE NEED TO MOVE
    FROM MICROLITHS
    TO MICROSYSTEMS

    View Slide

  47. SEPARATE THE
    STATELESS BEHAVIOR
    FROM THE
    STATEFUL ENTITY
    TO SCALE THEM INDIVIDUALLY

    View Slide

  48. SCALING (STATELESS) BEHAVIOR
    IS EASY

    View Slide

  49. SCALING (STATEFUL) ENTITIES
    IS HARD

    View Slide

  50. THERE IS NO SUCH THING AS A
    "STATELESS" ARCHITECTURE
    IT'S JUST SOMEONE ELSE'S PROBLEM

    View Slide

  51. REACTIVE
    MICROSYSTEM

    View Slide

  52. PRACTICE
    EVENT-BASED
    PERSISTENCE

    View Slide

  53. Update-in-place strikes systems
    designers as a cardinal sin:
    it violates traditional accounting
    practices that have been observed
    for hundreds of years.
    — Jim Gray

    View Slide

  54. The truth is the log.
    The database is a cache of a
    subset of the log.
    — Pat Helland

    View Slide

  55. EVENT LOGGING
    FOR SCALABLE PERSISTENCE

    View Slide

  56. CRUD
    IS DEAD

    View Slide

  57. EVENT SOURCING
    A CURE FOR THE CARDINAL SIN

    View Slide

  58. Modeling events forces you to
    have a temporal focus on what’s
    going on in the system.
    Time becomes a crucial factor of
    the system.
    — Greg Young

    View Slide

  59. THE LOG
    IS A DATABASE OF THE PAST
    NOT JUST A DATABASE OF THE PRESENT

    View Slide

  60. EVENT LOGGING AVOIDS THE INFAMOUS
    OBJECT-RELATIONAL
    IMPEDENCE MISMATCH

    View Slide

  61. UNTANGLE THE
    READ & WRITE
    MODELS WITH
    CQRS

    View Slide

  62. ADVANTAGES OF USING CQRS:
    1. RESILIENCE
    2. SCALABILITY
    3. POLYGLOT
    PERSISTENCE

    View Slide

  63. USE
    EVENT SOURCING
    AND
    EVENT STREAMING

    View Slide

  64. HOW CAN WE
    COORDINATE WORK
    ACROSS AGGREGATES?

    View Slide

  65. EVENT-DRIVEN
    WORKFLOW

    View Slide

  66. BUT WHAT ABOUT
    TRANSACTIONS?

    View Slide

  67. Two-phase commit is the
    anti-availability protocol.
    — Pat Helland

    View Slide

  68. In general,
    application developers
    simply do not implement
    large scalable
    applications
    assuming distributed
    transactions.
    — Pat Helland

    View Slide

  69. USE A PROTOCOL OF
    GUESS.
    APOLOGIZE.
    COMPENSATE.

    View Slide

  70. IT'S HOW THE
    WORLD WORKS

    View Slide

  71. USE SAGAS
    NOT DISTRIBUTED TRANSACTIONS

    View Slide

  72. View Slide

  73. IN SUMMARY
    1. Don't build Microliths
    2. Microservices come in (distributed) systems
    3. Microservices come as (micro)systems
    4. Embrace the Reactive principles
    5. Embrace Event-first DDD & Persistence
    6. Profit!

    View Slide

  74. TRY THE
    LAGOM
    MICROSERVICES FRAMEWORK
    POWERED BY AKKA & PLAY
    LAGOMFRAMEWORK.COM

    View Slide

  75. LEARN MORE
    DOWNLOAD MY BOOK FOR FREE AT:
    BIT.LY/REACTIVE-MICROSYSTEMS

    View Slide