David Heinemeier Hansson: Microservices vs. Monolith

David Heinemeier Hansson: Microservices vs. Monolith - https://www.youtube.com/watch?v=rkXGSLf-rVQ

For the last several years, one of the big titanic battles in how to structure your application has been to go microservices or to go monolith. This debate has been raging on and off, sometimes intensively, otherwise dulling down. But as of recent note, it's kind of blossomed up again, because a lot of applications who've gone with a microservices architecture, when that was the hot, hot thing, I realized that perhaps it wasn't so hot for them. Even the likes of Amazon has backed off on microservices for at least some of their applications. And I think there's a really good reason for that. Microservices is a pattern that is about organizational structure much more than it is about how to organize your code. If you have incredibly large teams working on single applications and you have to break those up such that the individual teams can own a sub area of it, yeah, microservices can make sense in some cases. But if you're a team of 10, 20, maybe even 50 or 100 developers, going with a monolith is just so much simpler. Instead of replacing all your method calls with network calls, you can just keep it on the same computer. When you don't have to worry about network connectivity to make the app do its most basic functions, you cut out a huge swath of computer complexity that otherwise bogs you down, makes things hard to debug, makes it hard for any individual to understand the whole system. And I think what's really key here is to realize that different patterns fit different organizations. Microservices, and that whole approach came out of companies like Netflix, with thousands and thousands of developers who needed a different approach to building their systems and making it scale for that level of an organization. If you take those kinds of patterns, the patterns that were built and extracted from companies of thousands of developers, and you apply them to companies of 5, 10, or 100 developers, you very often get really poor results. You are paying a heavy complexity tax for an environment and a context that just doesn't exist in your organization. That, to me, is one of the most foolish things that you can do. So I love the monolith. I love it so much. I coined the term the Majestic Monolith many years ago. I've been advocating for keeping things as simple as possible for as long as possible. And the Majestic Monolith does exactly that.