Earlier quoted context omitted.
apparently you aren't the first one to wonder that [1]. It is Rachel Kroll, an engineer at fb [2]. Good point about the summary. [1] https://news.ycombinator.com/item?id=13401293 [2] https://www.facebook.com/wogrammer/posts/1748187012080407:0
Recently left FB, in fact. Which is important context for many of her posts in the last month or so.
Interns with toasters: how I taught people about load balancers
41–50 of 124 posts
Re: Interns with toasters: how I taught people about load balancers
#42> This is what happened when one bad web server decided it was going to fail all of its requests, and would do so while incurring the absolute minimum amount of load on itself. Good ELI5 explanation, but it doesn't really explain why the webserver failed the requests as it did. Or maybe I'm missing something?
That the article is about load-balancers and how a single "rogue actor" can have outsized effect on the entire thing. The failing webserver is besides the point.
Re: Interns with toasters: how I taught people about load balancers
#43Who is Rachel and how do her short and simple stories always hit the front-page? They're interesting but I always think they're a little _too_ simple. I mean this entire thing can be summed up with: 500s (and other errors) are returned faster than processed requests. Load-balancers will find a misbehaving server's queue empty more often and give it all the requests
I wonder that too. But it seems she has gift: telling tech stuff as story that resonates with the HN crowd.
Re: Interns with toasters: how I taught people about load balancers
#44Who is Rachel and how do her short and simple stories always hit the front-page? They're interesting but I always think they're a little _too_ simple. I mean this entire thing can be summed up with: 500s (and other errors) are returned faster than processed requests. Load-balancers will find a misbehaving server's queue empty more often and give it all the requests
Everything seems trivial once you understand it. The author seems to be good at making people understand, so that it seems trivial afterwards. Knowing nothing about load balancers, had I read your summary before Rachels article, I would probably just glossed over it, but I would not have understood its profound importance for designing load balancers. Rachel's story kept me engaged and explained the problem in a way…
People need an intuitive concept and image to grasp and reason on while they master an idea, but that doesn’t justify any arbitrary amount of over-elaborating.
Re: Interns with toasters: how I taught people about load balancers
#45Re: Interns with toasters: how I taught people about load balancers
#46Earlier quoted context omitted.
What kind of college teaches about load balancers?
If they’re not teaching about the most basic principles of building scalable systems, what is the point of doing a degree, or hiring people who have done a degree?
Some degrees in CS are really vocational certificates, while more traditional degrees are not.
Re: Interns with toasters: how I taught people about load balancers
#47Re: Interns with toasters: how I taught people about load balancers
#48That's why I like random load balancing. If each machine is powerful enough and can handle a few thousand users then the distribution averages out. Smart load balancers are only really necessary if you have inefficient servers that can't handle more than 100 connections per second and they're difficult to get right. If you toss a coin 10 times, you're much more likely to get >=80% heads than if you were to toss that…
That model works if you have a large number of short lived requests. On the other hand, if you have a small number of long running requests that you want to distribute over a number of servers, then your load balancer needs to track which servers are busy, or you'll spend a lot of time waiting for the randomly assigned server to finish, while others are idle.
If Python is your thing, Celery makes this pattern trivial to implement.
This also simplifies so many other things: for example, deployments (and rollbacks!) can proceed much faster, since you don't need to wait obnoxiously long for all connections to drain.
Of course you're pushing more complexity up the stack, but in my experience it's a good trade-off.
Re: Interns with toasters: how I taught people about load balancers
#49Earlier quoted context omitted.
Recently left FB, in fact. Which is important context for many of her posts in the last month or so.
So basically she's using HN audience as a marketing blog and people are eating it up?
If this had been some post about lessons learned about a the latest whizbang JS framework people wouldn't have had a second thought.
I've read plenty of her posts and have sympathized, as being a long time sysadmin and learning the exact same lessons. She indeed does have a story telling skill which is sorely needed: ops people tend to suck at effectively sharing knowledge - she's doing valuable work here.
I don't understand why there is criticism?
Re: Interns with toasters: how I taught people about load balancers
#50Who is Rachel and how do her short and simple stories always hit the front-page? They're interesting but I always think they're a little _too_ simple. I mean this entire thing can be summed up with: 500s (and other errors) are returned faster than processed requests. Load-balancers will find a misbehaving server's queue empty more often and give it all the requests