Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Extracting services from a monolith

Extracting services from a monolith

My talk from the SoundCloud Meetup

Jano González

October 04, 2017
Tweet

More Decks by Jano González

Other Decks in Programming

Transcript

  1. Extracting services from a monolith
    @janogonzalez - October 2017

    View Slide

  2. Monoliths

    View Slide

  3. $ rails new soundcloud
    Monoliths
    How SoundCloud started

    View Slide

  4. Monoliths
    All functionality in the same place
    User
    Track
    Like

    View Slide

  5. Monoliths
    Usually layered
    Backend
    DB
    UI

    View Slide

  6. Monoliths
    More likely to have teams per technology

    View Slide

  7. Monoliths
    We had problems as the team started to grow

    View Slide

  8. Monoliths
    Our delivery was too slow

    View Slide

  9. Microservices

    View Slide

  10. Microservices
    Bounded contexts
    User
    Track
    Like

    View Slide

  11. Microservices
    Domain model fits in your head
    Like
    Track Likes
    Count
    User Likes
    Count

    View Slide

  12. Microservices
    Each bounded context belongs to a service
    Likes Service

    View Slide

  13. Microservices
    More likely to have cross-functional teams

    View Slide

  14. Microservices
    Faster delivery

    View Slide

  15. The requisites

    View Slide

  16. The requisites
    Easily allocate computing resources

    View Slide

  17. The requisites
    Monitoring

    View Slide

  18. The requisites
    Continuous delivery

    View Slide

  19. The problems

    View Slide

  20. The problems
    Cascading failures

    View Slide

  21. ● Circuit breakers
    ● Failure accrual
    The problems
    Cascading failures

    View Slide

  22. The problems
    Eventual consistency
    (A: a1,a2;
    B: b1)
    (A;B)
    (A;C)
    (A: a1, a2) (B: b1, b2)

    View Slide

  23. ● Define authoritative sources
    ● Compose at the edge
    ● Use lifecycle events when necessary
    The problems
    Eventual consistency

    View Slide

  24. The problems
    Too many stacks

    View Slide

  25. ● Standardize RPC and async mechanisms
    ● Provide support levels for different tech stacks
    The problems
    Too many stacks

    View Slide

  26. The problems
    Protecting against API changes

    View Slide

  27. ● Tolerant readers
    ● Consumer driven contracts
    The problems
    Protecting against API changes

    View Slide

  28. The problems
    Increased chattiness

    View Slide

  29. ● API Gateway
    ● BFF
    The problems
    Increased chattiness

    View Slide

  30. Our architecture

    View Slide

  31. Our architecture
    High level overview

    View Slide

  32. Our architecture
    Layers

    View Slide

  33. Extracting services

    View Slide

  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

    View Slide

  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

    View Slide

  36. Choose an integration approach
    Monolith as gateway
    BEFO
    R
    E
    Monolith

    View Slide

  37. Choose an integration approach
    Monolith as gateway
    Monolith
    Service Service
    AFTER

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  43. Choose an integration approach
    Strangler
    Monolith
    BEFO
    R
    E

    View Slide

  44. Choose an integration approach
    Strangler
    Strangler
    STR
    AN
    G
    LIN
    G
    Monolith

    View Slide

  45. Choose an integration approach
    Strangler
    Strangler
    Service Monolith
    AFTER

    View Slide

  46. Choose an integration approach
    Strangler
    Strangler
    Service Service
    SO
    M
    E
    D
    AY...
    Service Service

    View Slide

  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

    View Slide

  48. def index
    handle(request)
    end
    Strangler
    Introduce handlers for the paths

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  53. Choose a migration strategy for data
    New schema
    Monolith
    BEFO
    R
    E

    View Slide

  54. Choose a migration strategy for data
    New schema
    Monolith
    M
    IG
    R
    ATIO
    N
    A
    Service
    B

    View Slide

  55. Choose a migration strategy for data
    New schema
    AFTER
    Monolith
    A
    Service
    B

    View Slide

  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

    View Slide

  57. Choose a migration strategy for data
    Same schema
    Monolith
    BEFO
    R
    E

    View Slide

  58. Choose a migration strategy for data
    Same schema
    Monolith
    M
    IG
    R
    ATIO
    N
    A
    Service
    A’

    View Slide

  59. Choose a migration strategy for data
    Same schema
    AFTER
    Monolith
    A
    Service
    A’

    View Slide

  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

    View Slide

  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

    View Slide

  62. Conclusions

    View Slide

  63. Small focused teams Delivering features faster
    Conclusions
    Reasons to migrate

    View Slide

  64. Fast provisioning Monitoring Deployment pipeline
    Conclusions
    Requisites for migrating (Fowler)

    View Slide

  65. More moving parts
    Conclusions
    The problem you introduce

    View Slide

  66. One feature at a time When you need it Don’t stop delivering!
    Conclusions
    How to break your monolith

    View Slide

  67. It’s all about trade-offs!
    Conclusions
    Should you do it?

    View Slide

  68. Thanks

    View Slide

  69. Q & A

    View Slide