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

Microservices vs The distributed monolith

D5a2aef3c745cca287ddef1948157fd3?s=47 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.

D5a2aef3c745cca287ddef1948157fd3?s=128

carnage

October 29, 2016
Tweet

Transcript

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

    1
  2. Introduction

  3. Monolith vs Microservices 2

  4. Key features of a monolith architecture • A monolith is

    a single app combining multiple business functions. 3
  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
  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
  7. Key features of a microservice architecture • A microservice should

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

    have one responsibility. • Each microservice should be independent. 4
  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
  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
  11. Advantages of microservices • Improved modularisation of code 5

  12. Advantages of microservices • Improved modularisation of code • Allows

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

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

    diverse technology stacks • Independent deployment and scaling • Smaller code base 5
  15. Disadvantages of microservices • Availability 6

  16. Disadvantages of microservices • Availability • Knowledge siloing 6

  17. Disadvantages of microservices • Availability • Knowledge siloing • Testing

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

    of whole system is complex • Orchestration of system is harder 6
  19. The Distributed Monolith

  20. Don’t panic 6

  21. The common library

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

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

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

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

    • The common library becomes huge. • The common library becomes unstable. • Discourages technological diversity. 7
  26. What is the solution? • Small focused libraries 8

  27. What is the solution? • Small focused libraries • Only

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

    include what is required • Composer can help you 8
  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
  30. Interdependent deployments

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

  32. What makes this so bad? • Live demo! • Each

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

    simultaneous deployment increases risk • What about rollbacks? 9
  34. What is the solution? • API versioning 10

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

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

    • Automation 10
  37. Temporal coupling

  38. Booking a ticket 11

  39. Booking a ticket 11

  40. Booking a ticket 11

  41. Booking a ticket 11

  42. Booking a ticket 11

  43. Booking a ticket 11

  44. Booking a ticket 11

  45. Booking a ticket 11

  46. Booking a ticket 11

  47. What makes this so bad? • Performance 12

  48. What makes this so bad? • Performance • Services must

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

    wait for a response • What happens when something fails? 12
  50. Distributed transactions are HARD! 12

  51. Summing up

  52. Decoupling microservices • Avoid “nanoservices” 13

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

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

    Communicate asynchronously 13
  55. Event driven architecture

  56. A familiar model 14

  57. Event sourcing example 15

  58. Event driven architecture 16

  59. Projections • Turn events into read models 17

  60. Projections • Turn events into read models • Need to

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

    be able to recover after downtime • Can be rebuilt 17
  62. Process managers • Handle business logic around events 18

  63. Process managers • Handle business logic around events • A

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

    state machine • Be careful with replays 18
  65. Event replays 19

  66. Event replays 20

  67. Advantages of event driven architecture • Decouples microservices 21

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

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

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

    well • Easier to change • No distributed transactions 21
  71. Conclusions

  72. Every architectural decision involves tradeoffs 21

  73. Start big 21

  74. Favour autonomy over the single responsibility principal 21

  75. Embrace eventual consistency 21

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