VCE VBlock – When is the right time to start?

In talking to many people at VMware, I’ve often heard them say,”..almost anyone can virtualize the first 300-400 servers, but after that it takes a true mix of skill, technology and planning…”. I bring up this anecdote for a couple reasons. First, I’ve heard several people ask if Vblock was only useful for the largest customers or largest deployments. It’s not a coincidence that we target a Vblock 0 (the smallest version) to begin around 300 VMs. Vblock operates differently.

The second reason is that I was reminded of this again this morning as I spoke with a large Enterprise customer. The customer is an early, existing Vblock account, with several thousand servers yet to be virtualized. Their technical staff had engaged the VCE team in weeks/months of rigorous technical debate about the inner workings of Vblock. They had already deployed just north of 400 VMs and were pushing back at a different operational model. So when I asked their leadership why they finally decided to more towards a VBlock architecture, their answer was, “We got to 400 VMs through far too many exceptions in process. We couldn’t move to the next level without a forcing function to align our business needs with our technology organization.” In essence, they needed a solution that combined the right technology with the right process. They didn’t believe they would get there with the current model.

The interesting thing about this account is that the technical staff is as engaged as ever in finding ways to push the system. They have some very unique requirements as we move them from physical to virtual. They are driving us to solve their challenges today, but also helping us shape the Vblock of the future. But the conversation has changed over the last six months. The conversation is now solution-centric, with a cross-trained staff understanding the dependencies within a Vblock much better than in the past. They believe that Vblock has helped them take the first step in moving to a more efficient and coordinated model.

300-400 VMs is by no means a defined hurdle that IT must over come. For some companies it might be 50-100 VMs. For others, it might be 1000 VMs. But like anything at scale, rapidly virtualizing your IT environment takes proper architecture and planning. In some cases, Vblock might be the right architecture. We’d be interested in hearing your feedback about when you hit those thresholds that told you it was time to do things differently…

3 Comments.

Disclosure, EMCer here.Brian, I've seen something similar with the customers I've worked with on Vblock. Beyond the technical giblets (and this is coming from one who loves technical giblets), there's an interesting forcing function"" accelerant factor behind a Vblock concept. It's more about focusing less on certain choices, and more on others. The interesting thing is that several months in, the customers are finding that the things they obsessed about before are less important than they thought.It's more about forcing the change to look at the integrated stack underneath the virtualization layer as an integrated stack - rather than a set of independent stacks. This triggers the organizational change that's often needed to make ""virtualizing servers"" to become ""operate more in a cloud-like fashion"".It's certainly an interesting thing to have a front-row seat in this exercise.BTW - just so it doesn't sound like a vendor commercial, I've seen similar effects where people have forced themselves down their own ""integrated stack design"", so I think those effects are more about the idea than the individual vendor parts.In one standout case, a customer who was very mature in this model (having already rev'ed their ""integrated stack under VMware"" twice) had an interesting perspective. I thought he would barf all over the concept (after all, here we were proposing an integrated stack over his baby, which was already on Rev 2). The architect/driver's comment? ""If you're even close, its good enough. Rev'ing to version 3 of our architecture (to keep up with technology change) would cost our org several million dollars - and frankly, that's not our business"".Interesting."

Nice post. I see the same thing all the time.At some point, doing things the way you've always done them hampers progress, rather than facilitates it.And Vblocks tend to bring this issue into sharp focus.More posts, please!

Brian - One of the other things that I like about VBlocks are that they provide simple guidance on storage networking decisions. Small virtualization configurations are typically running NAS or iSCSI (VBlock 0 size), while larger configurations (VBlock 1 and 2) are more likely to be FC configurations (and starting to leverage FCoE in the rack).

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.