I wonder how much Gravatar sold for?
Looking Back on Selling Gravatar to Automattic
21–27 of 27 posts
Re: Looking Back on Selling Gravatar to Automattic
#22The 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…
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.
Re: Looking Back on Selling Gravatar to Automattic
#23The 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…
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".
Re: Looking Back on Selling Gravatar to Automattic
#24I wonder how much Gravatar sold for?
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.
Re: Looking Back on Selling Gravatar to Automattic
#25I wonder how much Gravatar sold for?
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 m…
Anyone else care to (anonymously or not) guess at a possible dollar-amount range? Even if just a ballpark figure?
Re: Looking Back on Selling Gravatar to Automattic
#26Earlier quoted context omitted.
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 pra…
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.
Re: Looking Back on Selling Gravatar to Automattic
#27The 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…
They aren't mutually exclusive. A good, simple design will allow you to move faster and scale better.
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.