51–58 of 58 posts
Earlier quoted context omitted.
100%. The writing style put me off too, not sure exactly what about is weird though
Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.
Earlier quoted context omitted.
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 cri…
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…
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.
Does this story seem kinda…fake…to anyone else? Like, obviously companies do sometimes make decisions this stupid, but the way this is written seems a little too carefully optimized to make for a morality play of the kind HN enjoys. (And there's a potential motive, since there's a whole bunch of links to paid books and such, somewhat clumsily tied to the main narrative.)
> “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 Sta…
https://en.wikipedia.org/wiki/Stack_Overflow
It is NOW that Stack Overflow may have more than one engineer working on it.
Earlier quoted context omitted.
> “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 Sta…
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.
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.
Earlier quoted context omitted.
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.
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…
In my daily job I see an effort to bring distributed system into a more monolith one, because it is just easier to debug.
Earlier quoted context omitted.
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…
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.
I have explained it enough, not sure what you're missing at this point.
Earlier quoted context omitted.
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.
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.
> not sure what you're missing at this point.
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.
Earlier quoted context omitted.
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.
> 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, or…
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.