Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From Microliths To Microsystems

E0b5787d1a1935a2800e0bbffc81c196?s=47 Jonas Bonér
February 08, 2017

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.

E0b5787d1a1935a2800e0bbffc81c196?s=128

Jonas Bonér

February 08, 2017
Tweet

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
  58. None
  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
  62. None
  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
  70. None
  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