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.

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