(2016-02-29) Dhh The Majestic Monolith

DHH: The Majestic Monolith. But before we dive into all its glory, let’s first examine its opposite pattern: Micro/services oriented architecture

M/SOA is a prescription to break down an application into many smaller parts,

This is a great pattern. No, really. Not being sarcastic here. If you’re Amazon or Google or any other software organization with thousands of developers, it’s a wonderful way to parallelize opportunities for improvement.

The patterns that make sense for organizations orders of magnitude larger than yours, are often the exact opposite ones that’ll make sense for you. It’s the essence of cargo culting.

The problem with prematurely turning your application into a range of services is chiefly that it violates the #1 rule of distributed computing: Don’t distribute your computing!

Every time you extract a collaboration between objects to a collaboration between systems, you’re accepting a world of hurt with a myriad of liabilities and failure states. What to do when services are down, how to migrate in concert, and all the pain of running many services in the first place.

Basecamp 3 is available via the web, as native mobile apps on iOS and Android, as native desktop apps on Windows and Mac, and through email as well. That’s a lot of platforms to juggle concurrently! And I believe the only possible way to do so with a small team of ~12 programmers is do explicitly choose and commit to The Majestic Monolith, in all its controversial glory.

One of the benefits to the majestic monolith is that it basically presumes that the people who work on it also understand it.

This in turn puts immense pressure on making the application understandable and changeable by individuals, not teams.

the essence of Ruby and Rails’ perception of programmers. That given the right incentives and nudges, most will rise to the occasion and write beautiful code. That our systems should be a red carpet invitation to become a better, more productive programmer.