Reactive Microsystems: The Evolution of Microservices at Scale

E0b5787d1a1935a2800e0bbffc81c196?s=47 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.

E0b5787d1a1935a2800e0bbffc81c196?s=128

Jonas Bonér

October 03, 2017
Tweet

Transcript

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

    @JBONER
  2. WE HAVE BEEN SPOILED BY THE ALMIGHTY MONOLITH

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

  4. None
  5. WE CAN'T MAKE THE HORSE FASTER

  6. WE NEED CARS FOR WHERE WE ARE GOING

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

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

  9. ARCHITECTURAL CONTEXT OF MICROSERVICES: DISTRIBUTED SYSTEMS

  10. TODAY'S JOURNEY

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

  12. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS

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

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

    Carl Hewitt
  15. MICROSERVICES COME IN SYSTEMS

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

    EVENT-BASED PERSISTENCE
  17. PRACTICE EVENTS-FIRST DOMAIN-DRIVEN DESIGN

  18. DON'T FOCUS ON THE THINGS the nouns the domain objects

    FOCUS ON WHAT HAPPENS the verbs the events
  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
  20. LET THE EVENTS DEFINE THE BOUNDED CONTEXT

  21. EVENTS REPRESENT FACTS

  22. To condense fact from the vapor of nuance — Neal

    Stephenson, Snow Crash
  23. WHAT ARE THE FACTS?

  24. TRY OUT EVENT STORMING

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

    THE SYSTEM
  26. THINK IN TERMS OF CONSISTENCY BOUNDARIES

  27. WE NEED TO CONTAIN MUTABLE STATE & PUBLISH FACTS

  28. AGGREGATE 㱺 UNIT OF CONSISTENCY 㱺 UNIT OF FAILURE

  29. PRACTICE REACTIVE DESIGN

  30. REACTIVE PROGRAMMING VS REACTIVE SYSTEMS

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

    PERFORMANT & EFFICIENT
  32. GO ASYNCHRONOUS

  33. ASYNCHRONOUS & NON-BLOCKING - MORE EFFICIENT USE OF RESOURCES -

    MINIMIZES CONTENTION ON SHARED RESOURCES
  34. ALWAYS APPLY BACKPRESSURE A FAST SYSTEM SHOULD NOT OVERLOAD A

    SLOW SYSTEM
  35. BACKPRESSURE

  36. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS

  37. WE'RE GETTING THERE, BUT WE STILL HAVE A SINGLE INSTANCE

    MICROSERVICE 㱺 NOT SCALABLE 㱺 NOT RESILIENT
  38. REACTIVE SYSTEMS CAN HELP US BUILD DISTRIBUTED SYSTEMS THAT ARE

    ELASTIC & RESILIENT
  39. REACTIVE SYSTEMS ARE BASED ON ASYNCHRONOUS MESSAGE-PASSING

  40. ALLOWS DECOUPLING IN SPACE AND TIME

  41. ALLOWS FOR LOCATION TRANSPARENCY ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS

    OF SCALE CORE 㱺 SOCKET 㱺 CPU 㱺 CONTAINER 㱺 SERVER 㱺 RACK 㱺 DATA CENTER 㱺 SYSTEM
  42. SELF-HEALING THROUGH BULKHEADING

  43. SELF-HEALING THROUGH SUPERVISION

  44. MICROSERVICES COME AS SYSTEMS

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

    MICROSYSTEM
  46. WE NEED TO MOVE FROM MICROLITHS TO MICROSYSTEMS

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

    THEM INDIVIDUALLY
  48. SCALING (STATELESS) BEHAVIOR IS EASY

  49. SCALING (STATEFUL) ENTITIES IS HARD

  50. THERE IS NO SUCH THING AS A "STATELESS" ARCHITECTURE IT'S

    JUST SOMEONE ELSE'S PROBLEM
  51. REACTIVE MICROSYSTEM

  52. PRACTICE EVENT-BASED PERSISTENCE

  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
  54. The truth is the log. The database is a cache

    of a subset of the log. — Pat Helland
  55. EVENT LOGGING FOR SCALABLE PERSISTENCE

  56. CRUD IS DEAD

  57. EVENT SOURCING A CURE FOR THE CARDINAL SIN

  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
  59. THE LOG IS A DATABASE OF THE PAST NOT JUST

    A DATABASE OF THE PRESENT
  60. EVENT LOGGING AVOIDS THE INFAMOUS OBJECT-RELATIONAL IMPEDENCE MISMATCH

  61. UNTANGLE THE READ & WRITE MODELS WITH CQRS

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

    PERSISTENCE
  63. USE EVENT SOURCING AND EVENT STREAMING

  64. HOW CAN WE COORDINATE WORK ACROSS AGGREGATES?

  65. EVENT-DRIVEN WORKFLOW

  66. BUT WHAT ABOUT TRANSACTIONS?

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

  68. In general, application developers simply do not implement large scalable

    applications assuming distributed transactions. — Pat Helland
  69. USE A PROTOCOL OF GUESS. APOLOGIZE. COMPENSATE.

  70. IT'S HOW THE WORLD WORKS

  71. USE SAGAS NOT DISTRIBUTED TRANSACTIONS

  72. None
  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!
  74. TRY THE LAGOM MICROSERVICES FRAMEWORK POWERED BY AKKA & PLAY

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