Do you have a .plan for your .com? You should.

Remember when users had a .plan? When the screech of a modem was the most annoying sound you'd hear while online? When multiplayer interaction meant joining a MUD, MOO, or MUSH? When FTP was the only way to transfer files, and if you wanted to chat you'd hop on #IRC? When discussions were for newsgroups, if you ignored alt.binaries.pictures.anything, which was certainly not for discussions.

It wasn't necessarily the proliferation of broadband that caused a massive leap in users on the Internet. Just as there are plenty of highways that lead to the upper peninsula (UP) of Michigan there have long been broadband options for users, it was more a case that the masses had no reason to visit - just like "da UP".

We keep hearing that Web 2.0 has been adopted quickly by "the masses." We understand "the masses" to be everyday folks rather than the early adopters who, by self admission, were mostly geeks and technology-minded folks. People who didn't mind switching between protocols. They had a .plan and understood that on the Internet there was a place for everything and everything in its place. The Web was for reading, IRC for chatting, and FTP servers for exchanging files. That didn't work for "the masses." The relationship between IP addresses and domain names was too complicated for the masses so expecting them to FTP or IRC with alacrity was a stretch.

But along came Web 2.0 with its new-fangled widgets and gadgets and its "communities". The place for everything suddenly became a web site and only a web site. Newsgroups were traded in for "forums" and IM almost completely replaced #IRC. MMORPGs did replace MUDs and MOOs and the masses flocked to social networking sites. Broadband use exploded, and in the big scheme of things it's just as believable to say that Web 2.0 drove the adoption of broadband, not the other way around.

So the funny thing here is that the Web 2.0 of the masses really isn't that much different than Web 1.0. No matter how it's generated - PHP, ASP, ASP.NET, Ruby - it's still primarily good old HTML and Javascript under the hood. Sure, it looks nicer, but putting lipstick on a pig doesn't change the fact that it's still a pig (until it becomes bacon, of course. Mmmm. Bacon.)

Yes, there's video and audio now, but it's embedded in ...wait for it ... yup. HTML. And it's all primarily delivered via...wait for it...wait for it...yup. HTTP. It's also still consumed by people. But like the HTML and Javascript that make up the sites, there's more of them as well.

More Problems, too

In a nutshell, Web 2.0 gives us more of everything we used to have. Like a facelift, Web 2.0 doesn't change what's under the hood, it just gives the overall package a much nicer look and feel. And the new package is more attractive to a whole lot larger audience.

Web 2.0 really isn't that different than Web 1.0 from an architectural standpoint with the exception that there's a lot more content and a lot more users viewing it. That also means there's a lot more opportunities for things to go wrong - timeouts, server errors, database connections failing. In order to scale up a Web 2.0 website you have to have a plan sooner, rather than later - before the users flock to your site and bring it crashing to its proverbial knees.

The architecture of a Web 2.0 site poised on the edge of Internet fame - or infamy, as the case may be - needs to be prepared for the sudden barrage of users that are sure to flock to the site once word gets around. It's no longer enough to just react to a growing user base, it's necessary to proactively prepare for the situation.

Application delivery controllers, application acceleration, application security. All are components of a well-architected infrastructure that is prepared for the (hopefully) inevitable explosion of your Web 2.0 site. An application delivery controller ensures availability and reliability through load balancing, failover, and application monitoring. Application acceleration products ensure your site is fast through optimization and acceleration techniques such as compression, caching, and application specific optimizations. Application security protects your site from both inadvertent and intentional security breaches by firewalling at the application layer; inspecting requests and responses and ensuring that only valid traffic passes in - and out - of your data center.

You really can't afford to try to scale up just as your site is reaching critical mass because once denied, these users rarely return - they're already off discovering some other newly launched Web 2.0 site. A site that probably protected their investment by architecting a highly scalable and reliable infrastructure.

You definitely need a .plan to scale your .com, and you need it now - not later.

For information on how F5 helps ensure your Web 2.0 site is fast, secure, and always available, check out F5 BIG-IP Local Traffic Manager and its product modules.

Imbibing: Water