$30 off During Our Annual Pro Sale. View Details »

Microservices vs The distributed monolith

carnage
October 29, 2016

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.

carnage

October 29, 2016
Tweet

More Decks by carnage

Other Decks in Programming

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