Microservices: Improving the autonomy of our teams with Event-Driven Architecture #cas2018
•
1 like•875 views
- Microservices: Improving the autonomy of our teams with Event-Driven Architecture discusses migrating from a monolithic architecture to microservices and event-driven architecture. - It explores how this impacts development team autonomy and scalability. It also analyzes a migration plan from monolith to service-based architecture. - The document outlines stages including starting with a monolith, then moving to microliths which improved codebase scaling but led to infrastructure scaling issues. It describes how event-driven architecture can further decouple services.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Microservices: Improving the autonomy of our teams with Event-Driven Architecture #cas2018
Similar to Microservices: Improving the autonomy of our teams with Event-Driven Architecture #cas2018 (20)
Recently uploaded
Recently uploaded (20)
Microservices: Improving the autonomy of our teams with Event-Driven Architecture #cas2018
- 1. Microservices: Improving the autonomy of our teams with Event-Driven Architecture Rafa Gómez & Javier Ferrer CodelyTV
- 2. THE MONOLITH DB USERS DB VIDEOS Stage 2 Microliths GET USERS DB VIDEOS DB Stage 2.1 Coupled Microliths USERS DB VIDEOS DB video_created e Stage 3 EDA Stage 1 Monolith
- 3. Goals 🧠 Explore the implications of an Event-Driven Architecture in terms of: 👥 Development teams management and autonomy 🚀 Scalability 🗺 Analyze a migration plan from a monolith to a service based architecture Intro
- 5. User story
- 7. 🗿 Stage 1: The Monolith Problem: The Domino Effect
- 8. Stage 1: The Monolith THE MONOLITH GET /users/x PUT /videos/x DB { "id": “some-uuid", "name": “Codelyber", "total_videos_created": 1 } 🧠
- 9. & 🙋 THE MONOLITH 🧠 Stage 1: The Monolith GET /users/x PUT /videos/x GET /courses/x GET /paths/x GET /videos/x/comments GET /videos/x/likes 💩 💩 💩💩 💩💩 💩 💩 💩 ☀☀ ☀☀ 💩 💩 💩💩💩💩 💩 💩 💩 💩 💩 💩 💩 💩 DB 💧
- 10. THE MONOLITH 🧠 Stage 1: The Monolith GET /users/x PUT /videos/x GET /courses/x GET /paths/x GET /videos/x/comments GET /videos/x/likes 💩 💩 💩💩 💩💩 💩 💩 💩 ☀☀ ☀☀ 💩 💩 💩💩💩💩 💩 💩 💩 💩 💩 💩 💩 💩 DB x1000 🔥
- 11. Recap Stage 1: The Monolith 👥 Development teams management and autonomy 👎 Same codebase 🚀 Scalability 👎 Development scaling issues 👎 Application scaling issues 👎 Infrastructure scaling issues Stage 1: The Monolith
- 12. HATERS
- 13. Haters advisory 🎯 Assume we’ve actual needs to implement a [micro]services architecture: . Multiple development teams 🌈 Different needs that require different programming languages 📊 Different scaling needs for each service Stage 1: The Monolith
- 14. 🗿 Stage 2: The Microliths 🗿 Problem: Domino Effect
- 15. Stage 1: The Monolith THE MONOLITH GET /users/x PUT /videos/x DB
- 16. USERS GET /users/x PUT /videos/x VIDEOS Stage 2: The Microliths DB
- 17. USERS GET /users/x PUT /videos/x VIDEOS Stage 2: The Microliths DB 🧠 💩 💩💩 💩💩 💩 💩 ☀ ☀ ☀ ☀ 💩 💩 💩 💩💩💩 💩 🧠 💩 💩 💩 💩💩 💩 💩☀ ☀ ☀ 💩 💩💩 💩☀ ☀☀ ☀ 👀 👀
- 18. USERS GET /users/x PUT /videos/x VIDEOS Stage 2: The Microliths DB 🧠 💩 💩💩 💩💩 💩 💩 ☀ ☀ ☀ ☀ 💩 💩 💩 💩💩💩 💩 🧠 💩 💩 💩 💩💩 💩 💩☀ ☀ ☀ 💩 💩💩 💩 👀 👀 ☀ ☀☀ ☀ ☀☀ ☀ ☀☀ ☀ ☀☀ ☀☀ ☀☀☀☀ ☀
- 19. USERS GET /users/x PUT /videos/x VIDEOS Stage 2: The Microliths DB 🧠 💩 💩💩 💩💩 💩 💩 ☀ ☀ ☀ ☀ 💩 💩 💩 💩💩💩 💩 🧠 💩 💩 💩 💩💩 💩 💩☀ ☀ ☀ 💩 💩💩 💩 👀 👀 ☀ ☀☀ ☀ ☀☀ ☀ ☀☀ ☀ ☀☀ ☀☀ ☀☀☀☀ ☀ x1000😰 🔥 AKA Distributed Monolith 🐘
- 21. Changelog Stage 2: The Microliths 👥 Development teams management and autonomy 👍 Solved code base scaling issues 👎 Teams sharing the same DB schema ✋ Isolated DBA team: obfuscate priorities 🚀 Scalability 👍 Slightly better development scaling 👍 No application scaling issues 👎 Infrastructure scaling issues Stage 2: The Microliths
- 22. 🗿🗿 Stage 2.1: Coupled Microliths Problem: Domino Effect
- 23. USERS GET /users/x PUT /videos/x VIDEOS Stage 2: The Microliths DB 🧠 💩 💩💩 💩💩 💩 💩 ☀ ☀ ☀ ☀ 💩 💩 💩 💩💩💩 💩 🧠 💩 💩 💩 💩💩 💩 💩☀ ☀ ☀ 💩 💩💩 💩☀ ☀☀ ☀ ☀☀ ☀ ☀☀ ☀ ☀☀ ☀☀ ☀☀☀☀ ☀
- 24. USERS DB GET /users/x PUT /videos/xVIDEOS DB Stage 2.1: Coupled Microliths 🧠 🧠
- 25. USERS DB GET /users/x PUT /videos/xVIDEOS DB 🏖 Stage 2.1: Coupled Microliths x1000🙂 🔥 { "id": “some-uuid", "name": "Codelyber", "total_videos_created": 1 } 🧠 🧠☀
- 26. USERS DB GET /users/x PUT /videos/xVIDEOS DB 🏖 Stage 2.1: Coupled Microliths x1000🙂 🔥 { "id": “some-uuid", "name": "Codelyber", "total_videos_created": 1 } 🧠 🧠☀
- 27. USERS🙂 DB GET /users/x PUT /videos/xVIDEOS DB 🏖 GET /videos ?user_id=x Stage 2.1: Coupled Microliths 🔥 x1000 AKA Distributed Monolith 🐘 🧠 🧠☀ 💩
- 29. USERS DB GET /users/x PUT /videos/xVIDEOS DB 🏖 GET /videos ?user_id=x Stage 2.1: Coupled Microliths 🔥 x1000 AKA Distributed Monolith 🐘 🧠 🧠💩☀ 😰
- 31. USERS🙂 DB GET /users/x PUT /videos/xVIDEOS DB 🏖 GET /videos?u_id=x Stage 2.1: Coupled Microliths 🔥 x1000 🧠 🧠💩☀ 🕸 { "id": “some-uuid", "name": "Codelyber", "total_videos_created": 0 }
- 38. USERS DB GET /users/x PUT /videos/xVIDEOS DB GET /videos?u_id=x Stage 2.1: Coupled Microliths 🧠 🧠💩🕸 { "id": “some-uuid", "name": "Codelyber", "total_videos_created": 0 } 👋☀
- 39. Changelog Stage 2.1: Coupled Microliths 👥 Development teams management and autonomy 👍 DB schema independence 👎 Inappropriate intimacy between teams => Use cases to develop & maintain 👎 More work to do (SQL query vs. expose & consume HTTP endpoint) 🚀 Scalability 👍 No DB scaling issues 👎 Services coupling => Communication => Latency & Domino effect Stage 2.1: Coupled Microliths
- 40. Changelog Stage 2.1: Coupled Microliths 👥 Development teams management and autonomy 👍 DB schema independence 👎 Inappropriate intimacy between teams => Use cases to develop & maintain 👎 More work to do (SQL query vs. expose & consume HTTP endpoint) 🚀 Scalability 👍 No DB scaling issues 👎 Services coupling => Communication => Latency & Domino effect Stage 2.1: Coupled Microliths
- 41. 5
- 42. 🧿 Stage 3: EDA Raising the DIP & OCP to a macro-architecture level
- 43. USERS SERVICE DB GET /users/x PUT /videos/xVIDEOS SERVICE DB GET /videos ?user_id=x Stage 2.1: Coupled Microliths AKA Distributed Monolith 🐘
- 44. I Videos ServiceUsers Service Stage 3: EDA
- 46. How do we apply this concept to our [micro]services? Do you remember… SOLID! From: I MySqlVideoRepositoryVideoCreator VideoCreator MySqlVideoRepository VideoRepository i To: D A I
- 47. From: I Videos ServiceUsers Service ??? ? To: Users Service Videos Service Stage 3: EDA
- 48. From: I Videos ServiceUsers Service video_created e To: Users Service Videos Service Stage 3: EDA
- 49. USERS DB GET /users/x PUT /videos/xVIDEOS DB Subscribed to video_created e Publishes 🧠 🧠☀ Stage 3: EDA { "id": “some-uuid", "name": "Codelyber", "total_videos_created": 1 } | DB table fields | |----------------------| | id | | name | | total_videos_created |
- 50. USERS DB GET /users/x PUT /videos/xVIDEOS DB x1000 🔥🏖 🙂 🕶 video_created e Publishes Subscribed to 🧠 🧠☀ Stage 3: EDA
- 51. Changelog Stage 3: Decoupling our teams 👥 Development teams management and autonomy 👍 Avoid inappropriate intimacy (develop & maintain use cases) 👍 OCP: Avoid having to modify current behaviour ☝ Learning curve (duplicated messages, order not guaranteed…) 🚀 Scalability 👍 No services coupling => No communication => Lower latencies & avoid domino effect 👍 Replicate data => Shape it as needed by the team use cases Stage 3: EDA
- 52. 🗺 Migration plan Microservices & Event-Driven Architecture
- 53. Base strategy = PoC: Learn & define messaging architecture (RabbitMQ Simulator) > Choose a little & not risky use case to develop in your new service ? Define your ACL: Domain events as interfaces/contracts @ Migrate historical data from the legacy system to the new one (next slides) A Start publishing events from the legacy system and consuming them from the new one (next slide) Microservices & Event-Driven Architecture
- 54. Migration plan fully based on domain events = Migrate historical data: = Legacy: Simulate the publication of events corresponding to historical data based on the DB state saving them in the event store > Copy all the events from the event store to a new queue X (history) ? New service: Consume all the events in the queue X @ Remove temporary queue X > Replicate new data changes: = Legacy: Start publishing events in the new queue Y > New service: Start consuming the events from queue Y Microservices & Event-Driven Architecture
- 55. Migration plan speeding up initial data migration = Legacy: Start publishing the needed events > Legacy: Create a DB slave not exposing it to serve public requests ? Legacy: Stop DB replication in the new slave (this define The Moment X™) @ Temporary script: Migrate historical data until The Moment X from the new slave to the new service DB making the needed transformations A New service: Start consuming the events published after The Moment X C Remove the slave & temporary script created for the historical data migration Microservices & Event-Driven Architecture
- 56. 5 9 I don’t know Rick…
- 57. ⚡ Conclusions
- 58. THE MONOLITH DB USERS DB VIDEOS Stage 2 Microliths GET USERS DB VIDEOS DB Stage 2.1 Coupled Microliths USERS DB VIDEOS DB video_created e Stage 3 EDA Stage 1 Monolith
- 59. To take away 🧿 Decouple your teams thanks to EDA 🗺 SOLID principles can be applied at micro and macro-design levels 📃 Think about your Domain Events as you Domain interfaces/contracts 🕵 Inappropriate intimacy: Services exposing information just because of other services need it. Simplify your services by limiting their APIs. 💡 Domain events as ACL. Useful while refactoring legacy systems. Conclusions
- 60. & More info?
- 61. & More info? Mini-demo time! 🎥I Demo with PHP, Scala, and RabbitMQ (Spanish 🤟): https://www.youtube.com/watch?v=1kaP39W80zQ 🐙🧣 https://github.com/CodelyTV/scala-http-api/ 🐙🐘 https://github.com/CodelyTV/cqrs-ddd-php-example
- 62. 👉codely.tv/pro/cas-18 👈!codely.tv/pro/commit-18" # 100 primeros => Primer mes a 19€ $ Tweet #commitCodelyTV => Sorteo 1 mes gratis !codely.tv/pro/commit-18" # 100 primeros => Primer mes a 19€ $ Tweet #commitCodelyTV => Sorteo 1 mes gratis
- 63. Related links Performance Under Load CodelyTV Pro Hexagonal Architecture course (Spanish) CodelyTV Pro CQRS course (Spanish) CodelyTV Pro Scala HTTP API course (Spanish) Testing CQRS talk (Spanish) We broke up with the monolith, and started dating #eventSourcing Versioning in an Event Sourced System RabbitMQ Simulator A Series of Fortunate Events The anatomy of Domain Event & More info?
- 64. Wait! Do we need [micro]services in order to apply these concepts at macro-design level?