
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
- Operating system
- Web server software
- Web creation tool server extensions
- Commerce server (catalog/order entry/workflow/inventory/shopping cart)
- Commerce server (payment)
- Transaction server
- High security
- Server management suite
- Archiving
- Additional miscellaneous possibilities: user personalization server, discussion group software, push software, etc.
Extranet Server
- Operating system
- Web server software
- Web creation tool server extensions
- Custom or packaged shared application(s). (This represents the application you intend to share with your partners, be it closed buying/selling, advanced electronic payment like EDI or ACH (Automatic Check Handling), information tracking or sharing, supply chain management, etc.)
- Groupware features. (Again a vague term exemplifying the collaborative features of your extranet if any, email, discussion groups, chat, videoconferencing, scheduling, etc.)
- Security (password, encryption, network directory authentication, etc.)
- Server management suite
- Archiving
As you can see, detailed discussions with your development staff is crucial to determining your underlying hardware requirements. Running an enterprise-class e-commerce server out of a single third-party application like Intershop is a pipe dream. Mom-and-pop shops can run an entire store off of one server, but no large company with a sizable inventory is going to be able to mirror this feat.
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.
|