I keep seeing similar posts but thanks to David, this one has a good case study behind it. However, I see several flaws in the logic:

  • The way you scaled (I have read about it) and it was mostly extensive. Adding more servers and so on. You were scaling also less-used parts of the system just because you cannot do otherwise.
  • The number of people — yes, 12 developers require almost no coordination and the whole point to have isolated components and bring autonomy is dissolving.
  • The quality of people — with you as the core technology creator, you cannot imagine having better technical expertise onboard, but this is not what everyone have.
  • The first law of distributed blahblah, well, splitting things to different services does not assume distributing. For some reason too many forget about this.
  • Maintenance costs — are you sure that your monolith is not your greatest impediment for innovation and growth? How many times you had moments like “we cannot build this because our model does not allow it” and “it’s just too complex to have it”?
  • May be not applicable for 37Signals but relevant for many others — developers seem to see their own problems and needs, forgetting about all others. These can be their users or their own support department. Too many times support just takes the responsibility of dealing with consequences of bad technical design decisions.
  • How flexible is the model of 190 classes and Active Record? How safe you feel changing it? This is returning back to the costs of maintenance from another angle.

More often than not, answers to these questions are not in the bright shiny world of “majestic monolith”.

Alexey is the Event Sourcing and Domain-Driven Design enthusiast and promoter. He works as a Developer Advocate at Event Store and Chief Architect at ABAX.

Alexey is the Event Sourcing and Domain-Driven Design enthusiast and promoter. He works as a Developer Advocate at Event Store and Chief Architect at ABAX.