- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
The In and the Out Page 2
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.