One year and three days ago, I wrote an entry entitled “What Do These Services Have in Common?” The services in question were Audioscrobbler, del.icio.us, Flickr, Technorati, Paypal, and Weblogs.com. On a cursory glance, there seems to be little in the way of a common thread. Certainly financing was not the common denominator: some were bootstrapped, some were VC funded, and some were the province of very large commercial entities. Nor is there a great deal of overlap functionally speaking. The linking factor, instead, was scalability – all of the mentioned services had been experiencing significant latency and/or downtime in the weeks prior to December of last year.
Scalability, I concluded then, was of paramount importance in a service driven world.
But what this does indicate, I think, is that in a services world, scalability is at a premium. It’s ironic from where I sit, because I sat through far too many WebLogic/WebSphere bakeoffs (with their respective tens of thousand per CPU licensing deals) in the late 90’s that were intended for deployments of a few thousand seats, while the services above are seeing traffic at least in the millions and are often delivered through quote unquote non-commercial server software.
This line of thinking was hardly original or prescient, of course, given that scalability’s not exactly a new concern. But I do think it’s increasingly driving the success or failure of the next generation of web applications.
Google Blogsearch, I think, might be the best example of this phenomenon at work. After having very little nice to say about it at its release, I’ll confess that it’s the first blog search engine I turn to these days. Why? Because its results are the most relevant? Negative. Because its results are the most timely? Nope. I use it because it’s just so damn fast. Google’s absolutely mastered the fine art of providing absurdly low latency in response times (with a few notable exceptions), and while I might not consciously be aware of it that affects my usage in interesting ways.
When one of the folks on my blogroll that I respect (who should feel welcome to name themself if they so choose) and I got into a debate about the virtues – or lack thereof – of tagging some time ago, the individual mentioned that his web logs saw me travelling into his site via Google rather than del.icio.us, which I’d been defending. I did not then and do not concede now that that invalidates the value of tagging and del.icio.us, but it was an interesting observation nonetheless. I went in via Google not because of search efficiency or any obvious product features, but because of performance. On the one hand it seems slightly absurd; as fast as Google is, we’re literally talking about a difference of seconds. But I’ve accepted as a fact of life for a while – as have a great many web application designers – that such miniscule slices of time can be the difference between a successful and unsucessful application.
So what does this all mean? Simply that scalability is important now, and is likely to become more so. In a critique of FeedLounge’s (disclosure: FL are not RedMonk customers, but I know Alex and Scott personally) approach, Jeremy Wright says the following:
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…
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.
From the FeedLounge side, Scott responds in a post entitled “Scalability is not the only concern,” saying:
Nothing is wrong. It is all choices that you make trying to start a company. Alex and I chose to focus on the user experience instead of scalability, and now we know that we have to scale. I knew going in to this venture that it would be a huge amount of data to move. I do have a great number of years experience making fast things faster in the software world. You mention that is “astounds you” as to what people define as scalable and available. No one has ever used those two words to define FeedLounge. Nor will they, until we have proven that we can. Ask any of our alpha users. They don’t stick around for the availability, they stick around for the features that they have been given. And yes, scalability is a feature, but not one that should be the major focus in incubation.
To me, the question that Jeremy and Scott are debating boils down to two choices:
- Build scalability in from the start
- Focus on features first, scalability second
In a perfect world, I’m with Jeremy. While I’m at none of these guys level technically (particularly these days), I’ve got enough hands on experience to know that it’s very difficult to build in scalability after the fact – just as it is with security. More to the point, in this perfect world, I’m fairly sure Alex and Scott would agree. But it not being a perfect world, with resources being limited, choices have to be made. It’s the old “pick two” quandry. A choice in favor of scalability would likely mean a glacial pace of development for the application, and a far less sophisticated user interface. And further, is it likely that Alex and Scott would ever be able to differentiate on the basis of scalability – can they out scale Google, for example? I think not. Instead, they chose to focus on features at the expense – in certain cases – of scalability. The result is a truly differentiated interface that now has a need to scale better.
In a way, the FeedLounge guys and every other developer wishing to cater to an internet sized audience is damned if they do and damned if they don’t. They can design boring applications that scale, or cool applications that don’t. Doing both simultaneously is exceedingly difficult, even for an organization the size of Google (see Analytics, Google). But as much as I do believe that scalability is important, and potentially a compelling feature in and of itself, if I’m in Alex and Scott’s shoes I probably make the same choice. I’d much rather have too much demand for my application than too little, which is what I think you risk if the primary focus from the outset is on scalability as opposed to compelling features. Longer term, I’d invest heavily to scale, but while in alpha I’m not convinced that’s the way to go.
One interesting question that I’m beginning to ask from all of this: is it even possible for smaller players to scale competitively? As good as the del.icio.us, FeedLounge, et al guys are codewise – and many of them are very, very good – there’s the non-coding aspects of scalability to consider. Networking, hardware, etc require capital investments that can be onerous when bootstrapping, and it’s a simple fact of life that the smaller guys don’t benefit from the economies of scale that say a Google or a Yahoo will. They buy hardware piecemeal, and get run-of-the-mill bandwidth deals, all of which adds up to high entry costs.
But might there be an opportunity there? Might there be an opportunity to aggregate lots of these Web 2.0 (for lack of a better term) services in one place, and offer them an affordable, scalable infrastructure? Maybe. There are lots and lots of hosts out there, but are there any that provide specific expertise in scalability? None that I’m aware of.
Either way, watching the different approaches taken towards better scalability should be interesting. As I write this, Gmail is non-responsive and timing out. Anyone need more proof that scalability is hard?
