Microservices vs The distributed monolith

When faced with a challenging legacy code base, tightly coupled and void of discernible structure: a big ball of mud, it is common to decide to refactor this monolith to a microservice architecture to separate concerns and split the codebase up, however without any clear boundaries you are in danger of creating a distributed big ball of mud.

You may recognise the symptoms of a distributed ball of mud: a large unfocused 'common' library shared between multiple services; performance issues as your front end makes calls to multiple back end API's to serve a single request; dependency hell on deployments as you have to release multiple code bases simultaneously and uptime issues as a single microservice going down brings down your entire application.

In this talk I'm going to cover some of the common pitfalls you might encounter when building a microservice architecture and show you how to use an event driven architecture to build truly scalable microservices.

Transcript

1. Microservices vs The distributed monolith
   Christopher Riley
   PHP Scotland 2016
   1
   

   View Slide

2. Introduction
   

   View Slide

3. Monolith vs Microservices
   2
   

   View Slide

4. Key features of a monolith architecture
   • A monolith is a single app combining multiple business
   functions.
   3
   

   View Slide

5. Key features of a monolith architecture
   • A monolith is a single app combining multiple business
   functions.
   • A monolith is deployed and scaled as a whole.
   3
   

   View Slide

6. Key features of a monolith architecture
   • A monolith is a single app combining multiple business
   functions.
   • A monolith is deployed and scaled as a whole.
   • A monolith is developed on a single technology stack.
   3
   

   View Slide

7. Key features of a microservice architecture
   • A microservice should have one responsibility.
   4
   

   View Slide

8. Key features of a microservice architecture
   • A microservice should have one responsibility.
   • Each microservice should be independent.
   4
   

   View Slide

9. Key features of a microservice architecture
   • A microservice should have one responsibility.
   • Each microservice should be independent.
   • A microservice should have a defined API.
   4
   

   View Slide

10. Key features of a microservice architecture
    • A microservice should have one responsibility.
    • Each microservice should be independent.
    • A microservice should have a defined API.
    • Smart endpoints, dumb pipes
    4
    

    View Slide

11. Advantages of microservices
    • Improved modularisation of code
    5
    

    View Slide

12. Advantages of microservices
    • Improved modularisation of code
    • Allows diverse technology stacks
    5
    

    View Slide

13. Advantages of microservices
    • Improved modularisation of code
    • Allows diverse technology stacks
    • Independent deployment and scaling
    5
    

    View Slide

14. Advantages of microservices
    • Improved modularisation of code
    • Allows diverse technology stacks
    • Independent deployment and scaling
    • Smaller code base
    5
    

    View Slide

15. Disadvantages of microservices
    • Availability
    6
    

    View Slide

16. Disadvantages of microservices
    • Availability
    • Knowledge siloing
    6
    

    View Slide

17. Disadvantages of microservices
    • Availability
    • Knowledge siloing
    • Testing of whole system is complex
    6
    

    View Slide

18. Disadvantages of microservices
    • Availability
    • Knowledge siloing
    • Testing of whole system is complex
    • Orchestration of system is harder
    6
    

    View Slide

19. The Distributed Monolith
    

    View Slide

20. Don’t panic
    6
    

    View Slide

21. The common library
    

    View Slide

22. What makes this so bad?
    • Microservices loose their independence.
    7
    

    View Slide

23. What makes this so bad?
    • Microservices loose their independence.
    • The common library becomes huge.
    7
    

    View Slide

24. What makes this so bad?
    • Microservices loose their independence.
    • The common library becomes huge.
    • The common library becomes unstable.
    7
    

    View Slide

25. What makes this so bad?
    • Microservices loose their independence.
    • The common library becomes huge.
    • The common library becomes unstable.
    • Discourages technological diversity.
    7
    

    View Slide

26. What is the solution?
    • Small focused libraries
    8
    

    View Slide

27. What is the solution?
    • Small focused libraries
    • Only include what is required
    8
    

    View Slide

28. What is the solution?
    • Small focused libraries
    • Only include what is required
    • Composer can help you
    8
    

    View Slide

29. What is the solution?
    • Small focused libraries
    • Only include what is required
    • Composer can help you
    • Sometimes you just have to copy + paste
    8
    

    View Slide

30. Interdependent deployments
    

    View Slide

31. What makes this so bad?
    • Live demo!
    9
    

    View Slide

32. What makes this so bad?
    • Live demo!
    • Each simultaneous deployment increases risk
    9
    

    View Slide

33. What makes this so bad?
    • Live demo!
    • Each simultaneous deployment increases risk
    • What about rollbacks?
    9
    

    View Slide

34. What is the solution?
    • API versioning
    10
    

    View Slide

35. What is the solution?
    • API versioning
    • Feature flags
    10
    

    View Slide

36. What is the solution?
    • API versioning
    • Feature flags
    • Automation
    10
    

    View Slide

37. Temporal coupling
    

    View Slide

38. Booking a ticket
    11
    

    View Slide

39. Booking a ticket
    11
    

    View Slide

40. Booking a ticket
    11
    

    View Slide

41. Booking a ticket
    11
    

    View Slide

42. Booking a ticket
    11
    

    View Slide

43. Booking a ticket
    11
    

    View Slide

44. Booking a ticket
    11
    

    View Slide

45. Booking a ticket
    11
    

    View Slide

46. Booking a ticket
    11
    

    View Slide

47. What makes this so bad?
    • Performance
    12
    

    View Slide

48. What makes this so bad?
    • Performance
    • Services must wait for a response
    12
    

    View Slide

49. What makes this so bad?
    • Performance
    • Services must wait for a response
    • What happens when something fails?
    12
    

    View Slide

50. Distributed transactions are HARD!
    12
    

    View Slide

51. Summing up
    

    View Slide

52. Decoupling microservices
    • Avoid “nanoservices”
    13
    

    View Slide

53. Decoupling microservices
    • Avoid “nanoservices”
    • Define clear boundaries
    13
    

    View Slide

54. Decoupling microservices
    • Avoid “nanoservices”
    • Define clear boundaries
    • Communicate asynchronously
    13
    

    View Slide

55. Event driven architecture
    

    View Slide

56. A familiar model
    14
    

    View Slide

57. Event sourcing example
    15
    

    View Slide

58. Event driven architecture
    16
    

    View Slide

59. Projections
    • Turn events into read models
    17
    

    View Slide

60. Projections
    • Turn events into read models
    • Need to be able to recover after downtime
    17
    

    View Slide

61. Projections
    • Turn events into read models
    • Need to be able to recover after downtime
    • Can be rebuilt
    17
    

    View Slide

62. Process managers
    • Handle business logic around events
    18
    

    View Slide

63. Process managers
    • Handle business logic around events
    • A state machine
    18
    

    View Slide

64. Process managers
    • Handle business logic around events
    • A state machine
    • Be careful with replays
    18
    

    View Slide

65. Event replays
    19
    

    View Slide

66. Event replays
    20
    

    View Slide

67. Advantages of event driven architecture
    • Decouples microservices
    21
    

    View Slide

68. Advantages of event driven architecture
    • Decouples microservices
    • Scales well
    21
    

    View Slide

69. Advantages of event driven architecture
    • Decouples microservices
    • Scales well
    • Easier to change
    21
    

    View Slide

70. Advantages of event driven architecture
    • Decouples microservices
    • Scales well
    • Easier to change
    • No distributed transactions
    21
    

    View Slide

71. Conclusions
    

    View Slide

72. Every architectural decision involves tradeoffs
    21
    

    View Slide

73. Start big
    21
    

    View Slide

74. Favour autonomy over the single responsibility
    principal
    21
    

    View Slide

75. Embrace eventual consistency
    21
    

    View Slide

76. Thanks
    • @giveupalready
    • https://github.com/carnage
    • https://carnage.github.io
    • http://joind.in/talk/d65df
    22
    

    View Slide