There's a book about it too: https://www.safaribooksonline.com/library/view/site-reliabil...

I bought it from O'Reilly....it came with mobi and epub versions. http://shop.oreilly.com/product/0636920041528.do

The SRE Book (http://shop.oreilly.com/product/0636920041528.do) has a number of chapters on load balancing that are well worth reading.

One thing that the book covers that I think this article glossed over was the fact that in sufficiently large systems there's never a single "load balancer" - instead there's many layers of load balancing systems at different levels of the stack. E.g.:

DNS load balancing -> high capacity network-level load balancing -> shared reverse HTTP proxy -> application server -> database (with a "load balancer" internal to the application server load balancing among DB replicas).

I think this is because most companies do pager duty wrong. I highly recommend the google SRE book[0] (notes here[1], chapter 11 covers oncall/pager). One thing mentioned in this book is compensation for being oncall. At Google we get fairly decent pay compensation for holding the pager, enough where it can incentivize people to be on the rotation.

(I'm a software engineer at google who is oncall at this moment)

[0] http://shop.oreilly.com/product/0636920041528.do

[1] http://danluu.com/google-sre-book/

If you liked this post and want to know the full details to this change in ops, please read the SRE book[0]. It's a great read for both devs and ops and can immediately help you make changes to company policy for the better.

[0]: http://shop.oreilly.com/product/0636920041528.do

Looks like it's up on O'Reilly's site: http://shop.oreilly.com/product/0636920041528.do - also on Amazon.

This is still largely at commodity prices / performance points. It's been quite some time since any of their hardware has looked consumer-oriented, but comparing this to what enterprises buy, it's apples and oranges.

[1] http://shop.oreilly.com/product/0636920041528.do

[2] http://research.google.com/pubs/pub35290.html