Abstracting Computing Resources Into Block

UCS (unified computing systems) came on the IT scene in 2009 as an alternate virtualization strategy and presented a viable option for the nearly 70 percent of data center hardware and software assets that were not yet virtualized. Cisco's UCS approach was a useful virtualization strategy for siloed enterprise applications designed to run on physical servers, but not in traditional virtualized environments. Cisco accepted the fact that these applications required their own hardware and offered a means of creating a resource-sharing "fabric" for hardware-resident assets that was capable of yielding similar resource-sharing benefits to software-based virtualization.

Components in the Cisco UCS framework included fabric interconnect switches that navigated Ethernet and Fibre Channel communications with low latency and data loss, blade and rack-mount servers with fabric extenders and scalability for applications, network adapters, and an overall system manager.

Since Cisco's UCS introduction, major data center vendors like HP have also begun to offer solutions for the resource-sharing of hardware-bound applications, with fabric-generating options that pool resources throughout the data center, whether or not applications are able to hook into standard software-based virtualization. The looming question for IT is, how to best deploy unified computing systems?

The reality of major applications being unable to escape their physical servers is going to continue, and if IT can find a cost-effective means of arranging virtualized resource-sharing even in hardware-bound environments, so much the better. At some point, however, IT has to architect an overall virtualization and resource-sharing strategy, identifying where it will be able to use software-based virtualization, what its preferred virtualization path is going to be, and where it must look for other ways to achieve resource-sharing for hardware-bound applications.

There are two additional decisions concerning this architecture as well: whether a given asset will be inside corporate IT or in an external cloud environment, and how granular IT's knowledge of virtual hardware resource-sharing and management is going to be. Only after these issues are decided can IT inject a UCS or comparable approach for hardware-bound resource sharing.Assuredly, there are going  to be companies that are very comfortable purchasing UCS or comparable "kits" and implementing hardware virtualization on their  own--but there will also be many others that will look for ways to acquire the technology without being required to invest in internal training in order to manage the new deployments to the most intricate degree. This is where concepts like V-blocks (virtual blocks) and HP's VDC (virtual data center) begin to make sense.  

Instead of figuratively dropping a box of nuts, bolts and parts on IT's doorstep for assembly and implementation, a V-block preconfigures a server, storage and switch for provisioning, operation and management in a data center setting. In Cisco's UCS, a V-block requires collaboration with vendors such as EMC, who provides the storage, and VMware, who provides the vehicle of virtualization. The V-block concept is in an evolutionary period, but it offers IT an instant and turnkey virtualization approach for hardware-bound assets with minimum integration work.

The preset V-block package also incorporates standard IT management policies and best practices, eliminating much of the guesswork that normally takes place in proof-of-concept or early stages of implementation. A similar approach is HP's VDC (virtual data center), which consists of a resource pool of integrated servers, storage and network boxes. Either way, IT obtains a level of abstraction above the  bare metal, can easily manage the block of virtualized hardware--and also has the choice of renting blocks of integrated virtualized hardware in the cloud as  well as implementing it on-premises.