The Majestic Monolith vs Microservices
Note: Liberally taken from this blog.
"When you reach a certain scale, there simply is no other reasonable way to make coordination of effort happen. Otherwise everyone will step on each other’s feet, and you’ll have to deal with endless merge conflicts. (Well, at least in theory, I hear Facebook is having a great time with a monolith, whether it’s majestic or not is a different discussion).
In other words, M/SOA fits the organizational shape of very large corporations.
So far so good! Where things go astray is when people look at, say, Amazon or Google or whoever else might be commanding a fleet of services, and think, hey it works for The Most Successful, I’m sure it’ll work for me too. Bzzzzzzzzt!! Wrong!"
I totally agree. Using M/SOA it's an hard decision.
--
"The patterns that make sense for organizations orders of magnitude larger than yours, is often the exact opposite ones that’ll make sense for you. It’s the essence of cargo culting."
Exactly!
--
"Basecamp is a large application. There are literally hundreds of screens of various kinds under its domain. We have 200 controllers with a total of 900 methods! This combined with a model of 190 classes with some 1473 methods. And that’s just what’s directly inside app/*, not to talk about our front-end, like the Trix text editor.
Basecamp is a small team. As I mentioned, we have just 12 programmers, and many of those are busy keeping the systems we’ve been creating over the last decade operational. In addition, we have just 7 designers (counting Jason, my partner and our CEO)."
I was alone, I wrote more than 400 (4 hundred!) model classes, with more than 3,000 (3 thousand!) methods, obtaining 15,000 Java LOCs in the model (with further 20,000 LOCs of unit and integration tests) in a year and half of work.
Maybe it's really me not used to handle large applications, but I thought it was a bit complicated even for a Majestic Monolith. I can't even imagine how complex would become with a Microservices architecture.