[Timon3]

Interesting. If I only look at the lines you quoted I can see how you arrive at your interpretation of those two quotes. But if I read them in the industry context, they are a concise response against common arguments for microservices. I'll explain the line of argumentation as I understand it.

- We know that full rewrites are expensive & can kill growing companies, so it's best to start with an architecture that you can keep as you scale

- Common argument for microservices: They scale best, look at Netflix etc.

- Counter argument 1: Netflix has a large team, and microservices add fixed complexity that can kill small teams

- Counter argument 2: Monoliths can also scale (see examples)

That was my initial understanding as someone who has had these discussions before. I don't think I'm adding any arguments, my first point is pretty much universally accepted and known. The author is just assuming a certain level of industry knowledge.

[kasey_junk]

The problem is the article isn’t coherent around this point, because it uses scale vaguely. If you look at the pitch the thing they focus on is _failure domain isolation_ but then the article immediately pivots to how attractive scaling is. Failure domain isolation doesn’t contribute to scale in the performance sense, it can tenuously be tied to scaling teams but that wasn’t part of the pitch.

In fact, I don’t think “scale” is ever part of the pitch of micro services. Independent scaling maybe if you have some particular hot spot. But the real pitch for micro services is and always has been about isolation. Isolating failure domains, teams and change management. That’s been the story since the Bezos letter and if the leadership didn’t understand that it’s a leadership skill issue. Not an architectural problem.

So this is a story about bad technical leadership, not a particular architecture. And if anything the initial pitch by the architect is the most technically valid leadership in the story (as poor as it is). They failed to understand the problem space but at least they identified what problem the architecture would solve. The rest of engineering leadership did the classic pointy haired boss thing of not listening and hearing what they wanted. They paid for it.

[altmanaltman]

> That was my initial understanding as someone who has had these discussions before. I don't think I'm adding any arguments, my first point is pretty much universally accepted and known. The author is just assuming a certain level of industry knowledge.

Or they're just bad at communicating and likely decision-making as well. I would say you're giving the author too much credit to be honest but I get your point. It's a poorly-written article in general imo.

[mjevans]

It's amazing what modern hardware can do when used correctly.

Consider moving to micro-services only AFTER reasonable algorithms on commodity bare metal show real capacity limits. There's still higher spec bare metal to carry said designs through a refactor / expansion based on where the performance bottlenecks are. Even absent literal micro-services there's still partitioning / sharding which can spread out many of the pain points.