Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reactive Microsystems: The Evolution of Microservices at Scale

818 views

Published on

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.

Published in: Engineering
  • Be the first to comment

Reactive Microsystems: The Evolution of Microservices at Scale

  1. 1. REACTIVE MICROSYSTEMS THE EVOLUTION OF MICROSERVICES AT SCALE JONAS BONÉR @JBONER
  2. 2. WE HAVE BEEN SPOILED BY THE ALMIGHTY MONOLITH
  3. 3. KNOCK, KNOCK. WHO’S THERE? REALITY
  4. 4. WE CAN'T MAKE THE HORSE FASTER
  5. 5. WE NEED CARS FOR WHERE WE ARE GOING
  6. 6. BUT DON'T JUST DRINK THE THINK FOR YOURSELF
  7. 7. NO ONE WANTS MICROSERVICES IT'S A NECCESSARY EVIL
  8. 8. ARCHITECTURAL CONTEXT OF MICROSERVICES: DISTRIBUTED SYSTEMS
  9. 9. TODAY'S JOURNEY
  10. 10. LET'S SAY THAT WE WANT TO SLICE THIS MONOLITH UP
  11. 11. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS
  12. 12. MICROLITH: SINGLE INSTANCE MICROSERVICE -NOT RESILIENT -NOT ELASTIC
  13. 13. One actor is no actor. Actors come in systems. — Carl Hewitt
  14. 14. MICROSERVICES COME IN SYSTEMS
  15. 15. 3 HELPFUL TOOLS 1. EVENTS-FIRST DDD 2. REACTIVE DESIGN 3. EVENT-BASED PERSISTENCE
  16. 16. PRACTICE EVENTS-FIRST DOMAIN-DRIVEN DESIGN
  17. 17. DON'T FOCUS ON THE THINGS the nouns the domain objects FOCUS ON WHAT HAPPENS the verbs the events
  18. 18. 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
  19. 19. LET THE EVENTS DEFINE THE BOUNDED CONTEXT
  20. 20. EVENTS REPRESENT FACTS
  21. 21. To condense fact from the vapor of nuance — Neal Stephenson, Snow Crash
  22. 22. WHAT ARE THE FACTS?
  23. 23. TRY OUT EVENT STORMING
  24. 24. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED HOW FACTS FLOW IN THE SYSTEM
  25. 25. THINK IN TERMS OF CONSISTENCY BOUNDARIES
  26. 26. WE NEED TO CONTAIN MUTABLE STATE & PUBLISH FACTS
  27. 27. AGGREGATEUNIT OF CONSISTENCY UNIT OF FAILURE
  28. 28. PRACTICE REACTIVE DESIGN
  29. 29. REACTIVE PROGRAMMING VS REACTIVE SYSTEMS
  30. 30. REACTIVE PROGRAMMING CAN HELP US MAKE THE INDIVIDUAL INSTANCE HIGHLY PERFORMANT & EFFICIENT
  31. 31. GOASYNCHRONOUS
  32. 32. ASYNCHRONOUS & NON-BLOCKING - MORE EFFICIENT USE OF RESOURCES - MINIMIZES CONTENTION ON SHARED RESOURCES
  33. 33. ALWAYS APPLY BACKPRESSURE A FAST SYSTEM SHOULD NOT OVERLOAD A SLOW SYSTEM
  34. 34. BACKPRESSURE
  35. 35. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS
  36. 36. WE'RE GETTING THERE, BUT WE STILL HAVE A SINGLE INSTANCE MICROSERVICE NOT SCALABLE NOT RESILIENT
  37. 37. REACTIVE SYSTEMS CAN HELP US BUILD DISTRIBUTED SYSTEMS THAT ARE ELASTIC & RESILIENT
  38. 38. REACTIVE SYSTEMS ARE BASED ON ASYNCHRONOUS MESSAGE-PASSING
  39. 39. ALLOWS DECOUPLING IN SPACEAND TIME
  40. 40. ALLOWS FOR LOCATION TRANSPARENCY ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE CORE SOCKET CPU CONTAINER SERVER RACK DATA CENTER SYSTEM
  41. 41. SELF-HEALING THROUGH BULKHEADING
  42. 42. SELF-HEALING THROUGH SUPERVISION
  43. 43. MICROSERVICES COME AS SYSTEMS
  44. 44. EACH MICROSERVICENEEDS BE DESIGNED AS A DISTRIBUTED SYSTEM A MICROSYSTEM
  45. 45. WE NEED TO MOVE FROM MICROLITHS TO MICROSYSTEMS
  46. 46. SEPARATE THE STATELESS BEHAVIOR FROM THE STATEFUL ENTITY TO SCALE THEM INDIVIDUALLY
  47. 47. SCALING (STATELESS) BEHAVIOR IS EASY
  48. 48. SCALING (STATEFUL) ENTITIES IS HARD
  49. 49. THERE IS NO SUCH THING AS A "STATELESS" ARCHITECTURE IT'S JUST SOMEONE ELSE'S PROBLEM
  50. 50. REACTIVE MICROSYSTEM
  51. 51. PRACTICE EVENT-BASED PERSISTENCE
  52. 52. 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
  53. 53. The truth is the log. The database is a cache of a subset of the log. — Pat Helland
  54. 54. EVENT LOGGINGFOR SCALABLE PERSISTENCE
  55. 55. CRUD IS DEAD
  56. 56. EVENT SOURCING A CURE FOR THE CARDINAL SIN
  57. 57. 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
  58. 58. THE LOGIS A DATABASE OF THE PAST NOT JUST A DATABASE OF THE PRESENT
  59. 59. EVENT LOGGING AVOIDS THE INFAMOUS OBJECT-RELATIONAL IMPEDENCE MISMATCH
  60. 60. UNTANGLE THE READ & WRITEMODELS WITH CQRS
  61. 61. ADVANTAGES OF USING CQRS: 1. RESILIENCE 2. SCALABILITY 3. POLYGLOT PERSISTENCE
  62. 62. USE EVENT SOURCING AND EVENT STREAMING
  63. 63. HOW CAN WE COORDINATE WORK ACROSS AGGREGATES?
  64. 64. EVENT-DRIVEN WORKFLOW
  65. 65. BUT WHAT ABOUT TRANSACTIONS?
  66. 66. Two-phase commit is the anti-availability protocol. — Pat Helland
  67. 67. In general, application developers simply do not implement large scalable applications assuming distributed transactions. — Pat Helland
  68. 68. USE A PROTOCOL OF GUESS. APOLOGIZE. COMPENSATE.
  69. 69. IT'S HOW THE WORLD WORKS
  70. 70. USE SAGASNOT DISTRIBUTED TRANSACTIONS
  71. 71. 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!
  72. 72. TRY THE LAGOMMICROSERVICES FRAMEWORK POWERED BY AKKA & PLAY LAGOMFRAMEWORK.COM
  73. 73. LEARN MOREDOWNLOAD MY BOOK FOR FREE AT: BIT.LY/REACTIVE-MICROSYSTEMS

×