I think one of the most stubborn myths of our times is that it’s “easy” to build a web company because servers, bandwidth, etc. are so cheap. I’m not so sure. Yes, it is “easy” — until you need to scale. Scaling is still hard.
I was reminded of this when I read Mena Trott’s post about Typepad’s recent problems, in which Mena writes about the pain they are going through and what they are buying to fix it:
Over the next week you should see significant improvement in performance as we get extra equipment on line and finish moving data off of heavily loaded servers. By the end of the move we will have five times the bandwidth we had before, as well as hundreds of thousands of dollars of new equipment, and room and power to add more equipment as needed.
Scaling is hard — and often expensive. Cheaper than it used to be, but still not cheap.
This also reminded me of Dave Winer’s sale of weblogs.com to Verisign, in which he wrote:
The bootstrap of weblogs.com is something a bigco should not attempt, it’s hard to make it go, and most bootstraps don’t, and it requires trust, something an individual is more likely able to inspire than a big company. On the other hand, running a serivce that other bigco’s depend on (like Google, and Microsoft, to name two) is not something a person like myself should attempt [stuff snipped here]. . . I’m good at digging holes, I have to pass off to others to make the trains run on time when the service grows as big as weblogs.com has.
Judging from this post, Dave understood the difficulty of scaling and smartly chose to sell weblogs.com before he hit the wall with it.
I think scaling issues are going to separate the men from the boys in the coming months. I think that many of the Web 2.0 “Flickr-wannabe, flip-it-quick” companies (as Russ describes them quite well and with good humor) have no idea how to scale (PHP and MySQL are fast. . . let’s just write the code!) and when they get popular enough to warrant interest from larger companies, they may be on the verge of being crushed (or already crushed) from a scaling standpoint. The ones who figure out how to scale on the backend while they are blinding the world with AJAX wizardry on the frontend will do very well, I think.
Bonus link: Flickr ops main man John Allspaw recently posted his Hardware Layouts for LAMP Installations presentation from the PHP/Zend conference. Following some of John’s hard-earned advice is a good way to get those scaling issues in order (and it’s still not easy).
Chad Dickerson's blog 
Excellent! I have been tracking these issues of late (well the last year) as I went though similar issues about 5 to 6 years ago and it is something at the forefront again with me.
I have talked with many developers about Ruby on Rails implementations in large use communities. The have been seeing it not scale too easily and have stayed with/gone to Python and other development tools, which do have the availability to scale. It seems Rails is a great prototype tool, but for intensive use web application it is not a decent solution. I am looking for more understanding on this (not looking at Ruby or Rails for what I am not working on) as I am just curious, is it the ColdFusion of the day?
A lot of the scaling issues that people are seeing are not solely due to the language or scripting framework that the application is built in.
It’s so much more than that. At friendster, we did a LOT of things for scaling. And only one of them was using PHP, migrating from Java. Of course people came out of the woodwork to debate the two and their scalability.
Of course, while that was happening, we completely re-architected the database layout, got a boatload of new equipment, moved datacenters, and build a good deal of custom code that actually had something to do with scaling.
I think that sometimes there’s a confusion between programming language scalability, which doesn’t really have a lot to do with how the application performs under increasing load, and the application’s supporting infrastructure, which does.