Scalability Revisited

[Previous] [Next]

You can define scalability in a number of ways. In one sense, scalability is a measure of how many users your application can handle at the same time. In another sense, scalability can be an indicator of whether your application can meet the availability requirements of a mission-critical business application. You can also define scalability as your application's ability to accommodate users who are outside the sanctity of your company's LAN and/or don't have an associated user account in your company's Windows 2000 domain. A Web developer might define scalability as an application's ability to reach every last user on the Internet. You have to decide which aspects of scalability are valuable and which should be requirements for your application.

How many users do you need to accommodate today? How many users do you expect your application to serve in the future? On average, how often does each user submit a request to the server? By answering these questions, you should be able to calculate roughly how much traffic you need to handle. If you need to handle hundreds or thousands of requests per second, you should be prepared to design an application that can accommodate this level of traffic.

You must also consider where your users are located. Can your application scale to accommodate users who are outside a closely administered LAN? Perhaps your application will be used by employees who are telecommuting via ISDN, DSL or cable modem. Maybe you need to accommodate an employee who on the Internet via an MSN dial-up connection in a hotel room on the other side of the planet. Perhaps your application will need to accommodate users from any location on the Internet.

Can your application reach users running a variety of different browsers and operating systems? Is your application flexible and reliable enough to accommodate a scenario in which your company's system administrator can't possibly configure the computers of your users? Scaling to reach every user on the Internet definitely involves tradeoffs in terms of what technologies you can use on client-side computers.

The point I'm trying to make is that the "ultimate" scalable application would be able to run transactions and retrieve data for millions of Internet users concurrently, and each user would be able run any operating system and require no customized configuration. That's a pretty tall order. However, the requirements for scaling your applications typically won't be this high. You should know the associated costs of the various aspects of scalability, and you can avoid paying for things you don't really need. That's why it's critical to determine your exact requirements for scalability as early in the design phase as possible.

Before you design a distributed application, you must decide how clients will communicate with your servers. Which underlying protocol will allow clients to submit their requests to the server—DCOM, HTTP or MSMQ? Your choice will have a profound effect on your application's scalability.

In this book, we've examined the inner workings of DCOM, HTTP, and MSMQ. As you know, these protocols are the building blocks of a distributed application. Each protocol has its advantages and drawbacks. Let's take a look at how each of these protocols fits into the big picture of large-scale application design.

The Original Vision of COM

In the 1990s, COM became an important technology for building component-based applications. It was adopted by many product groups within Microsoft, so many Windows developers had no choice but to follow suit. As a result, just about every Windows developer now uses COM in one form or another.

Many developers, myself included, thought that DCOM was on its way to becoming one of the industry's dominant application protocols for client-to-server communication. We shared a vision that large-scale applications could be built using a physical model like the one shown in Figure 12-1.

Figure 12-1. An application that uses DCOM for client-to-server communication has trouble scaling beyond the LAN. DCOM also makes it hard or impossible to scale an application to accommodate thousands of users.

COM offers location transparency by providing a transparent wire protocol (DCOM). As you know, this makes it relatively painless to establish a remote connection between a client computer and a server computer. In this sense, COM provides an inexpensive entry point into the world of distributed computing. This has led many people to conclude that DCOM is an obvious choice for building multitier applications.

As the 1990s came to a close, it became apparent that DCOM has too many limitations related to scaling a large application. For example, DCOM is far less able than HTTP to take advantage of load balancing products such as Microsoft's NLB and Cisco's LocalDirector. DCOM's connection-oriented nature makes it impossible to take advantage of request-based load balancing, thus limiting the number of concurrent users and preventing an application from achieving the highest possible levels of fault tolerance and availability.

The list of DCOM's shortcomings keeps growing. DCOM doesn't work well across firewalls, and its security model doesn't scale well on public networks such as the Internet. DCOM also requires a version of Windows on every client computer and a significant amount of custom configuration and administration on each client computer.

All these problems with DCOM boil down to one important fact: while DCOM works well for a small to medium-sized group of users in a LAN environment, it becomes more problematic and unreliable as you add more clients and/or move them farther from the server.

At this point, I'm afraid I might be depressing you. After all, throughout this book I've endorsed COM as an essential technology and I've forced you to look at hundreds of pages of COM's low-level details. I'm not suddenly telling you not to use COM, but we need to take a step back and examine things on a higher level.

COM and COM+ provide four important things:

• The glue that allows you to assemble applications using components written in the language(s) of your choice.
• A value-added runtime environment that exposes system services through the use of context and attribute-based programming.
• The means with which to call between processes running on the same computer, such as when an ASP page executes a method on an object running in a COM+ server application.
• A wire protocol (DCOM) that allows you to communicate across computer boundaries.

You might decide that DCOM isn't usable in your application, but the first three aspects of COM and COM+ will still be valuable to you.