The next time someone bitches to me about scaling, I'm going to point them to this article. It's a perfect example of why designing to scale from the beginning is usually bullshit.
It's only worth scaling once you know you have something worth it. Why design all sorts of crazy cache schemes, redundant load balancers, and master-slave databases when your actual product is crap? All you end up doing is slowing yourself down. Get some validation first that anyone is going to swallow your idea.
Sure, he had some late nights and some angry emails, but that's because he was dealing with the growing pains of being a success. Better that than the loneliness and depression of working endlessly and never getting anything out the door.
I've found that it's best to find some sort of sweet spot. Not so simple that later scaling requires a huge rewrite, but not so complex that you're spending valuable time up front to scale something that may never need it. I now try to code the first version as a simple version of the later version. Think ahead, but build for the present.
keeping scaling in mind helps a lot, but the real problems you'll run into then are the ones you're not aware of... like a 32,000 directory limit on linux. as your application grows, you just get blindsided at random, and need to put out fires constantly.
and that's where experience with scaling comes in handy. if you don't have it, the next best thing you can do is to have a knowledgeable friend, read up on best practices, and deal with fires quickly.
You can also setup a script to load up a million fake users onto a spare box and then mimic some typical activity. This'll catch a lot of the unforseen problems that'll show up: it'd catch that 32k directory limit, it caught the >1000 files/directory slowdown when I tried it, and it'll catch most database indexing or join problems. And if your test computer is much slower than the computer driving the requests, you can catch CPU or I/O bottlenecks in the webserver stack. I use P2/200 Mhz that's 10 years old for this and ping it from my parent's desktop that they bought last year.
There're still unforseen problems - there always are - but you can flush out some of the more obvious issues. And the testing can run concurrently with some of the last minute design tweaks, so it doesn't cost all that much in development time. Or do it after you launch when you've got a spare moment; very few websites get big immediately.
It's my belief that the "how" is as important as the "what" when it comes to your business. If you don't put the same quality of thought into how you execute on your solution, your value proposition is that much harder to emphasize.
I agree with you, but on the other hand, it's worth keeping the 90/10 rule in mind: if you can get 90% more performance up front with only 10% more effort, go for it. Caching images instead of generating them on the fly is pretty low hanging fruit.
(yes, I made up a 90/10 rule just to make my argument sound better).
> if you can get 90% more performance up front with only 10% more effort, go for it.
Scale is only loosely related to performance.
You can have an application that performs pretty badly, but scales. This is much better than an application that performs well, but won't scale.
Performance tends to degrade slowly, while scale is usually a hard limit (you've reached "n" users? server crashes). Hitting an issue of scale is usually a fairly traumatic thing for a service.
I'd agree with the original comment that when you're starting you don't need fancy caching schemes, load balancers or replicated databases.
Equally you don't want to build something that is incompatible with these in the future. It's a terrible pain and is probably indicative of a bad design... As the other reply said quite well: A good, simple design will allow you to move faster and scale better..
I'm a big fan of "optimise last", but I think this is often interpreted as "put together badly and fix later"... It should really be "quantify what you optimise".
I think it's a balance. You have to design with scaling in mind, and pick tools that allow you to potentially scale later on. If possible you don't want to have to rewrite you app several times from scratch as you scale.
But I agree. The hardest bit is making something people will use, and come back and use again, and again.
Once Automattic took over and scaled Gravatar out with their amazing CDN, adoption really ramped up. I use them without pause on my own projects, and I'm really happy to not have to configure my avatar every place I go!
I'm really glad you enjoyed it! Were you at Active? I'll write a post later on about how I ended up moving to SF. Good call on the move, this area is amazing.
Yup Active. We were in the same team. Crazy Rob and I know each other. The Active home page was "cameronized" last week.
Moving here is probably the best decision I've made in terms of my career. It's easier to meet like-minded people. I got to know startup founders and employees with no effort at all.
I would imagine this success made walking away from that other success (http://news.ycombinator.com/item?id=338286) easier. And, of course, GitHub is proving an even greater success.
Your story, once written, will be one of a man fighting tooth and nail with success coming from all directions.
Unfortunately I'm contractually obligated to keep that information private. If I could tell you the number, I would have no problem doing so, as it would be instructive and beneficial to the startup community to have comparison numbers on which to base their own decisions. Keeping dollar amounts private almost always only benefits the larger company involved. If other companies had better/more data, they would have more leverage during negotiations. Such information is very valuable for evaluating what a fair market price is.
"It was also made clear by Toni that Automattic would maintain Gravatar as a separate brand and continue its evolution (instead of just absorbing it into WordPress)."
I just looked at getting a gravatar for my Github account. I didn't do it because the signup page told me I was actually signing up for a Wordpress account and I needed to choose a handle I could never ever change. I wanted an icon, not to make an irrevocable decision and sign up for some unrelated site, so I gave up. The author writes "Gravatar was a feature"; I felt the same way: I was left wondering why GitHub would outsource a feature for another company to confuse.
Lots of nice history here, though. Great blog post.
I think it was inevitable that Automattic would more closely integrate the two products, but they're doing it in a way that maintains both brands. As far as having to choose a permanent identifier on signup, it's not the path I would have chosen (signup forms need to be as dead simple as painless as possible), but it certainly doesn't seem like too high a hurdle for most people to jump.
Cool. I guess it's a 'make something people want' story: it's one of those things that I look at and say "boring", but people wanted it, so it was successful.
It's only worth scaling once you know you have something worth it. Why design all sorts of crazy cache schemes, redundant load balancers, and master-slave databases when your actual product is crap? All you end up doing is slowing yourself down. Get some validation first that anyone is going to swallow your idea.
Sure, he had some late nights and some angry emails, but that's because he was dealing with the growing pains of being a success. Better that than the loneliness and depression of working endlessly and never getting anything out the door.