Top Ten Vblock Questions -- So Far!

So, I've been in front of lots of customers since the VCE Coalition announcement, and a lot of them focus primarily on the Vblock itself.

I thought I'd share the questions I'm getting -- and how I'm answering them.

Note: in addition to customer/partner focused questions, there's been a whole lot of snarky sniping from various competitors and others who may have a different agenda.  All part of the fun.  I'll try and cover their concerns later, but -- for now -- we'll focus on the people who pay the bills!

#1 -- Why Did You All Do This?

Most every decent-sized IT organization wants to get to the benefits of large-scale virtualization as quickly as possible.  We decided to take the very best technologies from all three companies, and package it up as a "virtualization appliance" to not only speed deployment, but overall improve results.

Think of it as a new option to consider: do things as you've always done them, or consider a new deployment and operational model via Vblock.

One of the challenges associated with private clouds is that three important things usually have to change at the same time to get the maximum benefit -- the technology model, the operational model and the consumption model.  A Vblock is intended to accelerate all three.

#2 -- What If I Want To Use Other Vendor's Technologies?

Feel free.  As always, people are certainly welcome to choose individual technologies and integrate them in such a way that they see fit.  VMware's products works with most everyone, Cisco's products works with most everyone's and EMC's offerings do the same.

However, these mix-and-match combinations aren't Vblocks, they're more like traditional IT approaches to building infrastructure.  At the same time, each of the three vendors are more than willing to sell you the individual components you'll likely need if you're taking the traditional approach.

#3 -- The Vblocks Seem Really Big, Why?

If you look at, for example, at a Vblock type 2 supporting ~6000 VMs, you may wonder -- who the heck needs that?

Well, we work with a few customers who are already in that territory, both large enterprises and service providers.  However, if one imagines what happens when virtual desktops catch on, ~6000 VMs can be consumed in a hurry.

Besides, if you can makes something work well at significant scale, the benefits trickle down to more modest environments.

#4 -- How Do I Manage A Vblock?

We *strongly recommend* (but do not insist) that people consider EMC Ionix UIM (unified infrastructure manager) as the element manager for the Vblock.  A major part of the value proposition is tied to the next-gen operational model, and you need an integrated element manager to achieve this, and today, there's only one to seriously go consider.

#5 -- What Do We Use A Vblock For?

Basically, anything that you want to do with VMware at scale. 

For some people, it's traditional workloads at scale -- Exchange, Oracle, SAP, et. al.  For other people, it's a platform for the new stuff -- virtual desktops, app dev and test, or self-service computing.

#6 -- Can I Integrate A Vblock In With My Existing Servers, Storage, Fabric, etc. ?

Yes and no.  Part of the idea behind a Vblock is the proverbial "clean sheet of paper", in exchange for which it delivers an eye-opening difference in capex and opex.  Taking that end-to-end value proposition, disassembling it, and forcing it to integrate backwards seriously dilutes the value proposition.  Certainly, it can be done (it's open technology, after all) but you probably won't be entirely happy with the results.

The primary exception is management.  Although we recommend UIM (above), it in turn plugs nicely into existing enterprise management frameworks you might be using today, such as BMC, Tivoli et. al.

#7 -- All The Competitors Are Calling This Closed, Proprietary, Risky, Evil, Etc.

Yes, they are saying that stuff, aren't they? 

At a practical level, all of the component technologies (server, fabric, hypervisor, storage, management) are no more open or closed than they were before Vblock.  Yes, it's true you can't build a Vblock with anything you choose, but that's sort of understood.  And if you want to build your own Vblock equivalent from this set of technologies, or some other combination, that's always been an option -- fully supported by each vendor individually.

Risky?  I'd offer it's no more or less risky than the component technologies and their ability to integrate and interact at scale.  Again, we're talking VMware, Cisco and EMC products.

The other thing we hear is "where is best-in-breed?".  We agree, that's important. 

Our collective position is that -- for this particular use case -- these are best-in-breed technologies, pre-assembled, pre-characterized, with integrated management and security, supported as a whole.

#8 -- How Do The Software Vendors Feel About This?

Basically, no differently than they feel about VMware in general. 

Some vendors, like SAP, are "all in" and very enthusiastic.  Other vendors (Microsoft, IBM) take a more balanced approach that they need to support what customers want to do on the infrastructure side, but would prefer to sell the entire stack.  One vendor in particular (Oracle) has clear ambitions around their own stack, and takes a very dim view.

Interesting to note -- a common request we're getting is to configure a V2P capability (virtual to physical), so that if a given software vendor gets cranky about replicating a specific problem in a physical environment, that can be automated.  Although we don't expect that to be used very much.

#9 -- What About Software Vendor Pricing?

Unfortunately, the members of the VCE coalition can only control the pricing of the products that we collectively sell.  There's still a *ton* of software products out there that are decidedly unfriendly to the implied variable consumption models associated with private clouds.

We'll all have to work through that one together.

#10 -- How Do I Get Started?

That's rather straightforward -- tell us about the use case you have in mind for a Vblock, and that starts the discussion. 

Maybe it's virtual desktops, or self-service computing, or business analytics, or app dev and test, or your SAP landscape, or maybe something else entirely.  Telling us "how big" (in terms of VMs) would be useful as well.

Next, decide whether you'd like your own team to do the installation, migration and operation, or whether you'd like that done for you, perhaps with a little help.

Then we're into the details: specific proposals, pricing, scheduling, etc.

And A Final Note

You'd be surprised at just how many people we're talking to are interested in #10!

Comments

[David Vellante]

Can I add one Chuck...

What's the best way to back up 6,000 VM's?

[Chuck Hollis]

Hi David

Generally speaking, the answer is client-side dedupe approaches. The Vblock architectures are generally rich in both CPU and memory resources, favoring this approach over target-side dedupe, not to mention minimizing I/O traffic.

Of course, if someone wanted to use another approach (e.g. traditional backup agents to tape or dedupe disk, snap and backup, etc.) all of that still can be done if needed.

-- Chuck

[Adrian]

Hi Chuck, Who are VCE's competitors on this coalition. Is anyone else selling a similar approach, HP and Brocade for instance ?

[Mark Bowker]

Hi Chuck,

Only 10 questions? ;-) Fair enough....you said so far :-)

First of all thank you for responding to the questions I posted on; http://www.liquefyingitblog.com/

Her are a few suggestions to add to your list:

#11 -- How do the channel partners and resellers embrace Vblocks with open arms? Aren't Vblocks the exact value they provide to their customers?

#12 -- Is Vblock a product/ skew or a reference architecture? Why?

#13 -- Why form a joint venture (Acadia) if EMC, Cisco and it's partners can perform individual tasks? Does this strip away revenue? Acadia will ONLY be called to the plate to "Build, Operate & transfer". If a customer only wants one or two of the three they go to to Cisco, EMC or partners anyway.

I'll stop with #13 in honor of Friday 13th :-)

Thank you in advance for adding to the list.

-Mark

[Chuck Hollis]

Hi Adrian

There are generically two classes of competitors -- those that are offering integrated stacks, and those that are currently outside a stack. Both will compete differently.

The stack vendors are HP, IBM, now VCE and potentially Oracle/Sun if they ever make peace with the EU :-) We expect to compete vigorously with HP, less so IBM.

There are a host of good vendors that are currently outside a stack: Brocade, NetApp, BMC, etc. Each of these will focus on the "best of breed" message and attempt to convince customers and partners to build their own stacks, rather than considering a pre-made one.

The members of the VCE coalition have to do both: focus on differentiating the stack, as well as supporting customers who wish to build their own stacks.

Hope this helps!

-- Chuck

[Chuck Hollis]

Hi Mark

These are all very insightful questions, and deserve thoughtful answers.

So, let's get started ...

#11 -- How do the channel partners and resellers embrace Vblocks with open arms? Aren't Vblocks the exact value they provide to their customers?

Well, just ask any partner, reseller or integrator that's working in this ecosystem, and they'll generally tell you that they're very excited about this.

You're right about the services piece, but as you learn more about it, most reseller consider this a poor business to be in -- it's hard, it's expensive and customers won't pay much of a premium for selecting and integrating ostensibly off-the-shelf components.

They'd much rather take their services headcount and point it at high-value, high-touch services that are more in demand, and they can charge a premium for -- migrations, consulting, application integration, etc.

Wal-mart can't charge much of a premium for assembling bicycles at Xmas, if you get my drift :-)

#12 -- Is Vblock a product/ skew or a reference architecture? Why?

I think the term you're looking for here is "SKU", refers to "stock keeping unit", which originated in the retail segment.

The respective companies provide a reference architecture and a bill of materials for their pieces. Customer who want the complete package will mostly engage with a partner, or perhaps the services organizations of the three companies as part of a larger services engagement.

Having one company resell or OEM the other's respective pieces (especially between EMC and Cisco) doesn't necessarily add a lot of value, jacks up the prices and creates interesting channel conflicts. And no one is going to pay much a premium for a pre-integrated stack vs. components, especially in larger environments.

#13 -- Why form a joint venture (Acadia) if EMC, Cisco and it's partners can perform individual tasks? Does this strip away revenue? Acadia will ONLY be called to the plate to "Build, Operate & transfer". If a customer only wants one or two of the three they go to to Cisco, EMC or partners anyway.

The problem we were trying to solve is pretty hairy if you think about it. First, there are three relatively new sets of skills that need to be brought together simultaneously: this stuff is built differently, operated differently and consumed differently.

Although each of the three companies has substantial services capability, we quickly realized that we needed a new construct to accelerate adoption, and it made sense to structure it as an independent JV. Many (but not all) of the people in Acadia come from one of the three companies, for example.

The second driver was accelerating partner enablement. We realized we needed a big investment to get the ecosystem up and running quickly, and -- once again -- the JV structure made sense.

Hope this helps!

-- Chuck

-- Chuck

[David Vellante]

Thanks Chuck...I agree, generally source-side de-dupe is your 'good buddy' in big VMware shops. I'm looking forward to the Vblock backup/recovery reference architecture Chad told me about this week. Not really what I'd call an 'edge' use case as some in the new BRS group imply for AV - ahem. Maybe I should blog about this for the 100th time and make some more friends :-)

Okay...next question...how do I restore in that environment w/o breaking the bank architecting a zillion grid nodes?

btw...great security white paper with the RSA folks-- best I've seen on the topic. I saw a very early version before you got involved and it's come a long long way. Nice work to the team.

[Chuck Hollis]

Hi David -- thanks for the engagement.

As we both know, full and immediate restores of entire zillion-VM environments usually fall under the heading of "disaster recovery and business continuity", so it really morphs from an Avamar discussion into a replication discussion. More on that soon :-)

There are some announcements coming out soon from Avamar that make what's already a good proposition (in terms of CPU/RAM/IO resource sizing) even more compelling, but I don't want to spill the beans.

Thanks for the kudos on the RSA security paper -- I think it came out pretty well myself.

Have a great weekend!

-- Chuck