Extracting services from a monolith

My talk from the SoundCloud Meetup

Transcript

1. Extracting services from a monolith @janogonzalez - October 2017
2. Monoliths
3. $ rails new soundcloud Monoliths How SoundCloud started
4. Monoliths All functionality in the same place User Track Like
5. Monoliths Usually layered Backend DB UI
6. Monoliths More likely to have teams per technology
7. Monoliths We had problems as the team started to grow
8. Monoliths Our delivery was too slow
9. Microservices
10. Microservices Bounded contexts User Track Like
11. Microservices Domain model fits in your head Like Track Likes Count User Likes Count
12. Microservices Each bounded context belongs to a service Likes Service
13. Microservices More likely to have cross-functional teams
14. Microservices Faster delivery
15. The requisites
16. The requisites Easily allocate computing resources
17. The requisites Monitoring
18. The requisites Continuous delivery
19. The problems
20. The problems Cascading failures
21. • Circuit breakers • Failure accrual The problems Cascading failures
22. The problems Eventual consistency (A: a1,a2; B: b1) (A;B) (A;C) (A: a1, a2) (B: b1, b2)
23. • Define authoritative sources • Compose at the edge • Use lifecycle events when necessary The problems Eventual consistency
24. The problems Too many stacks
25. • Standardize RPC and async mechanisms • Provide support levels for different tech stacks The problems Too many stacks
26. The problems Protecting against API changes
27. • Tolerant readers • Consumer driven contracts The problems Protecting against API changes
28. The problems Increased chattiness
29. • API Gateway • BFF The problems Increased chattiness
30. Our architecture
31. Our architecture High level overview
32. Our architecture Layers
33. Extracting services
34. Identify a candidate Does this feature need many changes? Is this feature causing technical risk? Choose an integration approach How to integrate the extracted service? Choose a migration strategy for data How to move the data to its own storage? Extracting services The process 1 2 3
35. Identify a candidate Does this feature need many changes? Is this feature causing technical risk? Choose an integration approach How to integrate the extracted service? Choose a migration strategy for data How to move the data to its own storage? Extracting services The process 1 2 3
36. Choose an integration approach Monolith as gateway BEFO R E Monolith
37. Choose an integration approach Monolith as gateway Monolith Service Service AFTER
38. Introduce a service layer for the feature If you don’t have it already Add an alternate path under a feature flag Beware that in-memory joins than may be needed Switch the traffic Now the code can be cleaned up Monolith as a gateway The process 2.1 2.2 2.3
39. def index likes = user_likes_service.public_track_likes( @user, pagination) respond collection_for(likes) end Monolith as a gateway Introduce a service layer for the feature
40. Introduce a service layer for the feature If you don’t have it already Add an alternate path under a feature flag Beware that in-memory joins than may be needed Switch the traffic Now the code can be cleaned up Monolith as a gateway The process 2.1 2.2 2.3
41. def public_track_likes(user, pagination) if $feature.active?(:use_likes_service, user) … else … end end Monolith as a gateway Add an alternate path under a feature flag
42. Introduce a service layer for the feature If you don’t have it already Add an alternate path under a feature flag Beware that in-memory joins than may be needed Switch the traffic Now the code can be cleaned up Monolith as a gateway The process 2.1 2.2 2.3
43. Choose an integration approach Strangler Monolith BEFO R E
44. Choose an integration approach Strangler Strangler STR AN G LIN G Monolith
45. Choose an integration approach Strangler Strangler Service Monolith AFTER
46. Choose an integration approach Strangler Strangler Service Service SO M E D AY... Service Service
47. Introduce handlers for the paths This allows for intervention Add an alternate path under a feature flag This may imply invoking not only the new service Switch the traffic Now the code can be cleaned up Strangler The process 2.1 2.2 2.3
48. def index handle(request) end Strangler Introduce handlers for the paths
49. Introduce handlers for the paths This allows for intervention Add an alternate path under a feature flag This may imply invoking not only the new service Switch the traffic Now the code can be cleaned up Strangler The process 2.1 2.2 2.3
50. def index if $feature.active?(:use_likes_service, @current_user) … else handle(request) end end Strangler Add an alternate path under a feature flag
51. Introduce handlers for the paths This allows for intervention Add an alternate path under a feature flag This may imply invoking not only the new service Switch the traffic Now the code can be cleaned up Strangler The process 2.1 2.2 2.3
52. Identify a candidate Does this feature need many changes? Is this feature causing technical risk? Choose an integration approach How to integrate the extracted service? Choose a migration strategy for data How to move the data to its own storage? Extracting services The process 1 2 3
53. Choose a migration strategy for data New schema Monolith BEFO R E
54. Choose a migration strategy for data New schema Monolith M IG R ATIO N A Service B
55. Choose a migration strategy for data New schema AFTER Monolith A Service B
56. • Allows changing the storage engine • Adds risk to the migration project • I haven’t used it personally, more suitable for services extracted for feature changes. Choose a migration strategy for data New schema
57. Choose a migration strategy for data Same schema Monolith BEFO R E
58. Choose a migration strategy for data Same schema Monolith M IG R ATIO N A Service A’
59. Choose a migration strategy for data Same schema AFTER Monolith A Service A’
60. • Low risk migration • We usually move the reads slowly and then do a quick write path cut-over • We’ve chosen this approach for services extracted due to technical risk Choose a migration strategy for data Same schema
61. • Systems that were reading directly from the DB • How to cut-over writes • Migrating events from the monolith to the service • Outages Extracting services Some details I omitted
62. Conclusions
63. Small focused teams Delivering features faster Conclusions Reasons to migrate
64. Fast provisioning Monitoring Deployment pipeline Conclusions Requisites for migrating (Fowler)
65. More moving parts Conclusions The problem you introduce
66. One feature at a time When you need it Don’t stop delivering! Conclusions How to break your monolith
67. It’s all about trade-offs! Conclusions Should you do it?
68. Thanks
69. Q & A