|
|
|
Building E-Commerce
December 15, 1998 |
|
The Key to Performance: Scalability Okay, youíve tested your network, run countless ìwhat-ifî permutations, worked up some really blood shot eyes and what have you got? Lots of numbers that point to buying a fast server. No kidding! Yes, itís a no-brainer that youíll need fast server hardware, but how fast is the big question. Another major question is how scalable will it need to be? Do you expect user load to increase dramatically in a short time (such as with a highly popular Web storefront grand opening sale)? Or is this a controlled extranet where you know exactly how many people will be using it, both initially and in the future? Scalability is so important because of server cost. The typical answer to a server that canít handle its user load is to add another box or replace the one youíve got. But considering that enterprise-class machines can easily cost $20,000, $50,000 or more, thatís not something you want to have to tell your boss too soon after the project goes live. As you can see, in the real business world, you quickly skip over all the nitty-gritty questions of processor type, RAM and disk size. The scalability question puts you smack in the thick of things, deciding between processing architecture, base operating system, how many servers youíll need, and of what type. At this point, processor speed and RAM size are almost academic questions. It canít hurt to pile them on so buy until the budget weeps. But to answer the scalability questionsÖthatís right, youíre talking to your developers again. At this stage, youíre making a lot of important decisions at once. If the development team is creating a custom application, youíve got the most in terms of architectural flexibility, but that probably wonít happen. Most likely, youíll be faced with a laundry list of software decisions depending on your e-commerce orientation: Store-Front Server
Running your companywide inventory database on the same server machine as your e-commerce server is nuts. If your commerce application wants to tie into an existing workflow system, such as Notes or GroupWise, that is probably running on a separate machine as well. Finally, transaction servers and other necessary middleware may also require dedicated hardware. All of a sudden, your commerce ìserverî has turned into a server farm with the additional complication that some of these boxes will reside beyond the firewall, while others wonít. Weíll explore that consideration a bit further below, but be prepared that there are very few rules to guide you here. These questions are integral to your particular situation and management preference. To be sure, a package like Intershop or Domino.Merchant could become one of the modules in the above list, but youíll still have to tie it into the rest. For example, your existing inventory records are undoubtedly kept in some kind of database. Which one, and can Intershop talk to it? Can it do so efficiently considering WAN bandwidth and high traffic statistics? Here is where many people make the final decision between hosting and running in-house. If your commerce architecture requires fast database access to critical company information like inventory, customer orders and accounting, you might be forced to replicate these databases so that theyíre physically near the commerce server in order to facilitate throughput. Most IT managers do not want to run sensitive information like this off-site. Even if they do, replicating all that information effectively over WAN links can be prohibitively expensive.
|
![]() |
Print This Page E-mail this URL |














