“You don't need this overengineered goo for your project.” • Hacker News Board

Re: “You don't need this overengineered goo for your project.”

#101

Post by lamontcg » Tue, Sep 07, 2021, 4:31 PM UTC

chrismorgan wrote: post #19

DaGardner wrote: post #17

Earlier quoted context omitted.

Yes it does: https://stackexchange.com/performance Pretty impressive I think.

No it doesn’t. From your link: • 9 web servers • 4 SQL servers • 2 Redis servers • 3 tag engine servers • 3 Elasticsearch servers • 2 HAProxy servers That comes to 23. I know “a couple” is sometimes used to mean more than two, but… not that much more than two. “A couple” is just flat-out wrong; I’d guess that he’s misinterpreting ancient figures, taking the figures from no later than about 2013 about how many web ser…

23 is not a lot of servers.

That is still doable with mid-90s era hand management of servers (all named after characters in lord of the rings).

Not that you should, but you could.

And the growth rate must be very low and pretty easy to plan out your O/S upgrade and hardware upgrade tempo.

And it was actually possible to manage tens of thousands of servers before containers. The only thing you really need is what they now call a "cattle not pets" mentality.

What you lose is the flexibility of shoving around software programmatically to other bits of hardware to scale/failover and you'll need to overprovision some, but even if half of SOs infrastructure is "wasted" that isn't a lot of money.

And if they're running that hardware lean in racks in a datacenter that they lease and they're not writing large checks to VMware/EMC/NetApp for anything, then they'd probably spend 10x the money microservicing everything and shoving it all into someone's kubernetes cloud.

In most places though this will fail due to resume-driven design and you'll wind up with a lot of sprawl because managers don't say no to overengineering. So at SO there must be at least one person in management with a cheap vision of how to engineer software and hardware. Once they leave or that culture changes the footprint will eventually start to explode.

Re: “You don't need this overengineered goo for your project.”

#102

Post by piva00 » Tue, Sep 07, 2021, 4:42 PM UTC

corobo wrote: post #89

piva00 wrote: post #66

Earlier quoted context omitted.

Sometimes I question myself if people posting these "a junior dev can build this product" haven't really worked with systems at scale and all of the myriad of issues that scale brings or if they are being the usual hyper-optimistic-dev that isn't considering much past the proof-of-concept point of a product. Either way is quite baffling how common this kind of comment is, almost a decade reading Hacker News and it po…

It also doesn't matter if a junior dev could do it if they just don't do it If it's so trivial, go be rich!

I remember this post from gregdoesit [1] as a good example of how much complexity is hidden under seemingly trivial interfaces. It's about Uber's supposedly bloated app, I believe that anyone who has worked at a scale where they had to support different national legal systems in their code would know that maintaining a large-scale product is nothing trivial.

[1] https://news.ycombinator.com/item?id=25376346

Re: “You don't need this overengineered goo for your project.”

#103

Post by TheCoelacanth » Tue, Sep 07, 2021, 10:27 PM UTC

manigandham wrote: post #85

chrismorgan wrote: post #19

Earlier quoted context omitted.

No it doesn’t. From your link: • 9 web servers • 4 SQL servers • 2 Redis servers • 3 tag engine servers • 3 Elasticsearch servers • 2 HAProxy servers That comes to 23. I know “a couple” is sometimes used to mean more than two, but… not that much more than two. “A couple” is just flat-out wrong; I’d guess that he’s misinterpreting ancient figures, taking the figures from no later than about 2013 about how many web ser…

Most of that is extra unused capacity. They've shared their load graphs and past anecdotes where it's clear the entire site runs very lean. Also 23 is very much a couple for a company and application of that size. It's not uncommon to see several hundred or thousands of nodes deployed by similar sites.

Two of their servers have 1.5 TB of RAM each. Just one of those nodes is probably as powerful and expensive as 100 nodes in a thousand node setup.

They aren't magically more efficient than other sites. They just chose to scale vertically instead of horizontally.

Re: “You don't need this overengineered goo for your project.”

#104

Post by BackBlast » Tue, Sep 07, 2021, 11:24 PM UTC

notanzaiiswear wrote: post #100

BackBlast wrote: post #97

Earlier quoted context omitted.

This doesn't seem to be as easily defined as you say. The new AWS group is more or less targeted at "avoid bad press" rather than "indefensible politics", whatever that is. Twitter mobs seem to be quite fickle to me and can just as easily eat their own as their usual fare. News outlets aren't a lot better, often following big enough gripe fests and piling on like the rest. It's not just based on particular politics.…

It gives activists another angle of attack on your business. If they can create enough of a scandal, Amazon might drop you to avoid bad press.

I don't use any cloud service that isn't available at other vendors. This isn't my primary reason, but it is on the radar.

Re: “You don't need this overengineered goo for your project.”

#105

Post by shakna » Wed, Sep 08, 2021, 2:30 AM UTC

ed_elliott_asc wrote: post #28

Etheryte wrote: post #25

Earlier quoted context omitted.

I don't think this really does justice to what Stack Overflow does. They're probably the most visited engineering-related site on any given day. They have their widely known Q&A, live updates and notifications, chat rooms, a blog, job listings with email updates, review queues, moderator tools, and so forth. Perhaps you only use three features, but the site does a tremendous amount, and that's not even thinking about…

Perhaps I was being a little dismissive but it doesn’t have the same features of something like Facebook or LinkedIn or google

> but it doesn’t have the same features of something like Facebook or LinkedIn or google

But it does seem to have most of the features of something like Reddit.

Re: “You don't need this overengineered goo for your project.”

#106

Post by manigandham » Wed, Sep 08, 2021, 2:53 AM UTC

TheCoelacanth wrote: post #103

manigandham wrote: post #85

Earlier quoted context omitted.

Most of that is extra unused capacity. They've shared their load graphs and past anecdotes where it's clear the entire site runs very lean. Also 23 is very much a couple for a company and application of that size. It's not uncommon to see several hundred or thousands of nodes deployed by similar sites.

Two of their servers have 1.5 TB of RAM each. Just one of those nodes is probably as powerful and expensive as 100 nodes in a thousand node setup. They aren't magically more efficient than other sites. They just chose to scale vertically instead of horizontally.

> "They aren't magically more efficient than other sites"

It's certainly not magic but good architecture decisions and solid engineering. This includes choosing SQL Server over other databases (especially when they started), using ASP.NET server-side as a monolithic app with a focus on fast rendering, and yes, scaling vertically on their own colo hardware. The overall footprint for the scale they serve is very small.

It's the sum of all these factors together, and it absolutely makes them more efficient than many other sites.

Re: “You don't need this overengineered goo for your project.”

#107

Post by p_l » Wed, Sep 08, 2021, 8:14 AM UTC

andrewingram wrote: post #73

p_l wrote: post #65

Earlier quoted context omitted.

Stack Overflow is also a) old system built before a lot of current management tech was available openly b) Very single-application centered. EDIT: To expand on it - they had to manually build a lot of what could be much easier handled today, and thus had no incentive to change later. Interestingly enough, SO has a lot of moving parts distributed over multiple servers, even if all of those servers used to fit into 1-3…

The single vs multiple application centric thing is a point that's not made enough. Google is basically now a company all about spinning up new products, rather than just periodically adding a new piece of tech to an existing product. As a layperson, Kubernetes _appears_ to be about making it easier to spin up (and run) new products, so it feels more appropriate for Google-like org types.

There are also a lot many more applications one might need to run, especially when scaling beyond one-two people running all development on their laptops/desktops and not having a company yet - especially when one doesn't have valley-style funding.

Also these days you might not want to implement login functionality from scratch, or have better logging, monitoring, etc. and that might involve running more applications than just your LAMP stack.