Recommended
More Related Content
Similar to Getting out of the monolith hell
Similar to Getting out of the monolith hell (20)
More from mimmozzo_
Recently uploaded
Recently uploaded (20)
Getting out of the monolith hell
- 1. Getting out of the monolith hell Domenico Musto
- 2. Domenico Musto ▪ Principal Engineer at Spektrix ▪ Distributed systems ▪ REST ▪ Messaging ▪ Automation testing ▪ Continuous delivery domenico.musto@gmail.com @mimmozzo
- 4. Monolithic architecture is great
- 5. Monolithic architecture ▪ Is easy to understand
- 6. Monolithic architecture ▪ Is easy to understand ▪ A single code base
- 7. Monolithic architecture ▪ Is easy to understand ▪ A single code base ▪ No integration issues
- 8. Monolithic architecture ▪ Is easy to understand ▪ A single code base ▪ No integration issues ▪ A single deployment pipeline
- 14. ▪ The code base gets too large and difficult to work with
- 15. ▪ The code base gets too large and difficult to work with ▪ The IDE is overloaded
- 16. ▪ The code base gets too large and difficult to work with ▪ The IDE is overloaded ▪ Continuous delivery is difficult
- 17. SOFTWARE DEVELOPMENT CYCLE BUILD TEST RELEASE
- 18. SOFTWARE DEVELOPMENT CYCLE BUILD TEST RELEASE SOFTWARE
- 19. SOFTWARE DEVELOPMENT CYCLE BUILD TEST RELEASE SOFTWARE
- 20. SOFTWARE DEVELOPMENT CYCLE BUILD TEST RELEASE SOFTWARE
- 21. SOFTWARE DEVELOPMENT CYCLE BUILD TEST RELEASE
- 22. ▪ The code base gets too large and difficult to work with ▪ The IDE is overloaded ▪ Continuous delivery is difficult ▪ The system is difficult to scale
- 23. ▪ The code base gets too large and difficult to work with ▪ The IDE is overloaded ▪ Continuous delivery is difficult ▪ The system is difficult to scale ▪ Scaling the dev team is difficult
- 24. ▪ The code base gets too large and difficult to work with ▪ The IDE is overloaded ▪ Continuous delivery is difficult ▪ The system is difficult to scale ▪ Scaling the dev team is difficult ▪ Hard to adopt new technologies
- 25. ▪ The code base gets too large and difficult to work with ▪ The IDE is overloaded ▪ Continuous delivery is difficult ▪ The system is difficult to scale ▪ Scaling the dev team is difficult ▪ Hard to adopt new technologies The monolith hell
- 26. Distributed system ▪ Speed up delivery by reducing development friction ▪ Scale the system ▪ Scale the development team ▪ Increase the uptime of your application
- 27. Agenda ▪ Business capabilities ▪ Components ▪ Integration patterns ▪ From monolith to distributed ▪ Pitfalls
- 29. Identify business capabilities ▪ Things that the business / product can do
- 30. Identify business capabilities ▪ Things that the business / product can do ▪ Shared domain space and language
- 31. Identify business capabilities ▪ Things that the business / product can do ▪ Shared domain space and language ▪ A team could be built around
- 32. Identify business capabilities ▪ Things that the business / product can do ▪ Shared domain space and language ▪ A team could be built around ▪ Micro products
- 35. Components
- 36. Orders Component A Component B Component C Users Component A Component B Component C
- 38. Components ▪ Autonomous ▪ Explicit boundaries Ian Cooper
- 39. Components ▪ Autonomous ▪ Explicit boundaries ▪ Bounded context Ian Cooper
- 40. Components ▪ Autonomous ▪ Explicit boundaries ▪ Bounded context ▪ Decentralized governance Ian Cooper
- 41. Components ▪ Autonomous ▪ Explicit boundaries ▪ Bounded context ▪ Decentralized governance ▪ Distributable Ian Cooper
- 43. Orders - Understands and owns orders data - Drives orders workflows Users - Understands and owns users data - Drives users workflows
- 45. HTTP
- 48. HTTP goodness ▪ Easy ▪ Synchronous
- 49. HTTP goodness ▪ Easy ▪ Synchronous ▪ Caching
- 50. HTTP weakness ▪ Reduces service autonomy
- 53. HTTP weakness ▪ Reduces service autonomy ▪ RPC temptation
- 54. HTTP weakness ▪ Reduces service autonomy ▪ RPC temptation ▪ Versioning
- 55. Messaging
- 58. Reference data UserCreated { Id: 1, Username: “domenico”, Email: “domenico.musto@gmail.com”, Twitter: “@mimmozzo”, Version: 1 } USERS MESSAGE BROKER
- 59. Reference data MESSAGE BROKER ORDERS Recipient Id : int Email : string Version: int
- 60. Type of messages ▪ Events ▪ Document messages ▪ Commands
- 61. Event ▪ Informs the outside world that something has happened
- 62. Event ▪ Informs the outside world that something has happened ▪ Past sequence
- 63. Event ▪ Informs the outside world that something has happened ▪ Past sequence ▪ Unique ID
- 64. Event UserDeleted { Id: 100, UserId: 200 }
- 65. Document Message UserCreated { Id: 100, Name: ‘Domenico’, LastName: ‘Musto’, Email: ‘domenico.musto@gmail.com’, Twitter: ‘@mimmozzo’ }
- 66. Command ▪ A demand to do something
- 67. Command ▪ A demand to do something ▪ Imperative sentence
- 68. Command SendEmail{ Id: 100, To: ‘domenico.musto@gmail.com’, From: ‘info@myecommerce.com’, Subject: ‘Welcome’, Content: ‘Enjoy’ }
- 69. Operating events
- 70. Operating events ▪ Eventual consistency ▪ Compensation ▪ Idempotence
- 71. Operating events – eventual consistency Recipient Id : 100 Email : email@gmail.com Version: 1 Orders
- 72. Operating events – eventual consistency Recipient Id : 100 Email : email@gmail.com Version: 1 OrdersUserEmailUpdated { Id: 100, Email: “new@gmail.com”, Version: 1 }
- 73. Operating events – eventual consistency Recipient Id : 100 Email : new@gmail.com Version: 2 OrdersUserEmailUpdated { Id: 100, Email: “new@gmail.com”, Version: 1 }
- 74. Operating events – compensation
- 75. Operating events – compensation USERS USERS EVENTS USERS EVENT PUBLISHER MESSAGE BROKER
- 76. Operating events – idempotence
- 77. Operating events – idempotence Recipient Id : 100 Email : email@gmail.com Version: 1 OrdersUserEmailUpdated { Id: 100, Email: “new@gmail.com”, Version: 3 }
- 78. Operating events – idempotence Recipient Id : 100 Email : new@gmail.com Version: 3 OrdersUserEmailUpdated { Id: 100, Email: “old@gmail.com”, Version: 2 }
- 80. Messaging goodness ▪ Decoupling ▪ Service autonomy
- 81. Messaging goodness ▪ Decoupling ▪ Service autonomy ▪ Versioning
- 83. Messaging weakness ▪ Async ▪ Eventual consistency
- 84. Messaging weakness ▪ Async ▪ Eventual consistency ▪ Enforce idempotency
- 85. HTTP or Messaging ? ▪ Async VS Sync
- 86. HTTP or Messaging ? ▪ Async VS Sync ▪ Cross BCs integration ?
- 87. From Monolith to Distributed
- 93. MONOLITH MONOLITH DB SERVICE EVENTS SERVICE DB AND CATAGLO DATA
- 94. MONOLITH MONOLITH DB SERVICE EVENTS SERVICE DB AND CATAGLO DATA
- 95. Pitfalls
- 97. Pitfalls ▪ Nano services ▪ Too many services to perform a business workflow
- 98. Pitfalls ▪ Nano services ▪ Too many services to perform a business workflow ▪ Fragmented logic
- 99. Pitfalls ▪ Nano services ▪ Too many services to perform a business workflow ▪ Fragmented logic ▪ Management and cost overhead
- 100. Distributed system ▪ Speed up delivery by reducing development friction ▪ Scale the system ▪ Scale the development team ▪ Increase the uptime of your application