A few months back, there was a meme going around talking about how cheap it was to build a web based application/service/company compared to our recent past. While this may be the case in various instances, the scalability needs of today’s web applications far outreach the needs of yesterday’s tools.
Some quotes worth including:
I guess the low-down is that if youâ€™re a company that provides a service, you either need to be ready to scale or you need to be ready to limit access to your service. Users shouldnâ€™t suffer. But if they do, at least communicate. Thankfully, thatâ€™s something FeedLounge does really, really, really well.
This is really the only option for a bootstrapped operation like FeedLounge. We have to grow our infrastructure organically so, as much as we’d like to, we can’t just throw the doors open. What we can do is be transparent and honest about this situation.
The design of the application allows scalability/availability to be added as time and money allow.
I don’t know that we’d said this before, I’m glad Scott mentioned it. Incremental scalability is basically what we’re planning for.
However, the reality is that if the â€œWeb 2.0 modelâ€? is to build services that users want, but then canâ€™t use because they were never designed properly, then thatâ€™s something that needs to be addressed.
The real issue here is that scalability costs money and big scalability costs big money. Even if an application is built so that it can scale (the FeedLounge architecture supports distribution in all areas), you need a lot of hardware and bandwidth to take advantage of that architecture. The years and millions of dollars that Yahoo! and Google have invested in scalability is their biggest advantage.
I understand that it is a challenge to scale. But the best way to scale is to always ask yourself the following question:
I am about to make a change(s) to my pages/server/network. When traffic suddenly doubles/triples/quadruples, what will the impact of this change be on the performance of my application?
If that fundamental question is asked at every step of the process as an application or service is built out and grown, then scaling the application is an organic process.
I’d say this question needs to be centered around features. We’ve held off including some features in FeedLounge that we plan to in the future, simply because they are resource intensive and, as a company, are somewhat resource constrained (and operating quite heavily in the red).
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.
The other thing to mention here is that scalability requires real life testing. To build for scalability first, you need to have suitable hardware, etc. in place to test with. You run into the situation where the “scalable platform” is a product in and of itself. Building a scalable platform can take years, and it’s hard to get back to building the application that runs on the platform.
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.
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.
As usual, Steve’s article is insightful and well written – go read it.
However Iâ€™m running into these scenarios too often where companies suddenly canâ€™t meet the demands of their users and, as a user, it pisses me off. Because, really, thereâ€™s no reason for user performance to EVER suffer if all users of your service need to sign up in order to use it, unless you have rogue users. As long as you can turn off user sign up, isnâ€™t it best in the long run for your current users to be happy while you fix issues?
The emphasis above is mine – and yes, that is exactly how we look at it. That is why we are still in a closed alpha right now. There may be times during the beta that we have to turn off registration while we bring up more hardware, but we know that having
UPDATE: another post from Jeremy.
This post is part of the project: FeedLounge. View the project timeline for more context on this post.