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.

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