The challenge

Assume you are a system or IT architect using IBM's Patterns for e-business to help develop your Web-based application. You're now at the point where you have your runtime pattern, such as the Self-Service::Stand-Alone Single Channel application pattern: Runtime pattern as shown in Figure 1, and perhaps have even selected the necessary product mapping. You want to recommend the appropriate server for each of the nodes in the runtime pattern. How should you proceed?

Recommending servers can be a challenge even for architects with expertise in server technology. Like much of the IT world, hardware is constantly changing and the choices are extensive. Server hardware can be quite complex to choose, order, and configure. And it can be expensive. Under these conditions, it can be hard to make a good choice, never mind the best choice.

Faced with this challenge, architects sometimes fall back on choosing the configuration used previously, opting for the most expensive solution affordable, or delegating the decision to a hardware specialist. Unfortunately, these approaches can backfire. The last configuration used might have been designed to meet totally different requirements. The most expensive solution could be overkill for the requirements. And while having a hardware specialist dedicated to mapping the runtime pattern to the appropriate servers would be ideal, it's not always possible. Still, the customer wants to know what is needed.

Back to top

Meeting the challenge with heuristics

Heuristic problem solving involves creating a set of rules or a procedure to solve problems, especially by experimental and trial-and-error methods. A heuristic approach works well for problems that lack an optimal solution. What, then, would be a heuristic approach for choosing hardware for your nodes?

To simplify your choice, the first rule should be to eliminate all servers that do not meet the requirements and the constraints of the customer and the solution. (Don't worry, you'll still have plenty to choose from.) For example, the customer might have an overriding requirement that the servers come from a specific vendor, such as IBM. In this case, you can eliminate from your list of possibilities all servers from other vendors, even if the non-IBM servers meet other requirements of the customer. The customer might have a requirement that the servers must also run software already in place. If the software was written for a specific operating system (for example, AIX), then this requirement would restrict the choice of servers even further. The customer may have certain skills they want to use, and those skills might be server-specific. And, the customer could have an enterprise architecture that limits your choice to specific platforms.

Once you've accounted for the customer constraints, the requirements of the solution itself might eliminate other servers from the list. Outlined below are some of the specific requirements the servers might have to meet.

Price constraints

Price could eliminate many servers if the customer has a definite budget for hardware and software. Naturally, servers meeting the price limits must meet the other requirements of the solution. You should also consider the total cost of the server when using price to narrow the possibilities. For instance, a rack-mountable server is often more expensive than a tower server, but price tag may not be the only cost. In a co-location environment, the cost of hosting many tower servers could be more expensive than hosting the same number of rack-mounted servers.

Environmental constraints

Environmental constraints might limit the number of servers you can select. The customer's location could be too small for anything other than rack-mounted servers, or it might not be able to host servers with special power requirements. Issues with air conditioning and cable restrictions could rule out some servers. Ask the customer's environmental specialist to describe the constraints, then cross-reference them against the list of possible servers.

Node characteristic heuristic

Look at the role or the characteristics of the node. If the prime responsibility of a node is storage (for example, database node), then servers with more disk bays, faster data channels (such as SSA), and the ability to connect to external storage are a good choice. If the prime responsibility of a node is processing (such as Web application nodes), then servers that can have more RAM, more cache memory, and multiple CPUs are a better choice.

Some nodes will need neither a lot of storage nor a lot of computational power. For these nodes you can choose servers for other reasons, such as price and reliability, rather than for their ability to contain the greatest number of disks or CPUs. Load balancers do not need much storage and might not require much in the way of CPUs, depending on the network traffic.

Nodes can have other roles as well. Some act as a bridge between different networks (for example, Ethernet and token ring). Some connect to many networks, such as many VLANs. Such networking requirements can eliminate certain servers from your list of possibilities.

Capacity heuristic

Consider both the initial and the projected capacity requirements. If the customer is expecting the storage requirements for the server to grow dramatically, then you would choose a server with the capacity to add additional storage rather than one that has limited storage growth. In general, match your node requirements for capacity with the hardware platform's ability to acquire more capacity. Capacity requirements are tied in with scalability requirements.

Scalability heuristic

If scalability is a requirement, you should know whether to scale vertically, by increasing the capacity of the server, or horizontally, by adding more servers and spreading the load over all of them. If the customer expects low or steady growth, such as an Intranet site with well defined non-functional requirements, then scaling vertically has a significant advantage -- fewer servers to buy and manage. What if growth is greater than the customer anticipates? To minimize this risk, consider servers that have the capacity to add extra storage or processing (depending on the node's characteristics).

Though scaling your solution horizontally means more servers to buy and manage, this choice offers advantages. If the customer expects growth rates to be high or unknown, horizontal scaling may be the best bet. It might also be the smartest choice if the customer's Web site experiences bursts of traffic throughout the year. The customer will require some form of load balancing technology (such as WebSphere Edge Server), but once that capability is in place, more servers can be added relatively easily. Horizontal scalability has another benefit: if the load is distributed over many servers and one of them goes down, then the site is still considered up, even if it is responding more slowly.

In the most uncertain situation, you could plan for both horizontal and vertical scaling. While this option may drive up the cost of the solution, it gives the customer more flexibility to scale upwards if necessary.

Reliability heuristic

If the customer is sensitive to system outages, select servers that have more reliability features. Hot-swappable disks, hot-plug power, and hot-plug PCI cards can make the server's mean time to failure (MTTF) longer and the mean time to recovery (MTTR) shorter. Servers with higher MTTF and shorter MTTR are more reliable. Bear in mind that the server operations team must be able to take advantage of these features for them to be effective. If nobody is monitoring the machines regularly, hot-swappable disks will offer no advantage, nor will it help if you can't access replacement parts easily.

In choosing a server for its reliability features, be sure to review the scaling choices. If you provide a solution with redundant servers that fail over, you lessen the need for the redundant servers to provide reliability features.

Performance heuristic

In theory, to determine the best node to meet your performance requirements you would assign a value to the load, such as a "spec" rating. You would then choose a server that meets or exceeds that value. In practice, it is difficult to know what the expected load will be. Often the application hasn't been completed before you have to order hardware. In general, the less you know about the expected load on the system, the more you should to plan to scale horizontally.

Other heuristics

Generally, the chosen servers must not be difficult or impossible for the customer to run and maintain. If the customer doesn't have or desire the skills needed to run and maintain a particular server, or if their operational tools don't support that server, then it will be a poor selection regardless of its other qualities.

"Acquirability" of a server is another consideration. If a server cannot be in place to meet the timeline of the solution, consider choosing a server you can get sooner. The time lapse from when you order a server to when you take possession may be long, depending on demand for the product and how many the vendor has in stock. Confirm availability before placing the order; you might end up choosing another server if you can't track down your first choice.

Finally, consider the popularity of servers. Within any vendor's product line, some servers will be chosen more than others, perhaps because of reliability or price or particular features. Keep popular choices in mind, especially when you have no other criteria for choosing among servers. A server that has been around for a long time, or one that is positioned to be around for a long time, might be a safer choice than one that either has just come on the market or is about to be discontinued. Your server-support specialist can usually provide more information on this subject.

Back to top

An example

In this simple example, you are trying to select a server for the Web application node of your solution. From your initial interviews with the customer you know they have a preference for IBM as the hardware platform. The software to be placed on the server is IBM HTTP Server and WebSphere Application Server. The staff has experience mostly with AIX, and the existing infrastructure is run on RS/6000 and pSeries machines.

In this scenario, you can justify restricting your platform choices to pSeries for the Web application node. Further investigation shows a lot of choices (based on the Spring 2002 catalog). Applying the heuristics, you get:

Any one of the remaining servers could be the best choice for your Web application server node:

Choosing one from the four remaining servers would depend on further investigation of the customer's requirements.

Back to top

Remaining challenges

Despite the heuristics discussed in this article, there are still challenges. Sometimes the customer might poorly define or not understand their non-functional requirements. Occasionally there is no historical data to use before you have to project growth rates or determine past reliability. Often the customer's expectation of future growth may be unknown, unclear, or too optimistic. These possibilities hamper your ability to fine-tune your server selection.

Back to top

Conclusions

Choosing the wrong hardware is an easy thing to do and an expensive mistake to make. If you use heuristics to make your selections, however, your decisions will be defendable, your choice will be good, and the application and the solution will succeed.

A final recommendation: always confirm your choices with a hardware specialist. Explain your solution and your choice of server for each node, so they can validate your reasoning. And, a hardware specialist might suggest a concern you didn't address, or a product you may have overlooked.

Resources

• Learn how to put your enterprise system together on IBM's Patterns for e-business site. One example of an e-business pattern is the Self-Service::Stand-Alone Single Channel application pattern for runtime and corresponding product mapping.
  
  
• I'd recomment this : good site on heuristic problem solving.
  
  
• For more on spec ratings, see spec.org.
  
  

About the author

Bernie Michalik is a senior IT architect who works at the Centre for IBM e-business Innovation, Toronto. Bernie currently is responsible for designing e-business solutions and making sure they perform well. He would like to thank Norbert Hoeller, Leo Marland, Marcelo Martins, Richard McDonald, Rebecca Vogan, and Barbara Wetmore for their gracious support and thoughtful comments. You can contact Bernie at bernie@ca.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The challenge
• Meeting the challenge with heuristics
• An example
• Remaining challenges
• Conclusions
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community