X

The new world of big fat Web sites

While small Web sites may look just like their client-server brethren, large ones such as those at Yahoo, Amazon, and Dell, bear little resemblance.

6 min read
"I'm on my way, I'm making it
I've got to make it show, yeah
So much larger than life
I'm going to watch it growing
--Peter Gabriel, Big Time

Every five to ten years, the computing world undergoes a discontinuity that dramatically affects the information technology landscape.

As we shifted from mainframes to minis, minis to PCs, and from PCs to client-server, new leaders were born and old players were put to rest. The friction of the old model and the high-speed growth of the new model opened the door for new leaders and put significant pressure on the leaders of yesterday.

At first, such shifts are subtle and hard to identify. Gradually, however, we notice that incremental dollars and human resources are committed to technologies that are quite different from the status quo. Eventually, these new architectures gain enough momentum to become the new reality.

If you focus on what is different today in terms of computer architecture, the most obvious determinant of change has been the Internet. At first, many experts speculated that the browser would be a major agent of change. However, it is not clear that the browser in and of itself created a technical discontinuity. It is true that this new user interface was obviously affecting the way that applications were designed, so it only followed that this was the beginning of a new reality. But the test of a discontinuity is whether it changes the competitive landscape, and Microsoft smartly dodged the consequences associated with a traditional shift.

The real technical discontinuity created by the Internet may be in its infancy. Consider that the browser is just one side of the Internet phenomenon. Opposite the browser, somewhere out there on the Internet, is a Web site. And while this Web site may represent entities as disparate as search engines, bookstores, news sources, or corporate intranets, the actual computer components that make up those sites are quite similar--or maybe not.

In its simplest form, a Web site has a keen resemblance to the architecture of a typical client-server application. There is usually an HTTP server to serve pages, some form of application layer, and a database. But if the traffic to a Web server grows, this simple site morphs into something truly new. Welcome to the world of "big fat Web servers" (BFWs).

While small Web sites may look just like their client-server brethren, large ones such as those at Yahoo, Amazon, and Dell, bear little resemblance. The computers behind these sites represent more of a "Web farm" than a Web server. Tens and potentially hundreds of servers are linked together in a highly complex and potentially fragile environment. Thousands and thousands of users hit these sites each day, and the dizzying flow of bits from machine to machine is nothing short of remarkable. Engineers and architects struggle each day to make sure that the site is running smoothly, that each server is sharing the appropriate load, and that no thresholds or bottlenecks are impending. This is not your father's personal computer.

There is little doubt that BFWs really do represent something new. Consider these major differences from client-server computing:

  • The typical client-server application is written to be distributed as a packaged application, whereas a Web site really only has one copy that is managed in house.

  • A packaged client-server application is installed at hundreds or even thousands of locations. A Web site is installed at only one place.

  • While a client-server application may run across two or three servers, this is nothing compared with the farm of Web servers at a BFW that can easily run into the hundreds.

  • The BFW may serve thousands or even millions of users, compared with a much more manageable client-server number.

  • The size of the code base and data model at a BFW dwarfs that of a traditional client-server app.

  • In the client-server world, bug fixes and code updates are distributed to files and installed on a periodic or as-needed basis. On the Web, changes can be made continuously.

    The BFW might best be described as a high-end, complex machine fine-tuned specifically for the task at hand. This is not "off-the-shelf" technology. Consider the air-conditioning system for a large skyscraper. The premise behind distributed computing would argue that you could just take hundreds of standard air conditioners built for a single-family home and scatter them around the building. Of course, this is not what happens. Specialists work with the building architects to build high-end systems that are specifically designed for the individual structure. The same is true for large Web sites.

    Perhaps the greatest difference between the BFW and client-server eras is the shifting of design criteria. Client-server was moving into a realm where flexibility and usability were increasingly important. In addition, as client-server technology companies moved downstream to smaller customers, they were forced to think increasingly about systems that were easy to install and easy to use.

    Interestingly, this pushed these companies into the world of single-family-home air conditioners. On the other hand, the BFW has three primary design considerations--speed, speed, and more speed. As the number of users grows on a Web site, the engineers typically adopt a "by-any-means-necessary" attitude. Elegant computing takes a back seat to innovative hacks, and high-end technologies like object brokers become more of a nuisance than a benefit. "Just make it work" becomes the mantra.

    If you think this is a temporary phenomenon, think again. We are in the very early days of BFWs. Corporate and venture capital dollars are pouring into large Web sites. E-commerce companies are popping up like dandelions. Every corporation realizes that they need a major corporate Web presence, not just to share information, but also to communicate with partners and conduct transactions.

    If that were not enough, software applications increasingly will take the form of Internet services, rather than standalone applications. With this model, a small or medium business may "rent" a financial application over the Web, rather than install and implement a software package on its premises. Each time this happens, there is one less standalone server purchased, and more dollars needed for BFWs.

    The BFW movement already has begun to affect the competitive dynamics of the computer business. The stock of Sun Microsystems, once considered a victim of the PC revolution, has soared from 40 to 100 since October. Oracle, a company that had worked hard to position itself for enterprise resource planning applications, must be thankful that its stock is headed in the opposite direction of its ERP peers. While PeopleSoft and SAP trade near 52-week lows, Oracle is bouncing off a 52-week high. Sun servers and Oracle databases are "no-brainer" components when assembling a BFW from scratch.

    Another interesting development is the rise of open-source computing. The operating system Linux and the popular Web server Apache were designed around the theory that all users should have access to their source code. While few information system managers have the desire to dive deep into the source code of SAP financials, engineers assigned to scale a big Web site typically are more than willing to "open the hood" and see if a few personalized tweaks might allow for a few more page views per minute. Believe it or not, while Netscape and Microsoft focus on other things, Apache HTTP server usage is on the rise. BFW designers need customized tools to build information skyscrapers.

    Microsoft is particularly challenged by the rise of the BFW. Its Web server platform, SiteServer, has borrowed a theme from its popular desktop application product, Microsoft Office. Throw everything into a single offering, so that each user will have access to the most features and the latest technologies. The problem is that the BFW builder doesn't want a Swiss Army knife, but rather a simple set of industrial-strength components. In addition, the model that worked against Netscape--throwing more code into the standard offering--is a step in the wrong direction.

    It would be premature to predict the death of distributed computing. But it is important to realize that, in a world of increasing bandwidth, centralized data makes more sense than distributed, Web services make more sense than applications, and investing incremental dollars in BFWs makes more sense than spending on smaller standalone machines.

    We are on the verge of a new discontinuity. New companies will be created, old companies will stumble, and the technical jockeys that can tame the BFWs will be the new heroes of the 21st century.