A vendor coalition consisting of VMware, Cisco and EMC launches an IT-as-a-service product with a compelling support structure. Where some see a marketing ploy, others see an opportunity to better leverage the infrastructure. Which side is right?
Last week, I had the good fortune to be invited to attend Tech Field Day in Boston where a group of fifteen Tech Field Day delegates descended upon the likes of Data Robotics, vKernel, EMC, HP, and Cisco in order to be dazzled by the new storage and virtualization efforts being undertaken by these companies. In the last session of the event, the group of delegates met with representatives from Cisco and EMC (one of EMC's representatives was "the other Scott Lowe" while I was simply a participant).
These engineers were a part of the Virtual Computing Environment (VCE) program, a joint venture between VMware, Cisco, and EMC. The main product being sold and supported from this partnership is called a Vblock infrastructure package, or simply Vblock. In this article, I'm not going too deeply into technical particulars about Vblock except to say that Vblocks are intended to truly enable organizations to purchase, deploy, and support IT-as-a-service efforts without having to expend major resources tuning the environment. Further, for organizations that purchase a support Vblock from the coalition, the entire infrastructure -- from the EMC-based storage to the Cisco-based servers and networking gear to the VMware software -- is supported through a single point of contact. It doesn't matter which component needs support, organizations have just a single phone number to call. This greatly simplifies the support of the environment.
The vendors in the coalition currently sell Vblocks in two flavors: Vblock 1 and Vblock 2. Each Vblock product includes very strict and specific hardware and software with some, but not a ton, of flexibility to configure some of the performance levers, such as number of CPU cores, amount of RAM, amount of storage capacity, and amount of storage I/O capability. Although these levers are somewhat configurable, each individual component must stay within specific parameters in order to be supported as a Vblock. Organizations are free to configure the full infrastructure as much as they want, but failure to adhere to the parameters put in place by the vendors results in the solution being sold on a more traditional basis rather than as a single unit of infrastructure.
The Vblock draw: By staying within the established hardware guidelines, the coalition vendors guarantee that the performance of the solution will stay in an expected range.
This is where I'm going to stop talking about Vblocks -- I'll discuss the underlying technology of Vblocks at length in another posting -- and start talking about the business benefits and drawbacks of this type of infrastructure purchase.
During the follow-up conversation that took place after the Vblock discussion, some participants told the EMC presenters that the Vblock was nothing more than a marketing ploy to increase sales and that the only people who would purchase such a solution would be CIOs who didn't understand the underlying technology and just wanted a vendor promise that performance would stay in a particular range. The Vblock solution doesn't really lend itself to heavy customization, they argued, so it was impossible to finely tune the environment to make sure that every IOPS was eked out and that every RAM byte was used to its fullest potential.
To be fair, these comments were made by people with a laser focus on storage and virtualization. They're paid to implement and support solutions that perform at optimal levels without any waste that drives up costs.
I spoke up with a different perspective: That of the aforementioned CIO who just wanted a solution that works and that's easily supported. I glommed on to the Vblock concept. My main complaint with Vblocks 1 and 2 is that they're sized very, very large -- as in thousands of virtual machines. It's obvious that this initial foray is intended to support very large organizations and service providers. I argued that smaller Vblocks would be a perfect fit for smaller environments where IT staff is very limited or in which IT staff members already have to wear many hats. By providing the ability to purchase a well-supported "block" of infrastructure, IT staff in these smaller organizations could turn their attention away from constant performance tuning and focus instead on making sure that IT is providing solutions that help the business meet its goals.
In my opinion, the point is this: IT's role is not to constantly fiddle with levers in the infrastructure, but to develop and implement an underlying infrastructure that meets the needs of the business. Especially for organizations that need to quickly implement solutions, I can see a major market for services like the VCE Vblock, especially if the coalition partners eventually scale it down to smaller levels, as is rumored to be happening with the development of a "Vblock 0" service.
The major upsides: Get an underlying architecture in place very quickly that can support a predetermined workload and that has single-vendor support.
Although the upside is huge, there are some obvious downsides to the Vblock concept. Many organizations don't know what their specific workload requirements will be, so being able to target a specific computing range simply isn't possible. Further, the inability to widely manipulate the various processing levers will always leave some resource sitting more idle than another. This is an inefficient use of resource and is a situation that could be corrected by optimizing each of the performance levers in a more robust way.
The suitability for a Vblock-type service in an organization will be dependent on that organization's individual needs. Some want to leverage the infrastructure as a service and focus their technology efforts on other business needs while others will opt to build out the infrastructure one optimized block at a time in order to maximize flexibility. To me, this is an alignment issue, which isn't to say that either side is necessarily right or wrong, but that both sides have options.
The takeaway: Decide what's more important to you and your company -- quick infrastructure deployment or heavy optimization capability -- and choose the appropriate path.