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

Upday Journey to Microservices

Upday Journey to Microservices

What we've learnt when we applied microservices architecture

Maciej Walkowiak

June 07, 2017
Tweet

More Decks by Maciej Walkowiak

Other Decks in Programming

Transcript

  1. JOURNEY TO MICROSERVICES
    @maciejwalkowiak

    View full-size slide

  2. what we’ve learnt when
    we applied microservices
    architecture

    View full-size slide

  3. Greetings
    Top News

    View full-size slide

  4. Greetings
    Top News
    My News

    View full-size slide

  5. STARTUP
    Source: https://giphy.com/gifs/season-3-money-unicorn-3osxYamKD88c6pXdfO

    View full-size slide

  6. People Vector created by Freepik

    View full-size slide

  7. Source: https://www.icicletech.com/blog/a-startups-guide-to-minimum-viable-product-part-1

    View full-size slide

  8. Source: https://www.icicletech.com/blog/a-startups-guide-to-minimum-viable-product-part-1

    View full-size slide

  9. SO .. WHAT’S THE PROBLEM?
    ▸ Developing new features required coordination between
    teams
    ▸ Hard to bring new feature in single sprint

    View full-size slide

  10. SO .. WHAT’S THE PROBLEM?
    ▸ Developing new features required coordination between
    teams
    ▸ Hard to bring new feature in single sprint

    View full-size slide

  11. 1. horizontal teams do
    not work well for
    incremental feature
    development

    View full-size slide

  12. CROSS FUNCTIONAL TEAMS
    Source: https://giphy.com/gifs/the-avengers-PpeGK6edBWAxi

    View full-size slide

  13. 2. Continuous delivery
    platform is a must

    View full-size slide

  14. CURRENT ARCHITECTURE

    View full-size slide

  15. CURRENT ARCHITECTURE
    Team X Team Y Team Z

    View full-size slide

  16. CURRENT ARCHITECTURE
    Team X Team Y Team Z

    View full-size slide

  17. SO .. WHAT’S THE PROBLEM?
    ▸ Adding new functionality requires changes in 2 separate
    services - sometimes doubles the work
    ▸ No clear service ownership - difficult to make architecture
    decisions - “a camel is a horse designed by a committee"
    ▸ No clear bugs ownership

    View full-size slide

  18. SO .. WHAT’S THE PROBLEM?
    ▸ Adding new functionality requires changes in 2 separate
    services - sometimes doubles the work
    ▸ No clear service ownership - difficult to make architecture
    decisions - “a camel is a horse designed by a committee"
    ▸ No clear bugs ownership

    View full-size slide

  19. 3. Horizontal
    components do not get
    along with vertical
    teams

    View full-size slide

  20. API GATEWAY
    HTTPS://GITHUB.COM/NETFLIX/ZUUL

    View full-size slide

  21. API GATEWAY - MIGRATION PHASE

    View full-size slide

  22. HAPPY DEVELOPERS!
    HAPPY MANAGERS!

    View full-size slide

  23. 1.000.000
    users

    View full-size slide

  24. 4. monitoring is
    essential

    View full-size slide

  25. SO .. WHAT’S THE PROBLEM?
    ▸ cross functional teams but many features were not
    crossing all technologies
    ▸ we ended up as two teams in a single team: android and
    backend
    ▸ teams were not oriented around business case

    View full-size slide

  26. SO .. WHAT’S THE PROBLEM?
    ▸ cross functional teams but many features were not
    crossing all technologies
    ▸ we ended up as two teams in a single team: android and
    backend
    ▸ teams were not oriented around business case

    View full-size slide

  27. CROSS FUNCTIONAL TEAMS
    CHAOS DRIVEN
    DEVELOPMENT
    Source:https://giphy.com/gifs/four-rooms-allison-anders-alexandre-rockwell-XTYq2BBOwwSUo

    View full-size slide

  28. SO .. WHAT’S THE PROBLEM?
    ▸ degrading quality
    ▸ no feeling of responsibility for production issues
    ▸ increasing overall system complexity

    View full-size slide

  29. SO .. WHAT’S THE PROBLEM?
    ▸ degrading quality
    ▸ no feeling of responsibility for production issues
    ▸ increasing overall system complexity

    View full-size slide

  30. 5. stable,,teams
    and ownership
    matter

    View full-size slide

  31. 6. TeAms built around
    features are fast

    View full-size slide

  32. TEAMS BUILT AROUND
    BUSINESS CAPABILITIES
    Source: https://giphy.com/gifs/fire-office-yolo-OongkSFTbly8w

    View full-size slide

  33. Top News
    My News
    Data
    Warehouse

    View full-size slide

  34. 7. modular
    architecture matters

    View full-size slide

  35. 8. there is always a
    monolith. embrace it

    View full-size slide

  36. T-SHAPE DEVS

    View full-size slide

  37. ok but what about
    architecture?

    View full-size slide

  38. ARCHITECTURE PRINCIPLES
    ▸ no ivory tower architect
    ▸ as little upfront architecture as possible
    ▸ subsystems communicate with each other over RabbitMQ
    ▸ databases are not shared between services
    ▸ avoid cascading synchronous communication in user flow
    ▸ keep it simple on every level

    View full-size slide

  39. 1. horizontal teams do not work well for incremental
    feature development
    2. Continuous delivery platform is a must
    3. Horizontal components do not get along with vertical
    teams
    4. monitoring is essential
    5. stable teams and ownership matter
    6/. teams built around features are fast
    6. modular architecture matters
    7. there is always a monolith. embrace it

    View full-size slide

  40. are we happy
    &
    what’s next?

    View full-size slide

  41. THAT’S IT.
    THANK YOU!
    @maciejwalkowiak

    View full-size slide