Server Consolidationï¿½Beyond the Hardware - page 2
Consolidation Is a Means to an End
Centralization is an obvious principle of server consolidation. If you have servers in 40 offices, consolidate them at 10 locations. You might have the same number of servers, but the reduction in overhead by cutting sites can be prodigious.
However, centralization is not just a numbers game. There may be good reasons why servers are spread about, at least for some of them. To do the job right, avoid blanket consolidation; do the diligent thing and look at each server site on its own merits. Remember, you are changing more than servers. With consolidation comes changes in network architecture, communications, storage systems, application and data distribution, and personnel, among other things. Even a certain amount of corporate politics may be involved. Sometimes the reasons why a location has its own servers have little or nothing to do with IT.
It's much the same situation for reducing the number of servers. You can use bigger servers, load more work into fewer servers, create virtual servers, and use server blade systems, all approaches that can make server use more efficient. Yet each of these entails changes and complications (i.e., different hardware and software) and therefore expenses.
This is another way of saying that for most server consolidation projects you can draw up a balance sheet: Savings on one side and the costs of change on the other. The results may be surprising.
Often, for simplicity's sake, developers and IT staff like to put one application on one server. This enables people to say things like, "That's the database server." Sometimes there are good reasons for the one application, one server rule. Often, there is no real reason, and several applications could live quite efficiently together. Consequently, consolidating applications, usually along with the data, is (or should be) part of the server consolidation process.
This is not necessarily easy. Reconfiguring applications and data requires great attention to detail. Security, access rights, performance, storage management, and maintenance are just some of the issues that must be resolved. To give you a flavor of the subtleties in server consolidation, consider licensing. Common sense says that by running fewer copies of an application there is licensing money to be saved. However, that depends on how a vendor prices its licenses. With per-seat pricing, costs will not change because the number of users will remain the same. Pricing by size or number of processors may not change much either, since consolidation typically involves fewer but larger servers. Some vendors will bargain. Whatever the situation, this is just one area of consolidation that requires thought and care.
Just as the best advice for buying hardware is usually, "choose the software you need and then pick the hardware to run it," applications and data should usually drive server consolidation. By evaluating what impact consolidation will have on the software, you'll get a better picture of costs and be forced to think about the larger philosophical issues, like decentralization vs. centralization, and PC vs. mainframe.
There are some interesting arguments (most of which are old), but in practice most enterprises live in the zone that centralizes some applications and decentralizes others. The important thing is to look at how the servers are being used on a case-by-case basis before making decisions about centralization and rationalization.