Modular vs Monolithic: No Holy Grails

One of the biggest problems in web development today is scalability. It’s a big problem, and not always easy to solve. The sheer number of requests that large applications need to process is huge, and increasing every day.

One of the most elegant and widely adopted techniques to deal with this is favoring modular architectures over monolithic ones. Having a distributed network of tiny apps makes it easier to have a robust, maintainable codebase. Adopting the Unix philosophy of doing one thing right is a topic that has been coming up at conferences and on blog posts all over the world lately, and with good reason.

But is a modular architecture always the best solution? Is then a monolithic approach “wrong” from the get go? Sometimes building a modular system is worth it, sometimes it just isn’t. In this talk I put forward my thoughts and experiences dealing with refactoring your application into several small ones, how to build a monolithic app that can be easily split, how to approach the refactor gradually and incrementally, so as not to lose the ability to deliver new features, and how to decide when it’s simply not worth it.

Transcript

1. Modular
   vs
   Monolithic
   No Holy Grails
   Monday, August 20, 12
   

   View Slide

2. Pablo
   Astigarraga
   Monday, August 20, 12
   

   View Slide

3. Uruguay
   (Yes, we do have some history)
   Monday, August 20, 12
   

   View Slide

4. @poteland
   github.com/pote
   Monday, August 20, 12
   

   View Slide

5. We are in Berlin!
   (This is incredible!)
   Monday, August 20, 12
   

   View Slide

6. Monday, August 20, 12
   

   View Slide

7. Thumbs up!
   Monday, August 20, 12
   

   View Slide

8. Monday, August 20, 12
   

   View Slide

9. The world of
   today.
   Monday, August 20, 12
   

   View Slide

10. The Future Marty!
    We are definitely in it.
    Monday, August 20, 12
    

    View Slide

11. Ach!?
    Monday, August 20, 12
    

    View Slide

12. We do have
    amazing stuff
    Monday, August 20, 12
    

    View Slide

13. Yesterday’s
    problems are easy.
    Monday, August 20, 12
    

    View Slide

14. There are
    new evils.
    Monday, August 20, 12
    

    View Slide

15. Everyone today is
    using a computer.
    (because we are in the
    future)
    Monday, August 20, 12
    

    View Slide

16. This means traffic.
    Monday, August 20, 12
    

    View Slide

17. Alas! Not all is
    lost!
    Monday, August 20, 12
    

    View Slide

18. (re)discovering
    UNIX
    The
    way.
    Monday, August 20, 12
    

    View Slide

19. This is good.
    Monday, August 20, 12
    

    View Slide

20. But wait!
    Monday, August 20, 12
    

    View Slide

21. There is the subtle
    evil too.
    Monday, August 20, 12
    

    View Slide

22. We love our jobs.
    it starts simply enough:
    Monday, August 20, 12
    

    View Slide

23. And we always want
    to design software in
    the best possible way.
    Monday, August 20, 12
    

    View Slide

24. But sometimes...
    Monday, August 20, 12
    

    View Slide

25. We want
    to build
    this.
    flickr.com/photos/aurelian
    Monday, August 20, 12
    

    View Slide

26. When our
    customers
    really need
    this.
    flickr.com/photos/wilzdezign
    Monday, August 20, 12
    

    View Slide

27. The best way is the
    one that benefits
    our clients.
    Monday, August 20, 12
    

    View Slide

28. We can do this
    right.
    Monday, August 20, 12
    

    View Slide

29. Pros
    vs
    Cons
    Monday, August 20, 12
    

    View Slide

30. Modular
    Architectures.
    Monday, August 20, 12
    

    View Slide

31. Modular - Pros
    Monday, August 20, 12
    

    View Slide

32. - Encourages separation of concerns.
    Modular - Pros
    Monday, August 20, 12
    

    View Slide

33. - Encourages separation of concerns.
    - Which helps keep codebases maintainable.
    Modular - Pros
    Monday, August 20, 12
    

    View Slide

34. - Encourages separation of concerns.
    - Which helps keep codebases maintainable.
    - Easier to test and expand.
    Modular - Pros
    Monday, August 20, 12
    

    View Slide

35. - Encourages separation of concerns.
    - Which helps keep codebases maintainable.
    - Easier to test and expand.
    - Simplifies scalability in terms of raw traffic.
    Modular - Pros
    Monday, August 20, 12
    

    View Slide

36. - Encourages separation of concerns.
    - Which helps keep codebases maintainable.
    - Easier to test and expand.
    - Simplifies scalability in terms of raw traffic.
    - More flexibility, less coupling.
    Modular - Pros
    Monday, August 20, 12
    

    View Slide

37. Modular - Cons
    Monday, August 20, 12
    

    View Slide

38. - Adds a new layer of code for each module.
    Modular - Cons
    Monday, August 20, 12
    

    View Slide

39. - Adds a new layer of code for each module.
    - This introduces a certain level of complexity.
    Modular - Cons
    Monday, August 20, 12
    

    View Slide

40. - Adds a new layer of code for each module.
    - This introduces a certain level of complexity.
    - Making the initial development slower.
    Modular - Cons
    Monday, August 20, 12
    

    View Slide

41. - Adds a new layer of code for each module.
    - This introduces a certain level of complexity.
    - Making the initial development slower.
    - And your adaptability weaker (at first).
    Modular - Cons
    Monday, August 20, 12
    

    View Slide

42. Monolithic
    Architectures.
    Monday, August 20, 12
    

    View Slide

43. Monolithic - Pros
    Monday, August 20, 12
    

    View Slide

44. - Reduced complexity.
    Monolithic - Pros
    Monday, August 20, 12
    

    View Slide

45. - Reduced complexity.
    - Simpler initial development and deployment.
    Monolithic - Pros
    Monday, August 20, 12
    

    View Slide

46. - Reduced complexity.
    - Simpler initial development and deployment.
    - Less worries mean more adaptability.
    Monolithic - Pros
    Monday, August 20, 12
    

    View Slide

47. - Reduced complexity.
    - Simpler initial development and deployment.
    - Less worries mean more adaptability.
    - More time for features and client value.
    Monolithic - Pros
    Monday, August 20, 12
    

    View Slide

48. Monolithic - Cons
    Monday, August 20, 12
    

    View Slide

49. - Less maintainable for large codebases.
    Monolithic - Cons
    Monday, August 20, 12
    

    View Slide

50. - Less maintainable for large codebases.
    - Tendency to grow out of control.
    Monolithic - Cons
    Monday, August 20, 12
    

    View Slide

51. - Less maintainable for large codebases.
    - Tendency to grow out of control.
    - Larger codebases means difficulty to test.
    Monolithic - Cons
    Monday, August 20, 12
    

    View Slide

52. - Less maintainable for large codebases.
    - Tendency to grow out of control.
    - Larger codebases means difficulty to test.
    - Coupling, lots of coupling.
    Monolithic - Cons
    Monday, August 20, 12
    

    View Slide

53. - Less maintainable for large codebases.
    - Tendency to grow out of control.
    - Larger codebases means difficulty to test.
    - Coupling, lots of coupling.
    Monolithic - Cons
    - Harder to scale for large traffic.
    Monday, August 20, 12
    

    View Slide

54. How do I choose?
    Monday, August 20, 12
    

    View Slide

55. Ask yourself:
    Monday, August 20, 12
    

    View Slide

56. Ask yourself:
    - Am I working on a startup?
    Monday, August 20, 12
    

    View Slide

57. Ask yourself:
    - Am I working on a startup?
    - Will this be a large app from the get-go?
    Monday, August 20, 12
    

    View Slide

58. Ask yourself:
    - Am I working on a startup?
    - Will I be serving a huge amount of traffic
    in the near future?
    - Will this be a large app from the get-go?
    Monday, August 20, 12
    

    View Slide

59. Ask yourself:
    - Am I working on a startup?
    - Will I be serving a huge amount of traffic
    in the near future?
    - Are you sure? ಠ_ಠ
    - Will this be a large app from the get-go?
    Monday, August 20, 12
    

    View Slide

60. Trick Question!
    Monday, August 20, 12
    

    View Slide

61. Truth:
    99% of startups
    need a monolithic
    app.
    Monday, August 20, 12
    

    View Slide

62. Think about your
    project needs.
    Monday, August 20, 12
    

    View Slide

63. Choose wisely.
    Monday, August 20, 12
    

    View Slide

64. But also:
    Monday, August 20, 12
    

    View Slide

65. Keep your
    options
    open.
    Monday, August 20, 12
    

    View Slide

66. How?
    Monday, August 20, 12
    

    View Slide

67. Assume we have
    a startup.
    Monday, August 20, 12
    

    View Slide

68. And we need to build a
    facebook/twitter/
    groupon/foursquare
    with a twist.
    Monday, August 20, 12
    

    View Slide

69. First things first.
    Monday, August 20, 12
    

    View Slide

70. Get your
    monolithic app
    right.
    Monday, August 20, 12
    

    View Slide

71. (groundbreaking
    stuff eh?)
    Monday, August 20, 12
    

    View Slide

72. Design your
    monolithic app
    modularly.
    Monday, August 20, 12
    

    View Slide

73. Service
    Pattern.
    Monday, August 20, 12
    

    View Slide

74. TL;DR
    Use your models to handle mainly
    persistence, put complex business
    logic in services you can call easily.
    James Golick
    Monday, August 20, 12
    

    View Slide

75. class UserCreationService
    def initialize(user_klass = User, log_klass = Log)
    @user_klass = user_klass
    @log_klass = log_klass
    end
    def create(params)
    @user_klass.create(params).tap do |u|
    @log_klass.new_user(u)
    end
    end
    end
    Monday, August 20, 12
    

    View Slide

76. (This has other
    advantages)
    Monday, August 20, 12
    

    View Slide

77. What do I get from this?
    Monday, August 20, 12
    

    View Slide

78. Your application
    will grow.
    Monday, August 20, 12
    

    View Slide

79. You’ll want to
    extract parts of it.
    Monday, August 20, 12
    

    View Slide

80. Let’s look at a real
    world example.
    Monday, August 20, 12
    

    View Slide

81. Start by building new
    domain specific features
    outside of your app.
    Monday, August 20, 12
    

    View Slide

82. You will need an API.
    Monday, August 20, 12
    

    View Slide

83. Well-Designed
    services
    +
    routing
    =
    API
    Monday, August 20, 12
    

    View Slide

84. Always code your
    logic thinking that it
    will be used in an API.
    Monday, August 20, 12
    

    View Slide

85. (You should be
    doing this
    anyway)
    Monday, August 20, 12
    

    View Slide

86. What if my app is
    coded nowhere
    near this approach?
    Monday, August 20, 12
    

    View Slide

87. Start Slow.
    Monday, August 20, 12
    

    View Slide

88. Do:
    Monday, August 20, 12
    

    View Slide

89. Do:
    - Write new business logic in services.
    Monday, August 20, 12
    

    View Slide

90. Do:
    - Write new business logic in services.
    - When changing old logic, refactor it.
    Monday, August 20, 12
    

    View Slide

91. Do:
    - Create API calls on a per need basis.
    - Write new business logic in services.
    - When changing old logic, refactor it.
    Monday, August 20, 12
    

    View Slide

92. Do:
    - Create API calls on a per need basis.
    - Map API calls to _one_ service.
    - Write new business logic in services.
    - When changing old logic, refactor it.
    Monday, August 20, 12
    

    View Slide

93. For the love of all that is holy:
    Monday, August 20, 12
    

    View Slide

94. For the love of all that is holy:
    Never stop feature
    development to code
    a full API.
    Monday, August 20, 12
    

    View Slide

95. The
    change
    will
    feel
    natural.
    Monday, August 20, 12
    

    View Slide

96. In short:
    Monday, August 20, 12
    

    View Slide

97. Think about your
    business needs.
    Monday, August 20, 12
    

    View Slide

98. Don’t buy into
    dogma or hype.
    Monday, August 20, 12
    

    View Slide

99. Be critical, and
    choose your solutions
    accordingly.
    Monday, August 20, 12
    

    View Slide

100. There are no holy
     grails.
     Monday, August 20, 12
     

     View Slide

101. Thank you! :D
     Monday, August 20, 12
     

     View Slide

102. Monday, August 20, 12
     

     View Slide

103. Questions?
     Monday, August 20, 12
     

     View Slide

104. Links:
     @poteland
     - Service Pattern:
     http://bit.ly/9hBela
     - Slides:
     http://bit.ly/Pf6u9O
     - Looking for a job?
     http://cuboxlabs.com
     Monday, August 20, 12
     

     View Slide