[altmanaltman]

> “It’s not complex if you do it right. Netflix — “

> “WE’RE NOT NETFLIX!” I finally snapped. “Netflix has 500 engineers. We have 4. Netflix has dedicated DevOps teams. We have one guy. Netflix has millions of users. We have 50,000.”

Then

> Lesson 5: The Monolith Isn’t Your Enemy

> A well-structured monolith can:

> Scale to millions of users (Shopify, GitHub, Stack Overflow prove this)

Because Shopify, Github and Stack Overflow have 4 engineers each as well.

It kind of seems real because it reads like the it's written by the kind of person that would make high level arch decisions without even understanding what the f they are doing.

[Timon3]

This criticism seems like a complete non-sequitur to me. They didn't claim that Shopify, Github and Stack Overflow scaled to millions of users with 4 engineers each. Is the implication that, because Netflix and those companies both had to hire more engineers to scale, the decision between monoliths and microservices has no impact on a 4-person team? I genuinely don't understand what you're trying to imply.

Based on my experience microservices do introduce additional fixed costs compared to monoliths (and these costs can be too expensive for small teams), so everything you've quoted makes complete sense.

[altmanaltman]

In the interest of helping you understand what I was saying, the two quotes are completely contradictory (even if the base argument is correct/valid).

The first one says we shouldn't follow Netflix's example because it is a massive company with an enormous team. The second one says we should follow the example of these companies instead, while ignoring that they are also a huge company with a massive team.

So the criticism/joke stems from the logical inconsistency between the two. The fact that you stopped with microservices, using a rant about Netflix, while at the same time lauding monoliths, using companies of similar scale as examples, highlights your lack of understanding of using team scale as a reason to pursue either alternative. Dealing with such a person in management is common where they often contradict their own reasoning and pick whatever they fancy at that time. You cannot argue logically when the system changes are not based on objective standards but subjective standards, where you can be wrong for one thing but they can be right for the same thing.

That's why it seems like the person making the decisions is lost in terms of the choices they're making.

[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.

[thesz]

Early Stack Overflow, in 2008, was an effort of mostly one engineer (Jeff Atwood) and scaled on that single man power to the tens of thousands of users.

https://en.wikipedia.org/wiki/Stack_Overflow

It is NOW that Stack Overflow may have more than one engineer working on it.

[altmanaltman]

I think you're getting caught up on the wrong thing here. The issue isn't that monoliths can scale. The issue is the inherent flaw in their logic within the confines of the post.

Netflix also didn't appear into existence with an army of engineers. It also scaled from a few engineers to what it is today. Which means you can scale using both depending on your setup. That cannot be the reason why you pick one arch over another. The reason has to do with your own setup, your company, and the application's specific context, all of which the author is missing.

Broadly, it feels like decision making without context/understand the why behind the decisions.

The specific comment has nothing to do with how Github or Stack Overflow scaled etc.

[thesz]

We do not know whether Netflix had microservices from the start, even at the start of their video-on-demand service.

In my daily job I see an effort to bring distributed system into a more monolith one, because it is just easier to debug.

[altmanaltman]

The comment is not based on Netflix or Stack Overflow. Just the person making the decision not having any consistent basis in their reasoning. There is a reason why they are self-admittedly not very good at their job.

I have explained it enough, not sure what you're missing at this point.

[thesz]

  > not sure what you're missing at this point.

We are talking with audience reading our comments. You think you are talking to me but you are talking to much wider audience.

Everyone, including me, are making some assumptions when we are writing something. When it is technical, it is easy to verify - obtain source code, run it, check results. When it is somewhat managerial, it is much harder to verify.

For example, original post emphasizing Stack Overflow being scaling monolith (pun intended) may refer to the point of time when SO were run by basically one man, yet scaling.

You dismiss it, that's okay. You do not answer my or OP points, that's okay too.

Our readers are smart enough to judge OP (and ours) points on their merits.

[altmanaltman]

> Our readers are smart enough to judge OP (and ours) points on their merits.

If we go solely by that criterion, the upvotes on the original comment do prove that people are smart enough to judge the points on their merits. It was good talking to you and to a much wider audience through you.