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
   

   View Slide

2. KNOCK, KNOCK. WHO’S THERE?
   REALITY
   

   View Slide

3. Traditional application
   architectures and
   platforms
   are obsolete.
   — Gartner
   

   View Slide

4. MICROSERVICES.
   WHAT MAKES THEM SO POPULAR?
   

   View Slide

5. ONE DEFINITION
   SUPPORTS MULTIPLE AUTONOMOUS TEAMS
   ORGANIZED TO SCALE THE DEVELOPMENT
   WHERE THE TEAMS CAN DEVELOP, DEPLOY AND MANAGE
   THEIR SERVICES INDEPENDENTLY
   

   View Slide

6. THE ARCHITECTURAL CONTEXT OF MICROSERVICES:
   DISTRIBUTED SYSTEMS
   

   View Slide

7. ANOTHER DEFINITION
   A SYSTEM OF
   AUTONOMOUS
   COLLABORATIVE
   DISTRIBUTED
   SERVICES
   

   View Slide

8. AUTONOMY
   FROM GREEK AUTO-NOMOS:
   AUTO MEANING SELF
   NOMOS MEANING LAW
   

   View Slide

9. PROMISE THEORY
   LEADS THE WAY
   

   View Slide

10. THINK IN PROMISES
    NOT COMMANDS
    

    View Slide

11. Autonomy makes information local,
    leading to greater certainty
    and stability
    —IN SEARCH FOR CERTAINTY BY MARK BURGESS
    

    View Slide

12. > Commands diverge into unpredictable outcomes from
    definite beginnings ˰ decreased certainty
    > Promises converge towards a definite outcome from
    unpredictable beginnings ˰ improved certainty
    

    View Slide

13. View Slide

14. AN AUTONOMOUS SERVICE
    CAN ONLY PROMISE
    ITS OWN BEHAVIOUR
    

    View Slide

15. View Slide

16. IT WILL SLICE UP YOUR
    1. ORGANIZATION
    2. ARCHITECTURE
    

    View Slide

17. Organizations which
    design systems
    ...are constrained to
    produce designs which
    are copies of the
    communication
    structures of these
    organizations.
    — Melvin Conway
    

    View Slide

18. USE BULKHEADING
    

    View Slide

19. BUT
    WHAT ABOUT THE
    TITANIC?
    

    View Slide

20. RESILIENCE
    IS THE ABILITY TO SELF-HEAL, WHICH REQUIRES
    COMPARTMENTALIZATION OF FAILURE
    

    View Slide

21. GO
    ASYNCHRONOUS
    

    View Slide

22. ASYNC IO
    —IS ABOUT NOT BLOCKING THREADS
    ASYNC COMMUNICATION
    —IS ABOUT NOT BLOCKING REQUESTS
    

    View Slide

23. ASYNCHRONOUS
    IO
    

    View Slide

24. SYNCHRONOUS DISPATCH
    

    View Slide

25. ASYNCHRONOUS DISPATCH
    

    View Slide

26. ASYNCHRONOUS
    COMMUNICATION
    

    View Slide

27. ASYNC COMMUNICATION ALLOWS DECOUPLING IN
    SPACE
    AND
    TIME
    

    View Slide

28. ASYCHRONOUS MESSAGE-PASSING
    EMBRACES THE CONSTRAINTS OF
    DISTRIBUTED SYSTEMS
    

    View Slide

29. MESSAGE-PASSING ALLOWS FOR LOCATION TRANSPARENCY
    ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
    CORE ˰ SOCKET ˰
    CPU ˰ CONTAINER ˰
    SERVER ˰ RACK ˰
    DATA CENTER ˰ SYSTEM
    

    View Slide

30. MICROWHAT?
    

    View Slide

31. The Unix philosophy:
    Write programs that do
    one thing & do it well.
    Write programs to
    work together.
    — Doug McIlroy
    

    View Slide

32. DO ONE THING
    AND
    DO IT WELL
    

    View Slide

33. BUT WHAT ABOUT
    STATE?
    

    View Slide

34. OWN YOUR STATE, EXCLUSIVELY
    

    View Slide

35. THERE IS NO SUCH THING AS A
    "STATELESS" ARCHITECTURE
    IT'S JUST SOMEONE ELSE'S PROBLEM
    

    View Slide

36. THINK IN TERMS OF
    CONSISTENCY BOUNDARIES
    

    View Slide

37. BOUNDED
    CONTEXTS
    

    View Slide

38. POLYGLOT
    PERSISTENCE
    

    View Slide

39. The truth is the log.
    The database is a cache
    of a subset of the log.
    — Pat Helland
    

    View Slide

40. FAVOR
    EVENT LOGGING
    

    View Slide

41. THE LOG
    IS A DATABASE OF THE PAST
    NOT JUST A DATABASE OF THE PRESENT
    

    View Slide

42. EVENT SOURCING
    WITH CQRS
    

    View Slide

43. EVENT LOGGING AVOIDS THE INFAMOUS
    OBJECT-RELATIONAL
    IMPEDENCE MISMATCH
    

    View Slide

44. YOU NEED TO SEPARATE
    THE STATELESS PART — THE BEHAVIOR
    FROM
    THE STATEFUL PART — THE KNOWLEDGE
    

    View Slide

45. STAY MOBILE
    BUT ADDRESSABLE
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

48. REFERENCES SHOULD ALWAYS WORK
    

    View Slide

49. ...AND NOW WHAT?
    

    View Slide

50. One actor is no actor.
    Actors come in systems.
    — Carl Hewitt
    

    View Slide

51. MICROSERVICES
    COME IN SYSTEMS
    

    View Slide

52. SYSTEMS NEED TO
    EXPLOIT REALITY
    

    View Slide

53. INFORMATION HAS
    LATENCY
    

    View Slide

54. WE ARE ALWAYS LOOKING INTO THE PAST
    

    View Slide

55. THE COST OF MAINTAINING THE
    ILLUSION
    OF AN ABSOLUTE
    NOW
    

    View Slide

56. AS LATENCY GETS HIGHER, THE
    ILLUSION CRACKS EVEN MORE
    

    View Slide

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
    

    View Slide

58. View Slide

59. View Slide

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)
    

    View Slide

61. STRIVE TO MINIMIZE
    COUPLING &
    COMMUNICATION
    

    View Slide

62. Words are very
    unecessary.
    They can only do harm.
    Enjoy the silence.
    — Enjoy the Silence by Martin Gore
    (Depeche Mode)
    

    View Slide

63. Silence is not only
    golden, it is seldom
    misquoted.
    — Bob Monkhouse
    

    View Slide

64. The contents of
    a message are
    always from the past!
    They are never “now.”
    — Pat Helland
    

    View Slide

65. WE HAVE TO RELY ON
    EVENTUAL CONSISTENCY
    BUT DON'T BE SURPRISED
    IT'S HOW THE WORLD WORKS
    

    View Slide

66. NO ONE WANTS
    EVENTUAL CONSISTENCY
    IT IS A NECESSARY EVIL
    

    View Slide

67. THINK IN FACTS
    

    View Slide

68. CAUSALITY
    IS A PATH TO KNOWLEDGE
    

    View Slide

69. To condense fact from
    the vapor of nuance
    — Neal Stephenson, Snow Crash
    

    View Slide

70. WE NEED TO
    CONTAIN MUTABLE STATE &
    PUBLISH FACTS
    

    View Slide

71. HOW CAN WE MANAGE
    PROTOCOL EVOLUTION?
    

    View Slide

72. Be conservative
    in what you do,
    be liberal in what you
    accept from others.
    — Jon Postel
    

    View Slide

73. CONSIDER USING AN
    ANTI-CORRUPTION LAYER
    (CLASSIC DDD PATTERN)
    

    View Slide

74. CONSIDER USING AN
    API GATEWAY
    TO SIMPLIFY CLIENT COMMUNICATION
    

    View Slide

75. HOW CAN WE MANAGE
    THE COMPLEXITY OF
    COMMUNICATION?
    

    View Slide

76. INTEGRATION
    WITH OTHER SYSTEMS
    IS A RISKY BUSINESS
    

    View Slide

77. SYNCHRONOUS
    COMMUNICATION
    PUTS YOU AT THE
    MERCY
    OF THE OTHER SYSTEM
    

    View Slide

78. USE CIRCUIT BREAKERS
    

    View Slide

79. ALWAYS APPLY BACK-PRESSURE
    OR SOMEONE WILL GET HURT
    

    View Slide

80. A FAST SYSTEM
    SHOULD NOT OVERLOAD
    A SLOW SYSTEM
    

    View Slide

81. BUT
    WHAT ABOUT
    TRANSACTIONS?
    

    View Slide

82. In general,
    application developers
    simply do not implement
    large scalable
    applications
    assuming distributed
    transactions.
    — Pat Helland
    

    View Slide

83. “Two-phase commit is
    the anti-availability
    protocol.”
    — Pat Helland
    

    View Slide

84. GUESS.
    APOLOGIZE.
    COMPENSATE.
    

    View Slide

85. IT'S HOW THE
    WORLD WORKS
    

    View Slide

86. BUT... I REALLY NEED TRANSACTIONS
    

    View Slide

87. SAGA
    PATTERN
    

    View Slide

88. IN SUMMARY
    EMBRACE REALITY
    AND ITS CONSTRAINTS
    SHALL SET YOU FREE
    (OR SOMETHING LIKE THAT)
    

    View Slide

89. LEARN
    MORE
    HTTP://BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE
    

    View Slide

90. NEVER. STOP. READING.
    SOME BOOKS TO GET YOU STARTED
    

    View Slide

91. THANK
    YOU
    

    View Slide

92. View Slide