VCE and Vblock –3 years in.

I have to say – I think I have a unique perspective on today’s VCE’s announcement.   It’s been 3 years since we had our first customer approach Cisco and EMC and say “we want converged infrastructure” (our response at the time was “huh?”) and also at the same time, Ed Bugnion and the Soni/Marco/Prem/Lucas team having a small team meeting in San Jose and getting introduced to “Project California” (which became Cisco UCS/Nexus).   I remember like it was yesterday!

There will be a lot of blog posts that talk about how awesome the new stuff is, how awesome the progress is.   Chuck Hollis has a great one here.  You can see the launch and interact at http://www.vce.com.   And you know what – it’s all right on.  

I’m going to take a different tack.   Here’s the good/bad/ugly after 3 years.   Fair?

Read on…

You’ve got to understand – the best ideas come from either: a) a bunch of (perhaps as little as one!) people coming up with a great idea; b) listening to customers complain about their problems.

VCE was really born from B: listening to customers.   The amount of time people were dealing with all the crapola (technical term for low business value) elements below the virtualization/cloud automation layer of the stack (a technological challenge), how classic “we have a bazillion adapters!” orchestration was so fragile in the enterprise due to insane variability (a technological challenge) and how storage/network/server/virtualization teams (an organizational challenge) infighting was slowing them down – an real barrier.

We had many CIOs come to us and express frustration that they were unable to be “cloud like” in their agility – but knowing full well that this was FAR more about people and processes in their enterprise than it was about tech.   They started to realize that something had also changed – that the degree of optimization they were getting at the infrastructure layer was declining.   It wasn’t a coincidence that the folks with clouds were hyperstandardized.  That’s a REALLY hard thing for me to acknowledge as a publicly proud nerd, but it’s also true.

There was one other thing too – people started to realize that virtualization liberated them finally from “hardware vendor lockin” – that frankly they could get out from almost anything.

VCE was born from listening – and all the things above.   It was an agenda of “if YOU have chosen a path where you need to move fast, need radical simplification, and are willing to consider people/process change – here’s how we can help”.

There was ONE CUSTOMER in particular that was the genesis of VCE and Vblocks  - and you know who you are dear reader!)   The dialog 3 years ago was almost funny in retrospect (I paraphrase below, but it WAS and STILL IS the essence behind VCE):

• Customer: “VMware, Cisco, EMC – we love you guys!”
• Us: “Awesome! Thanks – we try really hard.. we’re glad you love us!”
• Customer: “Yeah – but we’re under a lot of pressure to be way more agile, and compete with Amazon.  So sorry – higher up in the stack, we’re being told to outsource to IBM (ed: I remain VERY skeptical that this choice EVER makes someone more agile!) or to move to public cloud models.   We just can’t seem to get out of our own way!
• Us: “What?!?!?!”
• Customer: “Yup, sorry guys”
• Us: “well… What would you need to be more agile?”
• Customer: “Hmm.   we would need a way to… in essence BREAK our silos of our teams and processes that have been born out of the ‘build a stack under an app, project by project’”.
• Us: “GREAT!   We have a Reference Architecture!   It’s even a Cisco Validated Design!  And EMC Proven!”
• Customer: “Awesome – that would help standardize, and would stop months of arguing over how to pick and configure.   But wouldn’t change how we procure and operate – because we would still procure all parts separately, and we or a partner would integrate.”
• Us: “Hmmm.   So – you need to PROCURE as a unit across server/network/storage  - and as capital or opex.”
• Customer:  “Yup”
• Us: “umm… we can’t do that.”
• Customer: “yeah… Oh, and we need to SUPPORT as a unit – literally single support model for the whole thing”.
• Us: “umm… we can’t do that.”
• Customers: “Oh, one more thing – we need to WARRANTY as a unit – that should be easy”.
• Us: “……”

This dialog (I was there) had us really scratching our head as VMware, EMC, Cisco – and this is really hard to understand from a tech-only standpoint – this are business things, not tech things.   But they matter.

Rapidly (and that customer was the “canary in the coal mine” – many rapidly followed) – we realized we needed to create a Joint Venture (JV) – as these economic constructs – we simply couldn’t do – and our incredible channel partners could only go so far as a general statement (hence VSPEX later).

Thus, VCE and Vblocks were born.

Since then – there have been more than 1000 Vblocks shipped, hundreds of customers, and more than a $1B run rate.   That’s a huge success and shows “when you listen – good things can happen”.

So – let’s get to good/bad/ugly.

Ugly:

• “Vblock = Cloud”.  I was with a customer literally the week after last in Germany.  A huge household name that was one of the first Vblock customers (thank you!).   Their feedback (and if they read, feel free to comment!) was “Vblock didn’t deliver the agility we wanted”.   I asked: “did you change from people silos of ‘storage/network/server/virtualization’?”  Answer: “No.”  I asked: “did you use different tools/processes for management?’  Answer: “No.”   This is a case where we let that customer down.  We didn’t push back and say “no” enough.   It’s hard – but that’s the solution provider’s responsibility.   When they ask “can we use all our existing structures, and the storage team wants to provision the storage just like they always do, and we want to use our existing tools like we always have”… we should have had the self-discipline and customer focus to push back.  They wanted to change, but were also struggling to change.   They were asking for simple “best of breed parts” – which isn’t transformation.

BTW – to be REALLY clear – I asked the customer “how is the Vblock itself” – and their feedback was “it is a rock” (in german).   “Fast, extremely reliable – but it didn’t make us more agile”. 

Vblock simplifies, performs great, and is a rock (literally the VNXes and VMAXes in Vblocks show about 10x greater availability statistically than the same kit in mix and match), but if you simply zone the storage into your fabric, and provision the hosts normally – nothing really has changed.  Now, later that week, I met another customer in France – Credit Agricole, who RAVED about their Vblock.   What was different?   In the Credit Acrigole case – the forcing function was a project (just like with Visa) which was so time-constrained, and outcome-oriented that they just needed to GO.  They drew lines in the sand.   YOU WILL NOT apply the “how we always manage infrastructure”, or “these are the tools/processes we use to provision/de-provision/manage” if they slow things down.   Low and behold – the Vblock served as a hammer to crash through the walls holding them back!

Bad:

• “Unified Management”.    This was a lot harder than we thought at first glance.    EMC UIM was a good attempt, but didn’t get to the heart of the challenge.   There was a need for something BASIC.   UIM focused too much on the UI and workflows.   Customers told us – it’s simple:  “we need  a basic ‘BIOS for a Vblock’ (very low level – more able to discover basic stuff without a lot of work), and the UI is not a UI, but really is about the API.”   With EMC UIM, we started with the UI and workflow, and ended up the AI and physical discovery.   It was the wrong order.   Also the really basic low-level physical discovery was a hard problem – automatically surfacing when things get added BEFORE they get configured.
• Being binary about “Converged infrastructure”.   At first Vblocks weren’t rigid enough (they were reference architectures in 2009, and we had some that we mangled on site assembly as reference architectures are wont to do), and then VCE over-rotated into “locked down configs”.   Mid 2011 it got sane – two types (Vblock 300 and Vblock 700), with the ability to scale blades and storage up and down.   These early days of hyper-rigidity where not right.   They (along with the next point) were an error that opened up the market for “Vblock nay-sayers”.
• Partner enablement.   For those of you that know me on the inside, starting in 2010, I started to really hammer on the idea of “just treat the parents” (aka Cisco/EMC) “no different than the partners” (aka the resellers) – ergo enable us both to help customers.   I think VCE wasn’t clear enough: “we are a partner and channel play – but if you see that you drive a ton of value in ‘assembly’ for customers (and many VARs have built good businesses on this) – maybe we aren’t right for you.   If you are a partner who’s primary value is higher up the stack (helping customer deploy apps, new solutions, VDI, etc) – then we’re right for you”.

Good:

• Customers love Vblock.    I talked about Credit Agricole and Visa – but they are legion.   One of my favorites is Novartis – who is using Vblocks to simplify and accelerate huge swaths of their IT. Customers who really accept the people/process part of the things that surround “hyper-standardize, virtualize everything, automate like crazy” see huge value.   When your customers become your biggest advocates – with more than half choosing to buy additional Vblocks that says something.
• Real quantified value.   Again – with the common element of “embracing change” – customer have shared their experiences.   IDC did detailed “pre/post” studies with 5 customers in April.   Findings:

VCE continues to grow, adapt and evolve.

The new announcements:

• Broaden the use cases – with Vblock 200s for smaller datacenters, and Vblock 100 for Robo and manufacturing/industrial use cases.
• Build app-specific use cases.  While our view is that infrastructure generally needs to be “horizontal” pools of compute/storage/network under a virtualization layer – some cases are unique.   The SAP HANA Vblock appliance is build specifically for this powerful use case.
• Fix something fundamental – with the VCE Vision Intelligent Operations Software (“VIOS” – kind of like a “Vblock BIOS”) – there is a simpler low-level piece of software designed to really tackle the discovery/compliance/logging elements needed – and presenting up a simple API for all Vblock interactions that can plug right into vCenter, vCOPS, and vCloud Automation Center – as well as Cisco’s management stack (or others) – so customers continue to have choice.

Together with the emergence of VSPEX for customers and partners who don’t agree that they need to just hyper-converge and get on with things but truly see value and business differentiation through mix-and-match + integrate (which is a VERY different value proposition than Vblock)… Well – look at how the story started, look at the “good/bad/ugly” list, and you can see how VCE and Cisco, EMC, and VMware continue to work to help customers.

Comments, feedback welcome.  Are you a Vblock customer?  How is it going?   A VCE partner?   Ditto – feedback always!

Comments

[Dave Hopkins]

Wow. It would have been nice to have some of this brutal honesty in todays VCE announcement. Don't get me wrong the announcements were great, (vblock 100,200,320,720,Specialized,VIOS), but what was really missing was the kind of evolution of their products explained based upon the experience of VCE for past three years. It was not fatal, just an opportunity lost with a large audience to say something very interesting and engaging. Thanks Chad for providing this sort of perspective.