This chapter is from the book
This chapter is from the book
This chapter is from the book
Common Site Designs
Now that we've covered all the theory behind site design, you're probably wondering how to apply it to your business situation. The best way for us to help you do that is to show you some examples based on common business requirements. So, in the next few sections, we'll show you some common site designs. We'll focus on three main design categories:
Maintainability, which is intended to produce sites that are easy to manage and maintain throughout their life.
Scalability, which is intended to produce sites that can be easily expanded to handle an ever-increasing number of users.
Availability, which is intended to produce sites that can survive hardware and software failures and continue functioning normally from the user's perspective.
Our discussion of design theory in the first part of this chapter centered around three primary design components:
Web pages, which you create using ASP or ASP.NET.
The site itself, which consists of your Web servers and various pieces of server software.
The network that supports your site, including your Internet connections.
For each design category, we'll give you examples of specific Web page, site, and network design that meet various levels of maintainability, scalability, and availability.
NOTE
You may be wondering whether all of this design effort is necessary for an intranet e-commerce site, such as an internal e-procurement site, a company store for employees, and so forth. Absolutely!
What often differs between Internet e-commerce sites and their intranet cousins is scale. Certainly, intranet sites often have fewer users and you can more easily predict your maxmum user load because the site will be accessible only to employees. Scalability, then, becomes a less complex problem. Availability is often less crucial, too, because employees may be able to live without their company store for a while if a server fails.
None of these issues change your design process, though; they simply change the decisions you make during that process. Always be cautious when "shortchanging" an intranet site because it's "only for employees," though. Intranet sites have a way of becoming mission-critical components of a company, demanding the same levels of availability, scalability, security, and maintainability of an Internet-based site.
Designing for Maintainability
The key to maintainability is always asking yourself, "How easy will this be for someone else to understand and change in the future?" Even if you're the one who'll be maintaining things in the future, it's all too easy to forget why things were set up in a specific way six months or a year afterward.
The biggest key to ensuring maintainability is documentation. Document everything. Keep a master site document that describes the purpose of every Web page, every server, every network connection, and every configuration setting. Your documentation should be thorough enough to allow someone else to rebuild the site from scratch in case of a complete disaster (such as a meteor striking your data center). Aside from documentation, there are some other steps you can take to improve the maintainability of your Web pages, networks, and overall Web site.
Maintainable Web Pages
ASP pages can be made more maintainable by modularizing them. For example, almost every ASP page in your site will have to establish an ADO connection to your back-end database. You might program a few lines of code to do that within each page, as shown in Listing 3.1.
Listing 3.1 Creating an ADO Connection in ASP
<%
Dim oConn
Set oConn = CreateObject("ADODB.Connection")
oConn.Open "MyDataSource"
'rest of ASP page goes here
%>
There's nothing wrong with that technique, unless something changes in the future. For example, suppose you move to a new, more powerful SQL Server and change the data source name that the server uses. You would have to change every single ASP page in your site with the new, updated data source name—a maintenance nightmare.
ASP allows you to modularize your code through the use of server-side includes. Listing 3.2 shows a small ASP page that simply opens the ADO connection, and nothing else. You might save that file as i_ado.asp (the "I" prefix indicates that the page isn't a standalone page, but is instead intended for inclusion within other pages).
Listing 3.2 Writing an Include File
<%
Dim oConn
Set oConn = CreateObject("ADODB.Connection")
oConn.Open "MyDataSource"
%>
Listing 3.3 shows your original ASP page from Listing 3.1, modified to take advantage of the new include file.
Listing 3.3 Modified Asp Page That Includes i_ado.asp
<!--#include file="i_ado.asp"--> <% 'rest of ASP page goes here %>
Including files lets you make changes in only one place. For example, if you need to change your data source name, you just change i_ado.asp. The change then immediately takes effect in all pages that include i_ado.asp.
TIP
Anytime you'll use a given piece of code more than a couple of times, put it into an include file.
ASP.NET is based upon the .NET Framework, so it offers even more opportunities for modularization. ASP.NET pages are object oriented, offering the highest level of modularization and maintainability. You can create your own classes to perform specific functions—formatting product ID numbers, for example—and use those classes within ASP.NET pages. Any changes to the class will automatically be inherited by any classes based upon that class, and by any pages that use the class.
Maintainable Web Sites
Creating a Web site that's easy to maintain requires careful planning. If your site's servers are located in your office, or are otherwise attached to your private company network, maintenance is usually easy. You simply access the servers using the same network adapter that the servers use to communicate with back-end servers such as their database servers.
Maintaining servers that are located at a remote hosting facility can be more difficult. As we discussed in Chapter 2, you will probably have to go through a firewall to manage your servers, making a VPN an ideal solution. VPNs can also provide a solution for maintaining remote back-end servers, which aren't normally accessible across the Internet. Figure 3.3 shows a sample network diagram that includes a VPN server. Note that your administrative workstation is located at your office and creates a VPN connection to the remote VPN server. The VPN server then provides access to the remote back-end network, allowing you to easily administer all of your servers, despite the hosting facility's firewall (which must be configured to permit the VPN traffic).
){kind=link}
Figure 3.3 Using a VPN for remote maintenance makes it easier to configure firewalls, because only the VPN ports need to be opened.
Maintainable Networks
The key to a maintainable network, as we've said before, is documentation, documentation, documentation. You should put together a sheet or two of documentation for each server in your Web site, such as the one shown in Figure 3.4.
){kind=link}
Other network devices on your network need documentation, too, such as the sample router documentation shown in Figure 3.5.
){kind=link}
Figure 3.4 Server documentation makes long-term maintenance easier by helping you remember why you configured things the way you did.
Carefully documenting every piece of information about your network will help both you and future administrators when changes are required, or when problems arise. You should also have any necessary network diagrams that show how your site's network fits together, such as the sample diagram shown in Figure 3.6.
){kind=link}
Designing for Scalability
To ensure scalability, always ask yourself, "How easy will it be to expand this to support additional users?" The easier the answer seems, the more scalable your site is. Another good question is "How can we configure/program/design this to support the maximum number of users?" Don't overlook answers that seem to offer only minor improvements. For example, you might discover a programming trick that will allow a Web server to support a dozen extra users. That small of a number might not seem worth your while, but remember that your Web site may contain dozens of servers one day. If your programming trick can help each server support an additional dozen users, that's more than a hundred additional users for the whole site.
Figure 3.5 Router documentation is especially important, as it serves as the basis for your overall network documentation.
Scalable Web Pages
Creating scalable Web pages means avoiding technologies that impair scalability. In an ASP-based Web site, which is what you may be creating with Commerce Server 2002, the biggest obstacle to scalability is ASP session variables. Don't use them, and you'll definitely improve your site's scalability.
A more subtle way of improving scalability is to take every opportunity to improve performance, both on the Web servers and on their supporting database servers. Here are some tips:
When retrieving data from a SQL Server, execute a stored procedure that returns the data rather than executing a regular query. SQL Server executes stored procedures much more quickly than regular queries. In fact, everything you do to the SQL Server should be done through a stored procedure whenever possible.
Write stored procedures to return only the data you absolutely need. For example, if you frequently need to query product inventory levels, write a stored procedure that returns only the inventory number. If you sometimes need to query the inventory and the description, write a separate stored procedure for use in those circumstances. It won't hurt SQL Server to have a lot of stored procedures available, and minimizing the data a stored procedure returns will definitely improve performance.
Figure 3.6 Network diagrams should show relevant network components, such as servers, an estimate of client concentration, routers, and so forth.
Keep your servers up to date with the latest versions of ADO and other core object libraries. Microsoft improves the performance of these libraries with each new version, and even if the improvements are slight, the cumulative effect will be noticeable.
-
Use the absolute minimum amount of script code and database access necessary. Whenever possible, let IIS serve up static HTML pages instead of ASP pages, because IIS operates at peak efficiency when it doesn't have to deal with program code in your Web pages.
Product pages are an excellent example of that last tip. Some sites are designed with a single product detail page, named something like product.asp. The page accepts a parameter or two to indicate the product that the user is trying to view, and uses ASP code to dynamically query the appropriate product's information from the database and display the information for the user. Although that technique is an elegant solution, it requires IIS to do an incredible amount of work for one of your site's most common tasks.
Purely static product detail pages aren't usually feasible, because product information changes too frequently. Prices change, product descriptions change, and so forth. If you used static pages in your site, you and your staff would spend an enormous amount of time updating static HTML pages to match the information in Commerce Server's product catalog database.
The best solution lies in between totally dynamic and totally static pages. For example, you might write a Visual Basic application that runs automatically each evening. The application queries the Commerce Server database and creates static HTML pages for each product in the catalog. This technique gives you the high performance of static HTML pages, along with the benefits of dynamic pages that query product information from the database.
If your product information changes more than once a day, you might write a SQL Server trigger that generates a new static product detail page whenever a product's information changes. That way, your site will always contain the most recent product information in easily served static HTML pages.
Scalable Web Sites
If you've taken the time to create scalable Web pages, your overall site will be more scalable as a result. If you're not using ASP session variables, for example, adding capacity to your site can be as easy as adding another Web server to take up some of the user load.
In fact, your Web servers represent the most scalable portion of your Web site, because you can usually add another server to increase your site's capacity. Eventually, however, you'll add more Web servers than your back-end database servers can keep up with. The back-end portion of your site is usually the least scalable because everything comes down to a few SQL Server databases.
If you've already distributed the Commerce Server databases to the greatest degree possible, you'll have to start taking more complicated steps to add back-end capacity to your site. The most common means of adding back-end capacity is to split the site, as shown in Figure 3.7.
){kind=link}
In this example, you create two identical, independent Web sites, each with their own Web farm and back-end database servers. A third set of database servers holds your master databases. SQL Server replication is used to replicate catalog and other changes from the master servers to the site's servers, and to replicate order information from the site's servers to the master servers. Although expensive and complex, this technique offers potentially unlimited scalability, because you can always create a new, independent Web site whenever you've reached the scalability limits of an existing site.
Figure 3.7 Splitting a Web site can also allow you to distribute your site's servers geographically, if desired.
Scalable Networks
Creating scalable networks is probably one of the most difficult tasks an e-commerce site architect must face. Although local area networks (LANs) are easily scaled by using switches and routers to break the network into smaller, independent networks, wide area network (WAN) connections are much more difficult to scale.
The most common (and affordable) form of WAN connectivity in the USA are T1 lines, which provide a bandwidth of about 1.5Mbps. That's about one-sixth the speed of a very slow Ethernet LAN, which runs at 10Mbps. Hosting facilities may provide higher-bandwidth connections, which you'll share with the facility's other customers.
If you're not using a hosting facility, and your Internet connection is no longer big enough, it can take a month or more to add another (or a larger) line to double your capacity. If you are using a hosting facility, you may be able to purchase additional bandwidth from the facility, up to the maximum size of their WAN connection. If the facility needs to expand their WAN connection to meet your needs, you should probably start shopping for a new facility, because it will ultimately cost less.
In the end, even the most expensive WAN connectivity available will provide significantly less bandwidth than even a cheap LAN. So, because WAN connections are inherently the least scalable component of your Web site, design your site to be efficient—even miserly—in the use of WAN bandwidth. Here are some tips:
Minimize the use of bandwidth-consuming graphics, sound, and video. If your site needs to make heavy use of these multimedia elements, consider outsourcing their delivery. Outsourcing companies such as Akamai.com maintain high-bandwidth Internet connections, and allow your Web pages to pull your graphics, sound, and video from the outsourcing company's network, rather than your own.
Schedule bandwidth-intensive tasks such as mass email campaigns for hours when your bandwidth isn't being heavily utilized by customers. For example, a retail clothing site such as HipThreads might see most of their customers in the evening hours, leaving the daytime open for other tasks.
-
Look into cache-encoding. Cache-encoding helps your customers' computers (and their ISPs' computers) determine which portions of your Web site don't change very often. By cache-encoding relatively static pages, you help those remote computers save a copy of the page, so that it doesn't have to be pulled from your Web site each time a customer requests it. Cache-encoding can be especially useful when a lot of your customers are from America Online (AOL), because AOL aggressively caches pages to help manage their own bandwidth issues. You can learn more about cache-encoding in Microsoft's ASP documentation.
Designing for Availability
The question to ask yourself for availability is, "Is there any one bit that will prevent the site from functioning normally if that bit fails?" Eliminating any single points of failure—pieces of the site that don't have any redundancy—will ensure that your site continues to operate even when hardware or software fails.
There's very little black and white when designing for availability. Instead, availability is a matter of degrees. For example, you can purchase uninterruptible power supplies (UPSs) for your computers at a fairly low price. Doing so will give you a few minutes' extra power if the electrical utility power fails. For more money, you could purchase larger UPS batteries, which will allow your site to run for additional minutes without utility power. For even more money, you could install a diesel backup generator that will provide hours of operation in the complete absence of utility power. The level of availability you design for depends on your business needs (how much money will you lose if your site is down for a few minutes?), your environment (how often does the power go out in your area, and what's the average duration of each outage?), and your budget (how much availability can you afford to buy?). Another example might be planning for a database failure (which will eventually occur). You could just use a single database server, and hope nothing goes wrong. You could build a clustered server, which will help protect against server hardware failures, but not against database corruption. You could use separate database servers that replicate data to one another, which will protect against a hardware failure and database corruption. Each alternative costs a little more, requires a little more administrative effort, and gives you a little more peace of mind. You just have to decide how much peace of mind you can afford.
Of course, availability involves more than just planning for power outages. In the next two sections, we'll cover various levels of availability for Web sites and for the networks that support those sites.
Available Web Sites
For Web servers, scalability and availability are almost the same thing. For example, if you have a dozen Web servers providing the same content, one of them can probably fail without severely impacting your site's overall ability to serve customers. For that reason, Web server computers are often smaller machines without the highly redundant hardware of more powerful servers.
Back-end servers, such as your database servers, are much more likely to be impacted by a hardware failure. Although you can (and should) purchase servers with redundant cooling fans, power supplies, and so forth, nothing can protect you from a total hardware failure (such as a processor or memory failure). What you need is the whole-server redundancy provided by a cluster. Clusters contain at least two servers capable of performing the same job. If one fails, the other simply takes over. Both SQL Server Enterprise Edition and Commerce Server Enterprise Edition are cluster compatible.
For more information on using clustering to build highly available sites, see "Recommendations for a Highly Available E-Commerce Site."
Available Networks
Network redundancy equals network availability. Here are some tips for creating a highly available network:
Configure servers with redundant network cards. High-end network cards can work in tandem, with one card mimicking the other's identity in the event of a failure.
Connect servers to two separate switches. In the event that one switch fails, it'll have the same effect as a network card failure. The server's redundant card can continue operating through the functioning switch. You'll need to use high-end switches that can be configured in redundant pairs, such as those available from Foundry Networks.
Use redundant routers on redundant Internet connections. If one connection fails, that router can route its traffic through the router connected to the remaining Internet connection. Routers should work in tandem with your switches, so that if one router fails, the switches will direct traffic to the surviving router.
-
Make sure every component on your network supports some form of network management protocol, such as the Simple Network Management Protocol (SNMP), and use a management console that checks the components for proper operation. That way, if a failure occurs, you'll be notified immediately and be able to take action.