4 ms·

> While microservices talk likes to pretend the solution is some horrific “monolith”, we never really had “monoliths” before in development that I experienced.

> While microservices talk likes to pretend the solution is some horrific “monolith”, we never really had “monoliths” before in development that I experienced. What we had were some kinds of tiered architectures. I've worked with with monoliths. The author must not have experienced them. I've worked places that had builds that took hours to run. We had git merges that took days. We had commit histories that were unreadable. The developer experience working with it was one of CONSTANT frustration. The system was too big to make large changes safely. Incremental changes were too incremental and costly. Note nowhere in here am I saying that microservice architecture should always be preferred. But the idea that its all just some sort of trend with no real underlying advantage is sort of silly. Every company I've ever been at with a monolith tends to have "untouchables" of architecture and the original design schematics who understand the system orders of magnitude better than anyone else. That doesn't scale, and really messes with an engineering organization. There's conways law where software will eventually reflect the organization structure of the company, but there's also a sort of reverse conways law - when you have teams dedicated to specific services you also get to be able to target investments in those teams when their services are not executing well enough.

Gigachad 5y ago
Yeah I agree, it all breaks down when you need to make large scale changes. Something like updating a core library becomes virtually impossible because there is no half step. You have to fix _everything_ before you can merge and that takes long enough that the merge becomes horrific. I was told that updating Rails at GitHub was a multi year project involving building a compatibility layer so the app could run on both versions at once.

Gigachad 5y ago

Yeah I agree, it all breaks down when you need to make large scale changes. Something like updating a core library becomes virtually impossible because there is no half step. You have to fix _everything_ before you can merge and that takes long enough that the merge becomes horrific. I was told that updating Rails at GitHub was a multi year project involving building a compatibility layer so the app could run on both versions at once.