際際滷

際際滷Share a Scribd company logo

Split my monolith - Workshop

M
martinsson

際際滷s for the Split my monolith workshop. How to split a monolith without sharing the database. Whether you want to split into micro services or simply modularise your monolith into a "modular monolith" this worksop gives you some guidance.

1 of 49
Download to read offline
Split my monolith The workshop Photo : wikimedia
@florentpellet LyonTechHub @clem_bouillier @johan_alps
Split?
System resilience / Team scalability
Manage complexity
How? We all have seen failed modularisations. Our hypothesis is that it's often about the database https://twitter.com/mathiasverraes/status/711168935798902785?lang=en
Why is a shared DB bad? - Is it a clear interface? - Where is the code that writes to / read from a column? - Independent deployment? - Can we evolve the DB schema?
Micro-services ?
Availability 99.999% uptime ? Ex 99%^20 = 81%
Our Domain for today
Train management - Train routing: - Specify itinerary between two stations - Specify train topologies - Schedule train => a train makes the same trip every day - Booking: - Allows our customers to book a train - Tra鍖c info: - Track train on a trip - Detect delay - Invoicing: - Generate invoices and credits notes
Database schema
Exercice 1: Identify contexts in data model
Split database
Ideal split of Trip table
Example: Table Trip
Exercise: Split the Booking table
Which domain depends on which data? T: Tra鍖c info B: Booking R: Train routing I: Invoicing T,B,R B,R T,B,R T,B,R T,R,I T,R,I T,R,I T,I T T T,R,I T,B,I I I B, I B, R, I B, I T, B, R, I T, B, R, I B T, B, R, I T,B T, B, R, I B, I B, I B, I B, R, I T, B, I B, I B, I
How?
Bubble context
Autonomous bubble - synchronous
Autonomous bubble - state stream
Autonomous bubble - events
Autonomous bubble - notif. stream
Exposing legacy assets as services
Exercices
Scenario 1 Today is the day! Everything is 鍖ooded! Panic on board! Lots of late trains, we need an immediate solution. Deadline: Yesterday
Scenario 1 Many technical problems occur regularly in recent days Deadline: Yesterday We want to quickly set up a dashboard indicating in "real time" the number of people impacted. We cannot a鍖ord to re-deploy the legacy Expected : - Schema with modules, DB, API, messages, models (use the legend) - Messages frequency / data refresh rate - Make explicit any isolation - Detail data for each post-its
Scenario 1 - solution
Scenario 2 The storm is over. The dashboard made it a lot easier to prioritize various incidents. We'll need a solid architecture to build upon. Deadline: Not de鍖ned
Scenario 2 Expected : - Schema with modules, DB, API, messages, models (use the legend) - Messages frequency / data refresh rate - Make explicit any isolation - Detail data for each post-its The dashboard made it a lot easier to prioritize various incidents. We'll need a solid architecture to build upon. How would you do that given enough time? Deadline: Not de鍖ned
Scenario 2 - a solution
Scenario 2 - data Expected : - Which data is duplicated - Where does it come from - Who is the Writer Reader Many technical problems occur regularly in recent days Try another representation based on data model.
Scenario 2 - data, new point of view
Scenario 2 - data - solution
Scenario 3 We have a new nonon o鍖er (nogo train). Improve business opportunity, but success is not guaranteed. Need to test without impact legacy and reuse maximum functionality to reduce costs. Deadline: Month
Scenario 3 We have a new nonon o鍖er (nogo train). How to integrate this o鍖er with the current system? - New commercial o鍖er with a brand new UI : other reduction cards, options to buy (wi鍖) - Tra鍖c info, Train routing, Invoicing remain in the legacy - Seat assignment remain in the legacy (to 鍖ll booking table) - New module allows to book nonon train, and to cancel (new UI) - A train is either completely nonon or legacy o鍖er Expected (context and data) : - Schema with modules, DB, API, messages, models (use the legend) - Messages frequency / data refresh rate - Make explicit any isolation - Which data is duplicated - Where does it come from
Scenario 3 - solution
Scenario 3 - solution
Final Notes
In-process sync event (method call)
Strangler 鍖g pattern
Strangler 鍖g pattern paulhammant.com
Eventual Consistency is key Most things can be decoupled if we allow a delay in consistency (1s, 1min, ) Ex : The csv exports CALM theorem - State will ALWAYS be consistent if we don't delete information Counter examples: - Set di鍖erence - Multiple processes doing increment
Database change with minimal interruption 1st deploy: Add the new table/database 2nd deploy: 鍖ll the new table with values. Check 3rd deploy: New code writing to the new table (but not reading). Possibly a migration script 4th deploy: New code or feature 鍖ip, to read from the new table 5th deploy: remove old columns/table and old code. (Possibly days later) Mont辿e de version sans interruption (Nelson Dionisi)
Questions
Bibliographie Getting started with DDD when surrounded by legacy systems De Eric Evans Monolith to Microservices De Sam Newman
La passion d'apprendre formation.hackyourjob.com
Thank you !

More Related Content

Split my monolith - Workshop

  • 1. Split my monolith The workshop Photo : wikimedia
  • 4. System resilience / Team scalability
  • 6. How? We all have seen failed modularisations. Our hypothesis is that it's often about the database https://twitter.com/mathiasverraes/status/711168935798902785?lang=en
  • 7. Why is a shared DB bad? - Is it a clear interface? - Where is the code that writes to / read from a column? - Independent deployment? - Can we evolve the DB schema?
  • 11. Train management - Train routing: - Specify itinerary between two stations - Specify train topologies - Schedule train => a train makes the same trip every day - Booking: - Allows our customers to book a train - Tra鍖c info: - Track train on a trip - Detect delay - Invoicing: - Generate invoices and credits notes
  • 15. Ideal split of Trip table
  • 17. Exercise: Split the Booking table
  • 18. Which domain depends on which data? T: Tra鍖c info B: Booking R: Train routing I: Invoicing T,B,R B,R T,B,R T,B,R T,R,I T,R,I T,R,I T,I T T T,R,I T,B,I I I B, I B, R, I B, I T, B, R, I T, B, R, I B T, B, R, I T,B T, B, R, I B, I B, I B, I B, R, I T, B, I B, I B, I
  • 19. How?
  • 21. Autonomous bubble - synchronous
  • 22. Autonomous bubble - state stream
  • 24. Autonomous bubble - notif. stream
  • 25. Exposing legacy assets as services
  • 27. Scenario 1 Today is the day! Everything is 鍖ooded! Panic on board! Lots of late trains, we need an immediate solution. Deadline: Yesterday
  • 28. Scenario 1 Many technical problems occur regularly in recent days Deadline: Yesterday We want to quickly set up a dashboard indicating in "real time" the number of people impacted. We cannot a鍖ord to re-deploy the legacy Expected : - Schema with modules, DB, API, messages, models (use the legend) - Messages frequency / data refresh rate - Make explicit any isolation - Detail data for each post-its
  • 29. Scenario 1 - solution
  • 30. Scenario 2 The storm is over. The dashboard made it a lot easier to prioritize various incidents. We'll need a solid architecture to build upon. Deadline: Not de鍖ned
  • 31. Scenario 2 Expected : - Schema with modules, DB, API, messages, models (use the legend) - Messages frequency / data refresh rate - Make explicit any isolation - Detail data for each post-its The dashboard made it a lot easier to prioritize various incidents. We'll need a solid architecture to build upon. How would you do that given enough time? Deadline: Not de鍖ned
  • 32. Scenario 2 - a solution
  • 33. Scenario 2 - data Expected : - Which data is duplicated - Where does it come from - Who is the Writer Reader Many technical problems occur regularly in recent days Try another representation based on data model.
  • 34. Scenario 2 - data, new point of view
  • 35. Scenario 2 - data - solution
  • 36. Scenario 3 We have a new nonon o鍖er (nogo train). Improve business opportunity, but success is not guaranteed. Need to test without impact legacy and reuse maximum functionality to reduce costs. Deadline: Month
  • 37. Scenario 3 We have a new nonon o鍖er (nogo train). How to integrate this o鍖er with the current system? - New commercial o鍖er with a brand new UI : other reduction cards, options to buy (wi鍖) - Tra鍖c info, Train routing, Invoicing remain in the legacy - Seat assignment remain in the legacy (to 鍖ll booking table) - New module allows to book nonon train, and to cancel (new UI) - A train is either completely nonon or legacy o鍖er Expected (context and data) : - Schema with modules, DB, API, messages, models (use the legend) - Messages frequency / data refresh rate - Make explicit any isolation - Which data is duplicated - Where does it come from
  • 38. Scenario 3 - solution
  • 39. Scenario 3 - solution
  • 41. In-process sync event (method call)
  • 44. Eventual Consistency is key Most things can be decoupled if we allow a delay in consistency (1s, 1min, ) Ex : The csv exports CALM theorem - State will ALWAYS be consistent if we don't delete information Counter examples: - Set di鍖erence - Multiple processes doing increment
  • 45. Database change with minimal interruption 1st deploy: Add the new table/database 2nd deploy: 鍖ll the new table with values. Check 3rd deploy: New code writing to the new table (but not reading). Possibly a migration script 4th deploy: New code or feature 鍖ip, to read from the new table 5th deploy: remove old columns/table and old code. (Possibly days later) Mont辿e de version sans interruption (Nelson Dionisi)
  • 47. Bibliographie Getting started with DDD when surrounded by legacy systems De Eric Evans Monolith to Microservices De Sam Newman