Sizing it like a mainframe Is it better to devote one server to one application? Or buy the biggest server we can afford?

June  1996

Is it cheaper to centralize your applications on the biggest server you can afford, or deploy your applications on a fleet of smaller, cheaper servers? In capital equipment and personnel, the answer's obvious. But when you factor in the opportunity costs, the authors of this column argue it's better to take a more sophisticated look at the spreadsheets. (900 words)

Mail this article to a friend

How many applications can I put on my new mainframe-like server? Is it smarter to devote one server per application? Or, can I shove as many applications on my new server as I had on my mainframe? After all, the marketing folks at Sun, HP, and Digital tout their servers as mainframe replacements, with appealing arguments. Still, is it better to run many applications on a big server or many apps on many smaller, cheaper servers?

Let's first take a look at how we sized a serious BC/S (Before Client/Server) system. Yes, back in the olden days, when all we knew was legacy systems, we used one giant box, usually partitioned into a production and test environment. If we were lucky, we got two boxes: one for production and the other (a warm spare) for development work.

We treated all users equally: "Here's your box. Here's your online window. Here's what time we take the box down for maintenance. Here's how we handle special requests." Yes, we treated them equally -- like dogs. It never occurred to us that we treat them like customers. But what else could we do? We had one box, we were at the mercy of that one box and we shoved everything we could into it. Then we had fun trying to play God between thousands of diverse users in different business units. Asking users from different parts of the company to work together and agree on an issue. They would never agree on anything, so us dictators stepped in and implemented solutions as we saw fit, playing favorites with the group that had the most clout, not to mention cash. Now that's the politically correct thing to do! (Come to think of it, it does sound a little like Washington, D.C.)

No wonder users freed themselves of IT in the 1980s. They wanted to run their business in the manner that best suited their needs, not the way it suited IT.

Our point, and we do have one...
It's cheaper, in capital equipment and personnel costs, to load as many applications as possible on the largest server you can afford. A few organizations have compelling reasons to continue the "one for all and all for one" approach to computing we had no choice but to follow 20 years ago.

Many other organizations, on the other hand, should consider the opposite if for no other reason than flexibility! In IT's new, more service-oriented way of thinking, we think of the customer first, always placing their needs and requirements before ours. (Wow, what a novel idea!)

By placing one application on one server you have much more leeway than before. We can actually treat our users like real live customers by giving each choices. "Hey Mr. or Ms. customer! What time do you want backups performed? What would you like to call your server? Where would you like your server located?" And so on. Every department has different needs and requirements, and decentralized servers offer the best way to meet divergent needs. Yes, this costs more in hardware and support. But we see this as a drop in the bucket compared to the opportunity costs of centralization.

We recently visited a company considering two giant servers to house all new client/server applications. They were so proud of money they would save with this consolidation. We begged to differ, and told them their customers would not walk, but run towards a more flexible solution. We told them this revolt wouldn't occur immediately or explosively, but if IT's hands were tied every time one group of users requested something non-standard (i.e., backups at a different hour), poor IT would be forced to dictate answers. (Hello? Isn't this what IT's trying to live down?)

Some people argue it's harder (and more expensive) to manage more servers. Not always. You need to put processes in place with system management tools to allow a "lights-out" type of environment. Customer productivity and satisfaction come first. System management tools, license fees, data center floor space, and other costs are secondary.

That's why we recommend sizing each significant application, or a department's applications, to an appropriate server. If the proper process is implemented (we'll share that with you in an upcoming column), IT's and the customer's technoids together can decide what server will support the number of users, types and number of transactions, data dependencies, and whether the application is distributed fairly.

As unpopular as all this stuff may sound to all the MIS'ers out there, remember, in the 1990s our customers come first!

Resources

• Other Unix Enterprise
  /sunworldonline/common/swol-backissues-columns.html#unix

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-06-1996/swol-06-unix.html
Last modified: