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
2. Pablo Astigarraga Monday, August 20, 12
3. Uruguay (Yes, we do have some history) Monday, August 20, 12
4. @poteland github.com/pote Monday, August 20, 12
5. We are in Berlin! (This is incredible!) Monday, August 20, 12
6. Monday, August 20, 12
7. Thumbs up! Monday, August 20, 12
8. Monday, August 20, 12
9. The world of today. Monday, August 20, 12
10. The Future Marty! We are definitely in it. Monday, August 20, 12
11. Ach!? Monday, August 20, 12
12. We do have amazing stuff Monday, August 20, 12
13. Yesterday’s problems are easy. Monday, August 20, 12
14. There are new evils. Monday, August 20, 12
15. Everyone today is using a computer. (because we are in the future) Monday, August 20, 12
16. This means traffic. Monday, August 20, 12
17. Alas! Not all is lost! Monday, August 20, 12
18. (re)discovering UNIX The way. Monday, August 20, 12
19. This is good. Monday, August 20, 12
20. But wait! Monday, August 20, 12
21. There is the subtle evil too. Monday, August 20, 12
22. We love our jobs. it starts simply enough: Monday, August 20, 12
23. And we always want to design software in the best possible way. Monday, August 20, 12
24. But sometimes... Monday, August 20, 12
25. We want to build this. flickr.com/photos/aurelian Monday, August 20, 12
26. When our customers really need this. flickr.com/photos/wilzdezign Monday, August 20, 12
27. The best way is the one that benefits our clients. Monday, August 20, 12
28. We can do this right. Monday, August 20, 12
29. Pros vs Cons Monday, August 20, 12
30. Modular Architectures. Monday, August 20, 12
31. Modular - Pros Monday, August 20, 12
32. - Encourages separation of concerns. Modular - Pros Monday, August 20, 12
33. - Encourages separation of concerns. - Which helps keep codebases maintainable. Modular - Pros Monday, August 20, 12
34. - Encourages separation of concerns. - Which helps keep codebases maintainable. - Easier to test and expand. Modular - Pros Monday, August 20, 12
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
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
37. Modular - Cons Monday, August 20, 12
38. - Adds a new layer of code for each module. Modular - Cons Monday, August 20, 12
39. - Adds a new layer of code for each module. - This introduces a certain level of complexity. Modular - Cons Monday, August 20, 12
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
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
42. Monolithic Architectures. Monday, August 20, 12
43. Monolithic - Pros Monday, August 20, 12
44. - Reduced complexity. Monolithic - Pros Monday, August 20, 12
45. - Reduced complexity. - Simpler initial development and deployment. Monolithic - Pros Monday, August 20, 12
46. - Reduced complexity. - Simpler initial development and deployment. - Less worries mean more adaptability. Monolithic - Pros Monday, August 20, 12
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
48. Monolithic - Cons Monday, August 20, 12
49. - Less maintainable for large codebases. Monolithic - Cons Monday, August 20, 12
50. - Less maintainable for large codebases. - Tendency to grow out of control. Monolithic - Cons Monday, August 20, 12
51. - Less maintainable for large codebases. - Tendency to grow out of control. - Larger codebases means difficulty to test. Monolithic - Cons Monday, August 20, 12
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
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
54. How do I choose? Monday, August 20, 12
55. Ask yourself: Monday, August 20, 12
56. Ask yourself: - Am I working on a startup? Monday, August 20, 12
57. Ask yourself: - Am I working on a startup? - Will this be a large app from the get-go? Monday, August 20, 12
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
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
60. Trick Question! Monday, August 20, 12
61. Truth: 99% of startups need a monolithic app. Monday, August 20, 12
62. Think about your project needs. Monday, August 20, 12
63. Choose wisely. Monday, August 20, 12
64. But also: Monday, August 20, 12
65. Keep your options open. Monday, August 20, 12
66. How? Monday, August 20, 12
67. Assume we have a startup. Monday, August 20, 12
68. And we need to build a facebook/twitter/ groupon/foursquare with a twist. Monday, August 20, 12
69. First things first. Monday, August 20, 12
70. Get your monolithic app right. Monday, August 20, 12
71. (groundbreaking stuff eh?) Monday, August 20, 12
72. Design your monolithic app modularly. Monday, August 20, 12
73. Service Pattern. Monday, August 20, 12
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
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
76. (This has other advantages) Monday, August 20, 12
77. What do I get from this? Monday, August 20, 12
78. Your application will grow. Monday, August 20, 12
79. You’ll want to extract parts of it. Monday, August 20, 12
80. Let’s look at a real world example. Monday, August 20, 12
81. Start by building new domain specific features outside of your app. Monday, August 20, 12
82. You will need an API. Monday, August 20, 12
83. Well-Designed services + routing = API Monday, August 20, 12
84. Always code your logic thinking that it will be used in an API. Monday, August 20, 12
85. (You should be doing this anyway) Monday, August 20, 12
86. What if my app is coded nowhere near this approach? Monday, August 20, 12
87. Start Slow. Monday, August 20, 12
88. Do: Monday, August 20, 12
89. Do: - Write new business logic in services. Monday, August 20, 12
90. Do: - Write new business logic in services. - When changing old logic, refactor it. Monday, August 20, 12
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
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
93. For the love of all that is holy: Monday, August 20, 12
94. For the love of all that is holy: Never stop feature development to code a full API. Monday, August 20, 12
95. The change will feel natural. Monday, August 20, 12
96. In short: Monday, August 20, 12
97. Think about your business needs. Monday, August 20, 12
98. Don’t buy into dogma or hype. Monday, August 20, 12
99. Be critical, and choose your solutions accordingly. Monday, August 20, 12
100. There are no holy grails. Monday, August 20, 12
101. Thank you! :D Monday, August 20, 12
102. Monday, August 20, 12
103. Questions? Monday, August 20, 12
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