Unshackling Servers
There's a big pendulum swinging out there in IT land. It drives IT architecture - and constantly forces us to examine and re-examine the wisdom of our decisions. Some people say pendulums are driven by gravity, my experience is that hype also does a good job of driving pendulums.
Some of the IT pendulum swings of the last 20-30 years:
+ IBM Mainframes --> Mini computers
+ Mini computers --> Client / Server
+ Client / Server --> Unix Mainframe
+ Unix Mainframe --> Multi-tier / web based applications
Each one of these swings is driven by excitement around a technology that can cut costs by an order of magnitude. Unfortunately, what typically happens is that a few years later some of the veneer peels off and the dark underbelly of each pendulum swing shows itself. Dark underbellies usually take the form of complexity of operations and high Total Cost of Ownership (TCO).
We are at the apex of the current pendulum swing. Over the last 5 years more and more of IT has shifted to scale-out multi-tier applications running on small individual x86 or SPARC "pizza boxes". The promise was cheap computing for the masses. The reality has been server counts in the 1000's and an infrastructure that's impossible to manage and growth that's out of control.
Applications today are deployed in static configurations. Each tier is provisioned with a number of servers - usually the number needed to meet peak demand. Because peaks occur infrequently, the average utilization of most corporate application servers is under 10% - yet the idle resources cannot be used for anything else - they are shackled by their static configuration.
Customers I meet with tell me that for every production server, they buy 4 additional ones: 1 for development, 1 for testing, 1 for staging, and 1 for Disaster Recovery. This means that for a 20 server application they end up buying, racking, and cabling a total of 100 servers. The additional "overhead servers" are utilized in a very sporadic manner. Most of the time they are sitting idle.
The way to tackle these issues is to slow down server growth, or sprawl. They key is to stop provisioning each application silo for peak usage, and be able to rapidly shift available resources from one silo to another. For example, if you have 20 servers dedicated to QA for application A, you should be able to repurpose them to do QA for application B or C when they are idle. Similarly if you have servers standing idle in the event disaster strikes, wouldn't it be simple to use them to do performance testing on applications when there is no disaster going on?
The key is to create a system where servers can be repurposed on-the-fly. To do this, you have to "unshackle" the servers from their 3 main shackles:
1. Software image installed on them
2. Place in the LAN topology
3. Access to storage
Unshackling these 3 key elements creates an environment where any server can perform any function on any network with any storage at any time. This is where the pendulum is headed. This is what Scalent was built to achieve.
-- Ben Linder, CEO
posted by Scalent Systems at 11:49 AM
<< Home