bla bla microservices bla bla: director's cut

Everyone is talking about microservices, but there is more confusion than ever about what the promise of microservices really means and how to deliver on it. In this talk we will explore microservices from first principles, distilling their essence and putting them in their true context: distributed systems.

We will start by examining individual microservices and explaining why it is important to adhere to the core traits of autonomy, isolation, single responsibility, exclusive state, asynchronicity, and mobility. But what many people forget is that microservices are collaborative by nature and only make sense as systems. It is in between the microservices that the most interesting and rewarding, but also challenging, problems arise—here we are entering the world of distributed systems.

Distributed systems are inherently complex, and we enterprise 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 you up for failure. What we need in order to build resilient, elastic, and responsive microservices-based systems is to embrace microservices as systems and re-architect them from the ground up using reactive principles.

Transcript

1. BLA BLA MICROSERVICES BLA BLA DIRECTOR'S CUT JONAS BONÉR @JBONER CTO LIGHTBEND
2. KNOCK, KNOCK. WHO’S THERE? REALITY
3. Traditional application architectures and platforms are obsolete. — Gartner
4. MICROSERVICES. WHAT MAKES THEM SO POPULAR?
5. ONE DEFINITION SUPPORTS MULTIPLE AUTONOMOUS TEAMS ORGANIZED TO SCALE THE DEVELOPMENT WHERE THE TEAMS CAN DEVELOP, DEPLOY AND MANAGE THEIR SERVICES INDEPENDENTLY
6. THE ARCHITECTURAL CONTEXT OF MICROSERVICES: DISTRIBUTED SYSTEMS
7. ANOTHER DEFINITION A SYSTEM OF AUTONOMOUS COLLABORATIVE DISTRIBUTED SERVICES
8. AUTONOMY FROM GREEK AUTO-NOMOS: AUTO MEANING SELF NOMOS MEANING LAW
9. PROMISE THEORY LEADS THE WAY
10. THINK IN PROMISES NOT COMMANDS
11. Autonomy makes information local, leading to greater certainty and stability —IN SEARCH FOR CERTAINTY BY MARK BURGESS
12. > Commands diverge into unpredictable outcomes from definite beginnings ˰ decreased certainty > Promises converge towards a definite outcome from unpredictable beginnings ˰ improved certainty
14. AN AUTONOMOUS SERVICE CAN ONLY PROMISE ITS OWN BEHAVIOUR
16. IT WILL SLICE UP YOUR 1. ORGANIZATION 2. ARCHITECTURE
17. Organizations which design systems ...are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin Conway
18. USE BULKHEADING
19. BUT WHAT ABOUT THE TITANIC?
20. RESILIENCE IS THE ABILITY TO SELF-HEAL, WHICH REQUIRES COMPARTMENTALIZATION OF FAILURE
21. GO ASYNCHRONOUS
22. ASYNC IO —IS ABOUT NOT BLOCKING THREADS ASYNC COMMUNICATION —IS ABOUT NOT BLOCKING REQUESTS
23. ASYNCHRONOUS IO
24. SYNCHRONOUS DISPATCH
25. ASYNCHRONOUS DISPATCH
26. ASYNCHRONOUS COMMUNICATION
27. ASYNC COMMUNICATION ALLOWS DECOUPLING IN SPACE AND TIME
28. ASYCHRONOUS MESSAGE-PASSING EMBRACES THE CONSTRAINTS OF DISTRIBUTED SYSTEMS
29. MESSAGE-PASSING ALLOWS FOR LOCATION TRANSPARENCY ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE CORE ˰ SOCKET ˰ CPU ˰ CONTAINER ˰ SERVER ˰ RACK ˰ DATA CENTER ˰ SYSTEM
30. MICROWHAT?
31. The Unix philosophy: Write programs that do one thing & do it well. Write programs to work together. — Doug McIlroy
32. DO ONE THING AND DO IT WELL
33. BUT WHAT ABOUT STATE?
34. OWN YOUR STATE, EXCLUSIVELY
35. THERE IS NO SUCH THING AS A "STATELESS" ARCHITECTURE IT'S JUST SOMEONE ELSE'S PROBLEM
36. THINK IN TERMS OF CONSISTENCY BOUNDARIES
37. BOUNDED CONTEXTS
38. POLYGLOT PERSISTENCE
39. The truth is the log. The database is a cache of a subset of the log. — Pat Helland
40. FAVOR EVENT LOGGING
41. THE LOG IS A DATABASE OF THE PAST NOT JUST A DATABASE OF THE PRESENT
42. EVENT SOURCING WITH CQRS
43. EVENT LOGGING AVOIDS THE INFAMOUS OBJECT-RELATIONAL IMPEDENCE MISMATCH
44. YOU NEED TO SEPARATE THE STATELESS PART — THE BEHAVIOR FROM THE STATEFUL PART — THE KNOWLEDGE
45. STAY MOBILE BUT ADDRESSABLE
46. 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)
47. WHY WOULD I NEED VIRTUAL ADRESSING? 1. Load-balancing between stateless services 2. State replication of stateful services 3. Relocation of a stateful service
48. REFERENCES SHOULD ALWAYS WORK
49. ...AND NOW WHAT?
50. One actor is no actor. Actors come in systems. — Carl Hewitt
51. MICROSERVICES COME IN SYSTEMS
52. SYSTEMS NEED TO EXPLOIT REALITY
53. INFORMATION HAS LATENCY
54. WE ARE ALWAYS LOOKING INTO THE PAST
55. THE COST OF MAINTAINING THE ILLUSION OF AN ABSOLUTE NOW
56. AS LATENCY GETS HIGHER, THE ILLUSION CRACKS EVEN MORE
57. 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
60. INSIDE DATA: OUR CURRENT PRESENT OUTSIDE DATA: BLAST FROM THE PAST BETWEEN SERVICES: HOPE FOR THE FUTURE — PAT HELLAND (DATA ON THE INSIDE VS DATA ON THE OUTSIDE)
61. STRIVE TO MINIMIZE COUPLING & COMMUNICATION
62. Words are very unecessary. They can only do harm. Enjoy the silence. — Enjoy the Silence by Martin Gore (Depeche Mode)
63. Silence is not only golden, it is seldom misquoted. — Bob Monkhouse
64. The contents of a message are always from the past! They are never “now.” — Pat Helland
65. WE HAVE TO RELY ON EVENTUAL CONSISTENCY BUT DON'T BE SURPRISED IT'S HOW THE WORLD WORKS
66. NO ONE WANTS EVENTUAL CONSISTENCY IT IS A NECESSARY EVIL
67. THINK IN FACTS
68. CAUSALITY IS A PATH TO KNOWLEDGE
69. To condense fact from the vapor of nuance — Neal Stephenson, Snow Crash
70. WE NEED TO CONTAIN MUTABLE STATE & PUBLISH FACTS
71. HOW CAN WE MANAGE PROTOCOL EVOLUTION?
72. Be conservative in what you do, be liberal in what you accept from others. — Jon Postel
73. CONSIDER USING AN ANTI-CORRUPTION LAYER (CLASSIC DDD PATTERN)
74. CONSIDER USING AN API GATEWAY TO SIMPLIFY CLIENT COMMUNICATION
75. HOW CAN WE MANAGE THE COMPLEXITY OF COMMUNICATION?
76. INTEGRATION WITH OTHER SYSTEMS IS A RISKY BUSINESS
77. SYNCHRONOUS COMMUNICATION PUTS YOU AT THE MERCY OF THE OTHER SYSTEM
78. USE CIRCUIT BREAKERS
79. ALWAYS APPLY BACK-PRESSURE OR SOMEONE WILL GET HURT
80. A FAST SYSTEM SHOULD NOT OVERLOAD A SLOW SYSTEM
81. BUT WHAT ABOUT TRANSACTIONS?
82. In general, application developers simply do not implement large scalable applications assuming distributed transactions. — Pat Helland
83. “Two-phase commit is the anti-availability protocol.” — Pat Helland
84. GUESS. APOLOGIZE. COMPENSATE.
85. IT'S HOW THE WORLD WORKS
86. BUT... I REALLY NEED TRANSACTIONS
87. SAGA PATTERN
88. IN SUMMARY EMBRACE REALITY AND ITS CONSTRAINTS SHALL SET YOU FREE (OR SOMETHING LIKE THAT)
89. LEARN MORE HTTP://BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE
90. NEVER. STOP. READING. SOME BOOKS TO GET YOU STARTED
91. THANK YOU