Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

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

  • Operating system
  • Web server software
  • Web creation tool server extensions
    • HTML or Java
  • Commerce server (catalog/order entry/workflow/inventory/shopping cart)
    • Database server
  • 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
    • HTML or Java
  • 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.


Print This Page


e-mail E-mail this URL

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers