O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Split my monolith - Workshop

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 49 Anúncio

Split my monolith - Workshop

Baixar para ler offline

Slides 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.

Slides 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.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais recentes (20)

Anúncio

Split my monolith - Workshop

  1. 1. Split my monolith The workshop Photo : wikimedia
  2. 2. @florentpellet LyonTechHub @clem_bouillier @johan_alps
  3. 3. Split?
  4. 4. System resilience / Team scalability
  5. 5. Manage complexity
  6. 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. 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?
  8. 8. Micro-services ?
  9. 9. Availability 99.999% uptime ? Ex 99%^20 = 81%
  10. 10. Our Domain for today
  11. 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 - Traffic info: - Track train on a trip - Detect delay - Invoicing: - Generate invoices and credits notes
  12. 12. Database schema
  13. 13. Exercice 1: Identify contexts in data model
  14. 14. Split database
  15. 15. Ideal split of Trip table
  16. 16. Example: Table Trip
  17. 17. Exercise: Split the Booking table
  18. 18. Which domain depends on which data? T: Traffic 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. 19. How?
  20. 20. Bubble context
  21. 21. Autonomous bubble - synchronous
  22. 22. Autonomous bubble - state stream
  23. 23. Autonomous bubble - events
  24. 24. Autonomous bubble - notif. stream
  25. 25. Exposing legacy assets as services
  26. 26. Exercices
  27. 27. Scenario 1 Today is the day! Everything is flooded! Panic on board! Lots of late trains, we need an immediate solution. Deadline: Yesterday 🚨
  28. 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 afford 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. 29. Scenario 1 - solution
  30. 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 defined ⛱
  31. 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 defined ⛱
  32. 32. Scenario 2 - a solution
  33. 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. 34. Scenario 2 - data, new point of view
  35. 35. Scenario 2 - data - solution
  36. 36. Scenario 3 We have a new “nonon” offer (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. 37. Scenario 3 We have a new “nonon” offer (nogo train). How to integrate this offer with the current system? - New commercial offer with a brand new UI : other reduction cards, options to buy (wifi…) - Traffic info, Train routing, Invoicing remain in the legacy - Seat assignment remain in the legacy (to fill booking table) - New module allows to book “nonon” train, and to cancel (new UI) - A train is either completely “nonon” or legacy offer 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. 38. Scenario 3 - solution
  39. 39. Scenario 3 - solution
  40. 40. Final Notes
  41. 41. In-process sync event (method call)
  42. 42. Strangler fig pattern
  43. 43. Strangler fig pattern paulhammant.com
  44. 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 difference - Multiple processes doing increment
  45. 45. Database change with minimal interruption 1st deploy: Add the new table/database 2nd deploy: fill 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 flip, 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)
  46. 46. Questions
  47. 47. Bibliographie Getting started with DDD when surrounded by legacy systems De Eric Evans Monolith to Microservices De Sam Newman
  48. 48. La passion d'apprendre formation.hackyourjob.com
  49. 49. Thank you !

×