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.