Web 2.0 Companies NEED To Scale
I’m not sure when building a scaleable web app became optional. But Feedster, Technorati, Delicious, Google Analytics (and numerous other Google apps of late), BlogPulse and many of the other “big apps” have “suddenly” been hit by scaleability issues.
And so has FeedLounge:
As previously discussed in some depth, we’ve run into all sorts of trouble with scalability. When we began this project, I was working on the interaction design and saw a web based feed reader as “just another web application” - I was dead wrong (Scott already had a better idea about the scale we were looking at, but even he was surprised by what we found). The feed refreshing is a significantly higher load on the system than the actual users are - more like a search engine than a webmail system. We quickly found this out, and it fundamentally changed the way we had to approach the project.
Yeah. Here’s their process:
1. Start with a handful of users. This is too much for ded box.
2. Move to dedicated server.
3. Add a few more users til they’re at 100. This is too much for one box.
4. Add more hardware. It’s obvious this isn’t enough.
5. Recode.
Erm… Hello? Should the recoding have happened after step 1? I mean, if you draw a graph of “okay if we use 10% of a CPU with 10 users, with 100,000 users we’ll need 10K CPU’s” … Something’s wrong.
Maybe I’m just spoiled, having worked in high performance, high availability apps before, but it constantly astounds me what some folk consider “scaleable” and “available” applications. I’ve spent about 10 hours this month working with really, really high profile Web 2.0 ish companies nearly yelling at them about their lack of true infrastructure.
I won’t even get into their code.
It’s funny, because you’d think companies would have learned this lesson years ago. I remember back in the mid part of the .com boom I spent 2 days with Amazon optimizing their front-end code (HTML, JS, CSS, etc). Over 2 days, we trimmed about 50K of weight from it. Nothing major, just smart optimization. It saved them the need for 20 new servers and a major bandwidth upgrade.
Listen up. If your company relies on the web to stay alive, you’d damn well better be using at least some of the following “ladder to high availability”:
Backups, Redundant, Failover, Cluster, Distributed, Grid and finally Mesh
Each step up is a massive increase in cost, but it’s also a massive increase in uptime and such. I hate it when companies say they want 99.9% uptime (or even worse 5 9s of uptime) without thinking about what that’ll cost them.
If your business depends on your website being up, look at your code, look at your infrastructure and for your users sake figure out what you actually need and build the damn thing properly!
Thank you ;-)
POSTED IN: Business, IT News & Thoughts
11 opinions for Web 2.0 Companies NEED To Scale
Greg
Dec 6, 2005 at 4:11 am
Haha, you got told!
http://dotnot.org/blog/archives/2005/12/05/scalability-is-not-the-only -concern/
Dan Ciruli
Dec 6, 2005 at 8:04 pm
Couldn’t have said it better myself (so I quoted most of your post in my blog!). I will say this: designing for scalability doesn’t have to be difficult or expensive if 1) it’s done early, and 2) you utlize good tools for distribution (rather than writing them from scratch yourself)
Steve Borsch
Dec 6, 2005 at 9:08 pm
Glad to see people are talking about this issue. IMHO, this infrastructure discussion is the “dirty little secret” of all the hyperbole surrounding Web 2.0. Just wait until there is global scaling required!
I did a post about this dirty little secret right after the Web 2.0 Conference since this missing part of the discussion was so glaringly left out.
Joe Palladino
Dec 7, 2005 at 12:46 am
Here here!
The problem is that for so long web development wasn’t considered real development. it is taking time for the reality that this isn’t just real development it can be a bit more if you also including the front end as well.
john
Dec 7, 2005 at 2:16 am
totally agreed Jeremy… totally agreed. I also wish it were easier… and the funny thing is, a lot of the time it could be easier… but the experience isn’t generally spread out enough to do the simple things that can help… content caching via a CDN, smart scheduled processes, offloading non-mission critical tasks to other boxes, etc… lots of people have never had to deal with true scale, so they aren’t adept at it. Maybe there’s a good consulting gig there in this need?
Jeremy Pepper
Dec 8, 2005 at 4:57 am
Well, wasn’t that how Gmail operated all those months? Got too many people, let’s add another server?
It’s the same shtick as “beta” sites - it’s short term thinking to save $, and to not have to spend too much on the front-end. I think the Brits call it penny wise, pound foolish.
Prashant
Dec 8, 2005 at 5:29 am
Agreed To your Point but we have cases like riya.com the company is on the vege of being accuired by google when there technology is still in its alpha stage . you see the one more dimension of the scene is that weare living or racing toward a hot market . no body wants to loose out an opprtunity of being accuired and cashing out on the name of building an infrastructure .
so its normal . “when meebo.com can have a team of three guys and still makea dent in internet universe so can everybody else ” this seems to be the mantra these days
Prashant
http://www.knowprashant.blogspot.com
RMX
Dec 8, 2005 at 7:15 pm
I totally disagree. I went to a CIO-forum held by one of our Venture Capital investors where they had each of their portfolio companies describe the biggest mistakes in their company’s histories.
One very common theme was “spending too much time and resources in over-building infrastructure”.
The technology to scale becomes orders of magnitude cheaper and easier every year — and it’s foolhardy to design an architecture with 1999 scaling technology for hypothetical problem that might occur in 2005.
One obvious example is in the area of database scaling. Sure, today you can either get an expensive (Oracle RAC) solution, or cludge something together with a lot of effort on half-assed solutions (PostgreSQL/Slony/PgPool ; MySQL-Cluster ; SQLServer repliction). Or, you can realize that smarter database-developers than you are rapidly advancing each of those technologies, and by the time you need them they’ll be commoditized and stable.
I did a fair amount of work with our CFO in a publicly traded software company’s online-store infrastructure — and risk-benefit analysis almost always ended up favoring less than expected infrastructure.
Jeremy Wright
Dec 8, 2005 at 10:11 pm
RMX: I’m a bit curious as to what part of my post says companies need to spend gobs of money on scaling. As I said, there’s a ladder to high availability. Companies need to choose what step they should be on.
Nik Cubrilovic
Dec 10, 2005 at 11:06 pm
I will tell you the problem, it’s because many web2.0 apps are developed by designers-come-developers who while they can swing some PHP or RubyOnRails do not understand the concept of scale and efficiency. They see it running on their local desktop server with local browser well and think thats that.
Having 37Signals tell them on their blog that uptime is not as important doesn’t help either. These developers need to learn how to benchmark and build distributed and scalable applications, just because it runs fine on your local instance of MySQL server doesn’t mean that server and setup will scale up to 10 servers and 100,000 users.
In addition, I cant believe investors are putting money into these apps - money that is being spent on setting up new servers and new pipes that wouldn’t be required if the app with efficient in the first place. yuk.
Dan Ciruli
Dec 12, 2005 at 4:41 pm
Nik - you hit the nail on the head.