Stuff The Internet Says On Scalability For February 11, 2011
Friday, February 11, 2011 at 11:02AM
HighScalability Team in hot links
Submitted for your reading pleasure...
A good night's sleep is why Facebook CTO Bret Taylor says Friendfeed should have gone cloud, let others take the midnight watch, even if it costs a bit more.
James Urquhart with an information packed interview on a wide range of cloud topics: Cloud Expert Inside theCube at Stata Conference. Highlights: cloud is an operations model, it is not a technology, it is a way to apply technology to problems; the faster you can get the resources into the hands of the people who use it the more money you save overall; cloud is a cash flow story, not a savings story; services aren't about servers or storage, they are about applications.
Quotable Quotes:
Ryan Tomayko: Frameworks don’t solve scalability problems, design solves scalability problems. Via @GregSkloot
@zuno: The golden rule of scalability: "it can probably wait" look for other areas to save resources.
@bihzad: joinserv hit a scalability wall, but I'm pretty sure I can climb over it with multiprocessing
The always insightful Joe Stump on Location, Scaling, and Herding Cats. First Joe talks about the problems of the real-time mobile web. The data stream from heavily ensensored, always on mobile phones, is a scary amount of data. Then he works into more familiar how-to scale territory, saying the big problem is IO, performance != scalability, scaling is specialization, and automate everything. The last portion of the talk was the most interesting to me. Joe talks about scaling isn't just about scaling your infrastructure, it's scaling your teams, your processes, and engineering culture. A lot of insightful discussion or what one might consider master level scaling topics.
Quora: How does Etsy manage development and operations? Chad Dickerson laying down the insight at Etsy. Overall, engineers are treated as creative collaborators in the overall process with design and product, and products are worked out and iterated on with engineers instead of simply being handed to them for implementation.
Lessons from 30 years of Sendmail by Jonathan Corbet. Before there was before, was Sendmail. Interesting insights into its design and evolution: The KISS (keep it simple, stupid) principle works; If you don't know what you are doing, advance designs will not help; The world is messy, just plan on it; Flexibility trumps performance when the world changes every day; Fix things early; your installed base will only get larger if you succeed, and the pain of not fixing things will only get worse; Use plain text for internal files and protocols; Good documentation is the key to broad acceptance; most projects, he said, have not yet figured this out.