Upday Journey to Microservices

What we've learnt when we applied microservices architecture

Transcript

1. JOURNEY TO MICROSERVICES
   @maciejwalkowiak
   

   View Slide

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

   View Slide

3. View Slide

4. View Slide

5. View Slide

6. Greetings
   

   View Slide

7. Greetings
   Top News
   

   View Slide

8. Greetings
   Top News
   My News
   

   View Slide

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

   View Slide

10. People Vector created by Freepik
    

    View Slide

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

    View Slide

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

    View Slide

13. ISSUES
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

18. View Slide

19. View Slide

20. View Slide

21. 2. Continuous delivery
    platform is a must
    

    View Slide

22. CURRENT ARCHITECTURE
    

    View Slide

23. CURRENT ARCHITECTURE
    Team X Team Y Team Z
    

    View Slide

24. CURRENT ARCHITECTURE
    Team X Team Y Team Z
    

    View Slide

25. ISSUES
    

    View Slide

26. 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 Slide

27. 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 Slide

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

    View Slide

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

    View Slide

30. API GATEWAY
    

    View Slide

31. View Slide

32. API GATEWAY - MIGRATION PHASE
    

    View Slide

33. HAPPY DEVELOPERS!
    HAPPY MANAGERS!
    

    View Slide

34. 1.000.000
    users
    

    View Slide

35. 4. monitoring is
    essential
    

    View Slide

36. View Slide

37. View Slide

38. ISSUES
    

    View Slide

39. 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 Slide

40. 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 Slide

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

    View Slide

42. View Slide

43. View Slide

44. ISSUES
    

    View Slide

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

    View Slide

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

    View Slide

47. 5. stable,,teams
    and ownership
    matter
    

    View Slide

48. 6. TeAms built around
    features are fast
    

    View Slide

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

    View Slide

50. Top News
    My News
    Data
    Warehouse
    

    View Slide

51. View Slide

52. 7. modular
    architecture matters
    

    View Slide

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

    View Slide

54. T-SHAPE DEVS
    

    View Slide

55. ok but what about
    architecture?
    

    View Slide

56. 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 Slide

57. 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 Slide

58. are we happy
    &
    what’s next?
    

    View Slide

59. View Slide

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

    View Slide