From Microliths To Microsystems

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 we will explore microservices from first principles, distilling their essence and putting them in their true context: distributed systems.

What many people forget is that microservices are distributed and collaborative by nature and only make sense as systems—one collaborator is no collaborator. It is in between the microservices that the most interesting and rewarding, and also challenging, problems arise—enter the world of distributed systems.

Distributed systems are by definition complex, and we system developers have been spoiled by centralized servers for too long to easily understand what this really means. 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 just think about systems of microservices. In order to make each microservice resilient and elastic in and of itself, we have to design each individual microservice as a distributed system—a «microsystem»—architected from the ground up using the reactive principles.

Transcript

1. FROM MICROLITHS TO MICROSYSTEMS JONAS BONÉR @JBONER LIGHTBEND
2. WE HAVE BEEN SPOILED BY THE ALMIGHTY MONOLITH
3. KNOCK, KNOCK. WHO’S THERE? REALITY
4. WE CAN'T MAKE THE HORSE FASTER
5. WE NEED CARS FOR WHERE WE ARE GOING
6. BUT DON'T JUST DRINK THE THINK FOR YOURSELF
7. NO ONE WANTS MICROSERVICES IT'S A NECCESSARY EVIL
8. ARCHITECTURAL CONTEXT OF MICROSERVICES: DISTRIBUTED SYSTEMS
9. LET'S SAY THAT WE WANT TO SLICE THIS MONOLITH UP
10. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS
11. MICROLITH: SINGLE INSTANCE MICROSERVICE -NOT RESILIENT -NOT ELASTIC
12. One actor is no actor. Actors come in systems. — Carl Hewitt
13. MICROSERVICES COME IN SYSTEMS
14. AS SOON AS WE EXIT THE SERVICE WE ENTER A WILD OCEAN OF NON-DETERMINISM THE WORLD OF DISTRIBUTED SYSTEMS
15. SYSTEMS NEED TO EXPLOIT REALITY
16. INFORMATION HAS LATENCY
17. The contents of a message are always from the past! They are never “now.” — Pat Helland
18. WE ARE ALWAYS LOOKING INTO THE PAST
19. THE COST OF MAINTAINING THE ILLUSION OF AN ABSOLUTE NOW
20. AS LATENCY GETS HIGHER, THE ILLUSION CRACKS EVEN MORE
21. In a distributed system, you can know where the work is done or you can know when the work is done but you can’t know both — Pat Helland
22. STRIVE TO MINIMIZE COUPLING & COMMUNICATION
23. Words are very unnecessary. They can only do harm. Enjoy the silence. — Enjoy the Silence by Martin Gore (Depeche Mode)
24. Silence is not only golden, it is seldom misquoted. — Bob Monkhouse
25. WE HAVE TO RELY ON EVENTUAL CONSISTENCY BUT RELAX IT'S HOW THE WORLD WORKS
26. NO ONE WANTS EVENTUAL CONSISTENCY. IT'S A NECESSARY EVIL. IT'S NOT COOL. IT'S USEFUL.
27. THREE HELPFUL TOOLS 1. EVENTS-FIRST DDD 2. REACTIVE DESIGN 3. EVENT-BASED PERSISTENCE
28. PRACTICE EVENTS-FIRST DOMAIN-DRIVEN DESIGN
29. DON'T FOCUS ON THE THINGS—THE NOUNS FOCUS ON WHAT HAPPENS—THE EVENTS
30. LET THE EVENTS DEFINE THE BOUNDED CONTEXT
31. EVENTS REPRESENT FACTS
32. To condense fact from the vapor of nuance — Neal Stephenson, Snow Crash
33. WHAT ARE THE FACTS?
34. TRY OUT EVENT STORMING
35. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED HOW FACTS FLOW IN THE SYSTEM
36. THINK IN TERMS OF CONSISTENCY BOUNDARIES
37. INSIDE DATA: OUR CURRENT PRESENT (STATE) OUTSIDE DATA: BLAST FROM THE PAST (FACTS) BETWEEN SERVICES: HOPE FOR THE FUTURE (COMMANDS) — PAT HELLAND, DATA ON THE INSIDE VS DATA ON THE OUTSIDE
38. AGGREGATE 㱺 UNIT OF CONSISTENCY 㱺 UNIT OF FAILURE
39. WE NEED TO CONTAIN MUTABLE STATE & PUBLISH FACTS
40. PRACTICE REACTIVE DESIGN
41. REACTIVE PROGRAMMING VS REACTIVE SYSTEMS
42. REACTIVE PROGRAMMING CAN HELP US MAKE THE INDIVIDUAL INSTANCE HIGHLY PERFORMANT & EFFICIENT
43. GO ASYNCHRONOUS
44. ASYNCHRONOUS & NON-BLOCKING - MORE EFFICIENT USE OF RESOURCES - MINIMIZES CONTENTION ON SHARED RESOURCES
45. ALWAYS APPLY BACK-PRESSURE A FAST SYSTEM SHOULD NOT OVERLOAD A SLOW SYSTEM
46. WE NEED TO EXTEND OUR MODELS OF COMMUNICATION 1. ASYNCHRONOUS MESSAGING (N-M) 2. STREAMING (1-1) 3. SYNCHRONOUS REQUEST/REPLY (1-1)
47. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS
48. WE'RE GETTING THERE, BUT WE STILL HAVE A SINGLE INSTANCE MICROSERVICE 㱺 NOT SCALABLE 㱺 NOT RESILIENT
49. MICROSERVICES COME AS SYSTEMS
50. EACH MICROSERVICE NEEDS BE DESIGNED AS A DISTRIBUTED SYSTEM A MICROSYSTEM
51. WE NEED TO MOVE FROM MICROLITHS TO MICROSYSTEMS
52. REACTIVE SYSTEMS CAN HELP US BUILD DISTRIBUTED SYSTEMS THAT ARE ELASTIC & RESILIENT
53. REACTIVE SYSTEMS ARE BASED ON ASYNCHRONOUS MESSAGE-PASSING
54. ALLOWS DECOUPLING IN SPACE AND TIME
55. ALLOWS FOR LOCATION TRANSPARENCY ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE CORE 㱺 SOCKET 㱺 CPU 㱺 CONTAINER 㱺 SERVER 㱺 RACK 㱺 DATA CENTER 㱺 SYSTEM
56. But I'll take my time anywhere. I'm free to speak my mind anywhere. And I'll redefine anywhere. Anywhere I roam. Where I lay my head is home. — Wherever I May Roam by Lars Ulrich, James Hetfield (Metallica)
57. SEPARATE THE STATELESS BEHAVIOR FROM THE STATEFUL ENTITY TO SCALE THEM INDIVIDUALLY
59. SCALING (STATELESS) BEHAVIOR IS EASY
60. SCALING (STATEFUL) ENTITIES IS HARD
61. THERE IS NO SUCH THING AS A "STATELESS" ARCHITECTURE IT'S JUST SOMEONE ELSE'S PROBLEM
63. PRACTICE EVENT-BASED PERSISTENCE
64. The truth is the log. The database is a cache of a subset of the log. — Pat Helland
65. CRUD IS DEAD
66. FAVOR EVENT LOGGING
67. THE LOG IS A DATABASE OF THE PAST NOT JUST A DATABASE OF THE PRESENT
68. EVENT LOGGING AVOIDS THE INFAMOUS OBJECT-RELATIONAL IMPEDENCE MISMATCH
69. UNTANGLE THE READ & WRITE MODELS WITH CQRS & EVENT SOURCING
71. BUT WHAT ABOUT TRANSACTIONS?
72. In general, application developers simply do not implement large scalable applications assuming distributed transactions. — Pat Helland
73. USE A PROTOCOL OF GUESS. APOLOGIZE. COMPENSATE.
74. IT'S HOW THE WORLD WORKS
75. 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!
76. TRY THE LAGOM MICROSERVICES FRAMEWORK POWERED BY AKKA & PLAY LAGOMFRAMEWORK.COM
77. LEARN MORE DOWNLOAD MY BOOK FOR FREE AT: BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE
78. THANK YOU