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

bla bla microservices bla bla: director's cut

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.

E0b5787d1a1935a2800e0bbffc81c196?s=128

Jonas Bonér

October 04, 2016
Tweet

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
  13. None
  14. AN AUTONOMOUS SERVICE CAN ONLY PROMISE ITS OWN BEHAVIOUR

  15. None
  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
  58. None
  59. None
  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

  92. None