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
   

   View Slide

2. WE HAVE BEEN SPOILED BY
   THE ALMIGHTY
   MONOLITH
   

   View Slide

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

   View Slide

4. WE CAN'T MAKE THE HORSE FASTER
   

   View Slide

5. WE NEED CARS FOR WHERE WE ARE GOING
   

   View Slide

6. BUT DON'T JUST DRINK THE
   THINK FOR YOURSELF
   

   View Slide

7. NO ONE WANTS
   MICROSERVICES
   IT'S A NECCESSARY EVIL
   

   View Slide

8. ARCHITECTURAL CONTEXT OF MICROSERVICES:
   DISTRIBUTED SYSTEMS
   

   View Slide

9. LET'S SAY THAT WE WANT TO
   SLICE THIS MONOLITH UP
   

   View Slide

10. TOO MANY END UP WITH AN ARCHITECTURE LIKE THIS
    

    View Slide

11. MICROLITH:
    SINGLE INSTANCE
    MICROSERVICE
    -NOT RESILIENT
    -NOT ELASTIC
    

    View Slide

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

    View Slide

13. MICROSERVICES
    COME IN SYSTEMS
    

    View Slide

14. AS SOON AS WE
    EXIT THE SERVICE
    WE ENTER A WILD OCEAN OF
    NON-DETERMINISM
    THE WORLD OF
    DISTRIBUTED SYSTEMS
    

    View Slide

15. SYSTEMS NEED TO
    EXPLOIT REALITY
    

    View Slide

16. INFORMATION HAS
    LATENCY
    

    View Slide

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

    View Slide

18. WE ARE ALWAYS LOOKING INTO THE PAST
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

22. STRIVE TO MINIMIZE
    COUPLING &
    COMMUNICATION
    

    View Slide

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

    View Slide

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

    View Slide

25. WE HAVE TO RELY ON
    EVENTUAL CONSISTENCY
    BUT RELAX
    IT'S HOW THE WORLD WORKS
    

    View Slide

26. NO ONE WANTS
    EVENTUAL CONSISTENCY.
    IT'S A NECESSARY EVIL.
    IT'S NOT COOL. IT'S USEFUL.
    

    View Slide

27. THREE HELPFUL TOOLS
    1. EVENTS-FIRST DDD
    2. REACTIVE DESIGN
    3. EVENT-BASED PERSISTENCE
    

    View Slide

28. PRACTICE
    EVENTS-FIRST
    DOMAIN-DRIVEN DESIGN
    

    View Slide

29. DON'T FOCUS ON THE THINGS—THE NOUNS
    FOCUS ON WHAT HAPPENS—THE EVENTS
    

    View Slide

30. LET THE
    EVENTS DEFINE
    THE BOUNDED CONTEXT
    

    View Slide

31. EVENTS REPRESENT FACTS
    

    View Slide

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

    View Slide

33. WHAT ARE THE
    FACTS?
    

    View Slide

34. TRY OUT
    EVENT STORMING
    

    View Slide

35. UNDERSTAND HOW FACTS ARE CAUSALLY RELATED
    HOW FACTS FLOW IN THE SYSTEM
    

    View Slide

36. THINK IN TERMS OF
    CONSISTENCY BOUNDARIES
    

    View Slide

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
    

    View Slide

38. AGGREGATE
    㱺 UNIT OF CONSISTENCY
    㱺 UNIT OF FAILURE
    

    View Slide

39. WE NEED TO
    CONTAIN MUTABLE STATE &
    PUBLISH FACTS
    

    View Slide

40. PRACTICE
    REACTIVE DESIGN
    

    View Slide

41. REACTIVE PROGRAMMING
    VS
    REACTIVE SYSTEMS
    

    View Slide

42. REACTIVE PROGRAMMING
    CAN HELP US MAKE THE
    INDIVIDUAL INSTANCE
    HIGHLY PERFORMANT & EFFICIENT
    

    View Slide

43. GO
    ASYNCHRONOUS
    

    View Slide

44. ASYNCHRONOUS
    & NON-BLOCKING
    - MORE EFFICIENT USE OF RESOURCES
    - MINIMIZES CONTENTION ON SHARED
    RESOURCES
    

    View Slide

45. ALWAYS APPLY BACK-PRESSURE
    A FAST SYSTEM
    SHOULD NOT OVERLOAD
    A SLOW SYSTEM
    

    View Slide

46. WE NEED TO EXTEND OUR MODELS OF
    COMMUNICATION
    1. ASYNCHRONOUS MESSAGING (N-M)
    2. STREAMING (1-1)
    3. SYNCHRONOUS REQUEST/REPLY (1-1)
    

    View Slide

47. LET'S APPLY REACTIVE PROGRAMMING TO OUR MICROLITHS
    

    View Slide

48. WE'RE GETTING THERE, BUT WE STILL HAVE A
    SINGLE INSTANCE MICROSERVICE
    㱺 NOT SCALABLE
    㱺 NOT RESILIENT
    

    View Slide

49. MICROSERVICES
    COME AS SYSTEMS
    

    View Slide

50. EACH MICROSERVICE
    NEEDS BE DESIGNED AS
    A DISTRIBUTED SYSTEM
    A MICROSYSTEM
    

    View Slide

51. WE NEED TO MOVE
    FROM MICROLITHS
    TO MICROSYSTEMS
    

    View Slide

52. REACTIVE SYSTEMS
    CAN HELP US BUILD
    DISTRIBUTED SYSTEMS THAT ARE
    ELASTIC & RESILIENT
    

    View Slide

53. REACTIVE SYSTEMS ARE BASED ON
    ASYNCHRONOUS
    MESSAGE-PASSING
    

    View Slide

54. ALLOWS DECOUPLING IN
    SPACE
    AND
    TIME
    

    View Slide

55. ALLOWS FOR LOCATION TRANSPARENCY
    ONE COMMUNICATION ABSTRACTION ACROSS ALL DIMENSIONS OF SCALE
    CORE 㱺 SOCKET 㱺 CPU 㱺
    CONTAINER 㱺 SERVER 㱺 RACK 㱺
    DATA CENTER 㱺 SYSTEM
    

    View Slide

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)
    

    View Slide

57. SEPARATE THE
    STATELESS BEHAVIOR
    FROM THE
    STATEFUL ENTITY
    TO SCALE THEM INDIVIDUALLY
    

    View Slide

58. View Slide

59. SCALING (STATELESS) BEHAVIOR
    IS EASY
    

    View Slide

60. SCALING (STATEFUL) ENTITIES
    IS HARD
    

    View Slide

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

    View Slide

62. View Slide

63. PRACTICE
    EVENT-BASED
    PERSISTENCE
    

    View Slide

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

    View Slide

65. CRUD
    IS DEAD
    

    View Slide

66. FAVOR
    EVENT LOGGING
    

    View Slide

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

    View Slide

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

    View Slide

69. UNTANGLE THE
    READ & WRITE
    MODELS WITH
    CQRS & EVENT SOURCING
    

    View Slide

70. View Slide

71. BUT WHAT ABOUT
    TRANSACTIONS?
    

    View Slide

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

    View Slide

73. USE A PROTOCOL OF
    GUESS.
    APOLOGIZE.
    COMPENSATE.
    

    View Slide

74. IT'S HOW THE
    WORLD WORKS
    

    View Slide

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!
    

    View Slide

76. TRY THE
    LAGOM
    MICROSERVICES
    FRAMEWORK
    POWERED BY AKKA & PLAY
    LAGOMFRAMEWORK.COM
    

    View Slide

77. LEARN
    MORE
    DOWNLOAD MY BOOK FOR FREE AT:
    BIT.LY/REACTIVE-MICROSERVICES-ARCHITECTURE
    

    View Slide

78. THANK
    YOU
    

    View Slide