Extracting services from a monolith

Extracting services from a monolith

My talk from the SoundCloud Meetup

Ee64bbdcdeffabc6d4166a96e6d2a0d5?s=128

Jano González

October 04, 2017
Tweet

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