Yet another update at the bottom of the page Updated Many times in the past I have pointed out that most of the new Web 2.0 type start-ups have business plans that only go so far! I am actually glad to see Jeremy Wright take a […]

Yet another update at the bottom of the page

Updated Many times in the past I have pointed out that most of the new Web 2.0 type start-ups have business plans that only go so far! I am actually glad to see Jeremy Wright take a stand on this issue.

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. 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!

I think most start-ups actually don’t take that into account, and pay the price as they grow really big really fast. Early hiccups at TypePad were a case in point. Having had the financial resources, Six Apart has largely overcome those problems. Others, are not thinking along those lines, because we are in the early stages of what might be a bubble, as per Tristan Louis.

During a bubble, attention to boring details like capacity planning, infrastructure management, security, etc… sometimes take a back seat to new feature introduction. Those, however, are a substantial portion of what makes a company survive.

As part of my virtual visit to Les Blogs, I recorded a video which discussed these issues briefly. What worries me the most is “the me-too nature of the companies,” features posing as products and eventually companies and what not. These are signs of what could be excessive froth, as Louis points out. (Steven Borsch has a good post on this as well!)

However, the lack of planning for scale is a clear sign that we are living in a “built to flip” age. No one, is thinking (or planning) about long term business models!

Updated 37signals’ David Heinemeier Hansson offers an alternate point of view, though I suspect he is concluding “Planning and architecting for the future” with 99.999% uptime. He says spending $3 million on servers in Web 1.o was sign of a bubble. I say, not having a long term plan, including a scalable architecture shows, that you are waiting to be bought out. I think the issue is not about blowing millions on servers, which in these days of ultracommoditizaion is difficult, but the issue is – what is your end goal. Ramana Kovi has some thoughts, and I wish he would elaborate further.

Further thoughts from Steven Borsch: “It’s not just servers and bandwidth that are required for scale. It’s dealing with latency over an increasingly fragmented and geographically disbursed base of people consuming web applications.”

More thoughtful entries from Danny Ayers and The Stalwart, on this subject. Danny disagrees and The Stalwart agrees. Danny Says:

Definitions of Web 2.0 vary, but I think two key aspects are The Web as Platform and The Architecture of Participation. For applications that exploit these paradigms to function, there must certainly be some forward-looking design locally, for example in setting up a distributed database on the company’s servers.

But Danny isn’t that what I was saying? People are thinking short term, and thus not taking into account what you so eloquently write.

  1. 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.

  2. I have to disagree. While it’s embarassing for Google to be overwhelmed by Analytics users, I think there is much more risk for small web 2.0 “companies” investing tens of thousands of dollars in infrastructure before figuring out how to turn a profit. That’s more like Bubble 1.0 if anything.

    Then again, I’m not quite sure what the business model behind companies like Del.icio.us really is, other than hoping to be bought before burning through the VC money? That might be the real problem.

  3. slashdoc, i think theissue is pretty clear… if you are going to be doing business, well, then you might as well prepare for the eventual issues of scale and size. the fact is google analytics did not scale, is their bad planning and inexcusable. it is even more critical for start-ups to capture the users who come their way. of course they can stay in controlled beta for as long as they want. sphere is clearly doing that.

  4. Funny time to quote him Om, he just posted on his his company’s site about how b5media was having server uptime issues…

  5. I write OSS server automation software, and I was at the Web 2.0 in hopes of learning how to apply some of these nifty ideas to my own development, and even though I went to learn I ended up feeling a lot more like a vendor. Very few people had any kind of infrastructure or really any idea how to successfully run web services.

    People need to realize that managing and scaling the services are different skills than creating them; either develop both skills or get to hiring, but don’t think that those machines will just run themselves.

  6. Scalability not just about how to add another box to the rack and let DNS round robin scheme take over the scalability. Scalability must be designed into application architecture. If scalability designed correctly into the applications there are hugh financial savings you can reap. Distributed Multi-Database SQL queries “is a must” for any web service application who want to scale.

  7. Jason is right on. There is little reason to spend much energy on “getting scalability right” at the outset. The energy is much better spent on figuring out how to get customers and make them pay. Scalability is fairly easy to provide when necessary. Most startups would kill to have scalability problems!!

  8. i think you folks are missing the point. i think ramana is spot on. it is the right architecture, and ability to think through the what if problem. it is not throwing servers which is an issue, it is an issue of building a scalable architecture. and that a lot of companies are not thinking through.

  9. mike,

    perhaps that proved jeremy’s point. the unexpected happens, and well you need to be prepared for it. don’t you think.


Comments have been disabled for this post