In theory, you'd think you can do load-testing and simulations and capacity planning, and find these breaking points ahead of time. In practice, it's not always feasible, and this seems like a simple-enough hack that gets you much of the way there.
1,090 karma · joined August 31, 2011
In theory, you'd think you can do load-testing and simulations and capacity planning, and find these breaking points ahead of time. In practice, it's not always feasible, and this seems like a simple-enough hack that gets you much of the way there.
http://www.ted.com/talks/jamie_heywood_the_big_idea_my_broth...
And to bring it back full circle to HN: Once original Basecamp sunsets, we think PatientsLikeMe has the oldest continuously-running Rails app; the oldest commits are from 2005, running Rails 0.5.
Since those days, it's less that I've seen the individual-user system work at scale - it's that I've seen the single role account fail, repeatedly. I've managed to avoid permissions hell with a few well-chosen supplemental groups, but maybe I'm too optimistic that what used to work in one environment will work in another. Ask me in six months. :)
Does AOL count? I built the mail system. It was kind of a big deal. We pushed 4,000 TPS through servers less powerful than an iPhone. I also spent time at Akamai, though I admittedly worked on a tiny, isolated test lab (150 servers or so, a fraction of a percent of the "real" server base).
I have worked with some amazing people, at all scales, and I have never seen a deployment that managed to completely avoid manual logins. No, you aren't logging into a few hundred hosts manually (well, there was this one shop... but let's not hold that up as exemplary). But you're probably logging into a few to test things out manually before you decide what your automated deployment script will be rolling out.
Even when you do deploy a fix, with a large sysadmin team it's good to know WHO exactly ran that one-off deployment script. When I said "auditing", I wasn't even thinking of PCI, or auditing against malicious actions of any kind - just simple troubleshooting forensics. But we have a great, robust way to see exactly who modified a file and when; it's the file system. Why reinvent it? (I just spent the last day trying to figure out who edited a script. Why, "postgres" did.. of course it did.)
Should you aim to do these manual config changes in the test lab first? Of course. Do you always succeed? No. Some things only get tested in the big lab. Reality intervenes. I try to plan for it.
Mind you, I'm arguing this partly to see if I can be talked out of it. I think I believe it, but I've been wrong about way bigger things. If you've achieved my automation nirvana, and you roll things out to a few thousand servers, never manually, and never wondering who did it, tell me how it works.
In ten-server deployments, you're logging in because every machine is trying to take on a new role or aspect and you're still learning how to automate that.
In thousand-server deployments you're logging in because the latest batch of Seagate drives has a statistically significant failure rate and you need to try some experimental firmware they wrote for you.
When do you get "serious"?
I don't always log into my production boxes... but when I do, I log in as 'jay'.
"Thunderbird is not dead. We have announced a change in the way we develop new features for Thunderbird."
... in the sense of "not doing that anymore".
Love, DevOps
As someone who's had a few questions shunted from SE site to SE site, being closed at every step, I think SE would do well to emphasize migration over closure. Having a question closed is a real downer, the opposite of all the SE game mechanics. And it's one of the oldest principles of UX: Don't tell me what I should have done. Just do it for me.
That manufacturer is probably flying every single C-level exec out to the US-East data center, over the July 4th holiday, to personally disassemble the generator, polish each screw, and carefully put it all back together while singing an a cappella version of "Bohemian Rhapsody", including vocal percussion.
And if they do it to Amazon's satisfaction, Amazon has hinted that they might decide not to out them to the rest of the world. That's called leverage.
This revisits books from earlier in the decade (like _Good to Great_), and shows that many of the profiled companies failed. It's a great way to learn how to read entrepreneurship books; many theories are based on "Intel is successful; Intel does X; therefore doing X will make you successful".
In general, go read books from ten years ago and see if any of the predictions held up. Likewise, I recommend _Founders at Work_ because so many of these (currently) successful companies were launched with opposing philosophies, and all of them worked. Open plan? Works! Offices? Also works! Deep funding? Works! Bootstrapping? Also works!
We tried this with "AOL Certified Mail", which had an unspoofable official chrome, and I don't remember any serious drop in phishing.
http://huanliu.wordpress.com/2012/03/13/amazon-data-center-s...