Stacks, the Vblock and Value — A Chat with EMC’s Chad Sakac

Stacks, the Vblock and Value — A Chat with EMC’s Chad Sakac

It’s not always easy being a customer.  There’s a lot of noise in the marketplace and it’s not always clear to the customer which statements are relevant.  As we often see in public life, sometimes the most discussed issues are not always the most relevant or important.

There’s been a fair amount of noise lately coming from many directions on competing datacenter stacks, but looking past the shop talk and mud-slinging, what are they key issues for the customer?  For example a customer may not be terribly concerned with a product’s value chain and how well it works in the sales channel, but will be very concerned with how will it perform and create value in their data center.

I had some questions of my own on various capabilities of different stacks, so I reached out to EMC’s Chad Sakac who offered to answer some questions from his position as the VP of EMC’s Technology Alliance.  Before we get to the discussion I wanted to take a quick moment to define “stack”.

What’s a Stack?

A stack is essentially four components designed to work together as a datacenter platform:

  • Storage
  • Networking
  • Servers (compute)
  • Management and Orchestration across the stack – integrated APIs and tools.

Some stacks are built around x86 virtualization (stack ends at the VM) while other stacks will consider x86 virtualization as being optional (stack ends at the physical server).

Customers have choice in that they can attempt to build their own stacks (where the customer owns the engineering burden) or they can elect to purchase a stack from a vendor.  Further complicating matters is that some vendor stacks might more closely resemble a reference architecture (existing components certified to work together in a specific configuration), while other stacks might possess characteristics of a more cohesive product.

There are several considerations inherent in these stack options which can impact both OPEX (Operational Expenses) and enterprise agility that a customer needs to consider such as:

  • Simplicity of procurement
  • Scope and terms of warranty
  • Single versus multiple points of support
  • Simplification of the stack’s lifecycle (deploying, maintaining, refreshing)
  • Elasticity of the stack (are you forced to buy more than you need?)

Vendor Stack Offerings

The Vblock is a stack consisting of EMC Storage, Cisco networking, and Cisco UCS servers virtualized with VMware vSphere, coupled with integrated management and orchestration.   Vblocks are manufactured & supported by VCE, a joint venture between EMC and Cisco (with minority investment from Intel and VMware), and sold via channel partners and Cisco and EMC.

Several hardware vendors are also putting together their own x86 virtualization stacks, including HP’s Matrix (CloudStart), IBM’s Cloudbust and Oracle’s Exalogic.  Like VCE and Vblocks, they represent a new model of technology acquisition, deployment and use. Also like VCE and Vblocks, the vendors continue to support the long standing “mix and match” model of piece parts, based on standards and interoperability that have existed for years in open systems.  Oracle’s Exalogic however has received some criticism in some quarters of resembling a mainframe and lacking elasticity relative to other stacks and more.

The FlexPod offering by NetApp at first glance appears to be similar to the Vblock (as far as components) as it uses the same components for servers and networking, but utilizes NetApp storage solutions and several third-party management and orchestration tools.  After a closer look however, it appears to resemble a reference architecture in these sense that assembly, procurement, support, orchestration, etc. seem to be more of the “mix & match & assemble” model.  I reached out to EMC’s Chad Sakac to gain more insights from his perspective on how the various stacks…well…stacked up.

A Discussion With Chad Sakac

Q:  At the core, all stacks provide a platform for virtualization and reduce the engineering (integration) burden.  Is this the “least common denominator” which all stacks have in common?

A: That’s one of the “least common denominators”.  Here’s the list of what all “the stacks” offer in common: 1) an integrated product for hosting x86 workloads reducing the integration and interoperability burden. 2) a new procurement model – the unit of acquisition/warranty is “integrated infrastructure”, not piece parts; 3) a single-vendor support model as opposed to multi-vendor joint escalation; 4) management tools and APIs that orchestrate across the stack.

Q:  Is this the original market need you were trying to fill with the Vblock and how have you seen that market evolve since then?

A: Yes, but it’s been a fascinating 2 years on our own VCE journey.

Those requirements and market needs have been surprisingly consistent – period.   But our early customer interactions were… well… different.   Those differences has changed HOW we’ve gotten to serving those consistent requirements over the last two years – VCE having been public for one year, but something we were discussing privately before that.

The first few customers who started to push us in this direction happened to be HUGE cases.  For perspective, they were asking for several hundred Vblocks in one go.   In those cases, the customer was very explicit – they wanted “private/internal clouds”, and wanted them NOW.   The other major difference was that they wanted it to be built by the provider, maintained and operated by the provider of the solution, and wanted to pay for it “by the VM used” – ergo, it looked exactly like an “internal” version of the external public cloud consumption models of things like Amazon EC2.     Most often, VCE was competing with IBM in those engagements.

Those initial requirements were the thing that necessitated the VCE joint venture – as there was no way for Cisco or EMC or VMware to offer what the customer was demanding independently on the support front.

Those initial customers also drove the initial need for one of the things the joint venture needed to provide were Build/Operate/Transfer services.  Just think about it – early the model of “infrastructure as a service” is based on the type technologies that Cisco, EMC and VMware support, but the way the customer wanted to consume/pay for it was something that few (HP, IBM and the largest Systems Integrators as examples) could provide.   When you have that model, “manufacturing” the Vblock wasn’t a big deal – as the VCE joint venture or an SI partner would do it for the customer on site – so the customer was cool with boxes of component parts arriving from multiple vendors and being integrated on site (as that was all invisible to them)

That last part – “operate it for me in a Build/Operate/Transfer model, and I will pay by the VM used” – has turned out to be something that IS NOT generally a requirement.

Since then, what we’ve seen at hundreds of customers is that they come in every size and shape, but the most common thing is they want is the PRODUCT that accelerates them in offering their own Infrastructure as a Service (IaaS), not A SERVICE that is IaaS.   That meant we needed to change a few things:

  • VCE needed to continue down the “integrated support” model – that was something that was nailed early.
  • VCE needed to build real manufacturing lines – so that the product (a Vblock) arrives as a unit.
  • In turn that means that EMC and Cisco act, in every sense that matters as OEMs that provide parts to a vendor (in this case VCE) who manufactures a product.
  • VCE needed to build a model and human resources that supports the various ways that customers acquire Vblocks as a product – enabling channel partners and Cisco and EMC to be able to sell Vblock as a product and deliver integration services and value on top of Vblocks.

Here’s a quick analogy that makes what drives the customer requirements crystal clear:

“I can go to Fry’s Electronics, and build my own homebrew server out of any set of parts (motherboard, case, CPU, powersupply, NICs, HBAs, whatever) – it’s the ultimate in flexibility as I can have any parts I want.  They are all interoperable and work with each other.  Of course, I’m going to spend time putting it all together (which I as a propeller-head like, but frankly is a waste of time), and boy, sometimes I’m going to get bit by “this doesn’t work right with that”.   OR, I can by a server from HP, Dell, or IBM, where they OEM the parts, I go to a site where I pick the type of server (1U, 2U, 4U), pick my components from a pre-selected set that are pre-integrated/tested, and the whole thing arrives, and I rack and power it on.  Oh, and it comes with things like Insight Manager that let me see/manage the server as a unit”.

IS THE SAME IDEA AS:

“I can go to any Server, Network, Storage and Management tool server and build my own homebrew stack out of any set of parts (e.g. VMware, HP servers, Cisco switches, EMC or NetApp storage, whatever) – it’s the ultimate in flexibility as I can have any parts I want.  They are all interoperable and work with each other.  Of course, I’m going to spend time putting it all together (which I as a propeller-head like, but frankly is a waste of time), and boy, sometimes I’m going to get bit by “this doesn’t work right with that”.   .  Or, I can by integrated infrastructure from VCE, where they OEM the parts, I go to a site where I pick the type of server (Vblock 0, Vblock 1, Vblock 2), pick my components (number of blade packs and the associated disk packs) from a pre-selected set that are pre-integrated/tested, and the whole thing arrives, and I rack and power it on.  Oh, and it comes with things like Unified Infrastructure Manager that let me see/manage the server as a unit”.

If you look at that, it’s literally a search and replace of the two paragraphs 🙂

While TODAY, the first kind (mix and match and build yourself) is the more common way of building IT x86 infrastructure – everything we see from the market, from customers, from the technology roadmap suggests that a move over time (nothing happens overnight) to integrated infrastructure models over time is inevitable.  It’s perhaps one of the main ways we can make material progress against the “spend less time/money on keeping the lights on” infrastructure and focus more time/money/resources on things that provide core business differentiation and value (which are applications, not infrastructure).

Q:  Several stacks see orchestration as another level in which to provide value.  For example, sometimes in IT we see delays created by the IT silos where the storage team asks “what was the zoning presentation again?” and the network team clarifies “which VLANs did you need on that interface?”.  It seems that stacks can help here, by creating a technical platform which — when properly utilized — can transcend the IT bureaucracy and thus improve agility.

Some stacks add vCenter plug-ins for orchestration, but the Vblock utilizes Unified Infrastructure Manager (UIM) for orchestration with the Vblock.  Exactly how do you see UIM providing value differently from vCenter plugins for example, used in some other stacks?

A: vCenter plugins don’t do end-to-end orchestration.   Let’s look at what we’re talking about.  What needs “orchestrating”, and what does “provisioning” look like on an integrated infrastructure product?

Well – you don’t provision storage, or networks, or servers.   You would need to provision services.  As an example of what a service would be would be “How much total capacity in my infrastructure do I have across pools of compute, networks, and storage?  Ok, I have enough – please give me a bronze vSphere cluster and a gold vSphere cluster”.  Note – you DON’T say “I want that blade, and that network, and that storage”.  Then, you need to have the following happen – blades get assigned (including all firmware updates), networks (for all network/storage needs), storage for boot/datastores gets configured and provisioned, and vSphere gets installed.

Then, you just consume the resources via vCenter or via a self-service portal like vCloud Director.

You need to have the ability to manage those services (change them, decommission them, check SLA of the service) in an integrated way.  One also does the “macro” provisioning  like creating clusters rarely (think weekly or monthly) but do the VM-level provisioning frequently (constantly).

Those capabilities need to also be accessible as an “integrated infrastructure API” (otherwise integrating with other tools/frameworks still gets done at the point element of the integrated infrastructure stack – which in turn means you save nothing when integrating into a given customer environment).

That’s a BIG difference vs. vCenter plugins.   vCenter plugins rock, and every vendor (including Cisco and EMC – which we do) really need to have them in the “mix and match” model.  The core idea of vCenter plugins is “let the VMware admin see/provision my server/network/storage”.

BTW – while vCenter plugins are not analogs to Vblock UIM, there are analogous products.    Examples are HP Matrix’s suite of management and orchestration tools,  NewScale, BMC and others.   These all use “modules” (in essence pre-built scripting to APIs) to orchestrate heterogenous servers, networks, and storage.   You can also use some of those 3rd party tools to “orchestrate” mix and match stacks (like a FlexPod for example), though invariably as people who are familiar with that model, there’s always “some construction required” in scripting and integration modules, and that isn’t just to get it running up front, it’s required over the life of the stack as it gets updated/maintained.

One thing that crystalizes the critical idea that true integrated infrastructure is an atomic PRODUCT (not an assembly of elements) is that customers with existing orchestrations tools like BMC Atrium use them WITH Vblocks – interacting with the UIM APIs directly to orchestrate Vblock services, and not the “parts” of a Vblock.

Q:  Some stacks have adopted a “confederated” support model where the customer decides which vendor to call (network, storage, etc), whereas with VCE there is a single entity supporting the product. Is this a big difference, and what have you heard from customers on the various support models?

A:  On this one, the customers I’ve talked to have been clear – for the product category of “integrated infrastructure”, they demand single end-to-end support.  That means explicitly “no multiple accountable parties”.  It helps to think of the fact that we are talking about an atomic PRODUCT, not and ASSEMBLY of products.

Note, I’m not saying they don’t understand and appreciate that leading vendors can develop great joint support models.   These take the form where one of the entity can front a case and be the point accountable party and do a good job with joint escalation.   Customers who chose VMware on Cisco UCS and EMC storage that they buy separately get this today – and we all do our best to service the customer.   This model has been around for eons.

The expectation of support for a product is that the vendor of the product is support.  PERIOD.   If the product claims to be an “integrated infrastructure stack”, then the vendor for that product supports the product.   It’s not a product if that statement is not true.

Look at the server example.  If you’re an HP customer – and you have an issue with their NIC, which unbeknownst to you is using a Broadcom chipset and has an issue – who do you call?   Easy.  Your expectation is simple – it’s an HP server, an HP part.   If you homebrewed your server, you would call Asus who made your motherboard, and Broadcom, who made the NIC.

It’s the same with the category (which is a new one) of “integrated infrastructure” category.

Q:  When it comes to stacks are cloud service providers and in-house private clouds looking for the same things, or are they looking for different qualities in their stacks?

A: an uncharacteristically short answer for me:  Generally the same things, but always different scales.   Also – tend to have different economic model preferences (based on base-load vs. unpredictable load).   Enterprises tend to want capital models (“I will pay you X for your Vblock”).  Service provider tend to want utility models (“I will pay you 1/10*X for your Vblock, but pay 1/10*110% every time I use 10% more).

Though, it’s interesting to see that more and more enterprises are waking up to the upside of utility models as a blend with capital models (aka, “use capital models for your baseload you KNOW you will have, and use utility models for your unpredictable load as opposed to swagging your 3-5 year load and capitalizing the whole thing, because if you’re wrong, it sucks”).

Q:  In a previous post on Blue Shift there was a discussion about the pros and cons of different stack configurations. VCE has Vblocks for SAP and VDI, and NetApp appears to be looking at additional FlexPod designs. There seems to be opportunities to optimize a stack for specific workloads — how far do you see VCE and other vendors going with customized stacks?

A: We’ll produce reference architectures for use cases as far as the customers ask 🙂   There’s interesting demand for “SpringSource App Dev Vblock” and other funky ones.

One thing that’s important to note, the Vblock is a product – it’s not a case of “VDI Vblock” (in other words a DIFFERENT Vblock built for VDI), rather “reference architecture where use case = VDI, products supporting it  = VMware View or Citrix Xen + Vblock”.     The analogy with NetApp is “reference architecture where use case = VDI, products supporting it = VMware View or Citrix Xen + VMware vSphere + Cisco UCS + Cisco Nexus + NetApp FAS”

Q:  Some have criticized the Vblock as being less open and less flexible than other stacks. What do you think this statement means and from the customer perspective is this a meaningful criticism?

A: Here’s the test of whether I’ve been sufficiently clear 🙂   That criticism is PARTIALLY CORRECT.

FIRST – let’s talk about “Less Flexible”:

You can choose VMware, Cisco UCS and EMC.   Or V, C, ___, or ___, C, E, or V, C , ____, or ANY VARIANT thereof.   In those vendor variants – you can have any configuration you want.   All three companies are open, innovate and create standards and comply with those innovated by others.   THAT’S NOT CHANGING – PERIOD.   Joe Tucci, John Chambers, and Paul Maritz have been clear on this – they call it the “mix and match” model (which is how the majority of how IT is done today).  I like to call it “homebrew”.

A Vblock is inherently rigid than “homebrew”.   Every product is inherently rigid in the parameters of the product.

Think of it this way… Again, analogies are useful.   What is more flexible:

“Go to Fry’s Electronics and buy ANY motherboard, ANY CPU, ANY memory, ANY hard drive, ANY case, ANY hard drive, ANY networking kit – then come home, and assemble it”

OR:

“go to www.dell.com and order a PowerEdge C2100 server”

Clearly – the first one is “more flexible”.   So – why is it that almost no enterprise – even the smallest ones – don’t buy servers that way? It’s because it’s a huge pain and support/lifecycle would be a nightmare – just like the state of commodity open systems stacks today – making “keeping the lights on” 70% of the IT expense.   The emergence of “integrated infrastructure” products is a response to the customer/market realization that ALL the stuff (server, network, compute) underneath a virtualization stack is, at its core, a commodity hardware system – just like a server is.

In Integrated Infrastructure products, FLEXIBILITY (change anything you want, however you want) is traded off for AGILITY (gives me enough flexibility to meet a broad set of needs, but the vendor has made some hard choices to narrow variability to make it a PRODUCT).

SECOND – let’s talk about “less open”:

I’m going to repeat myself, because it bears repeating…   Remember, you can choose VMware, Cisco UCS and EMC.   Or V, C, ___, or ___, C, E, or V, C , ____, or ANY VARIANT thereof.   In those vendor variants – you can have any configuration you want.   All three companies are open, innovate and create standards and comply with those innovated by others.   THAT’S NOT CHANGING – PERIOD.   Joe Tucci, John Chambers, and Paul Maritz have been clear on this – they call it the “mix and match” model (which is how the majority of how IT is done today).

Vblock is ANOTHER CHOICE.  It’s another product category though.   So, the “openness” comparison is “does the choice of Vblock limit your future choice/lock you out re replacing Vblock with another integrated infrastructure product, like HP Matrix?”, just like in the “mix and match” model you could ask “does the choice of EMC storage limit you/lock you out from switching to HP/3PAR storage in the future?”.

The answer in both cases is black and white – NO.   The difference is “what would change” if you changed your strategy – let’s look at what you would need to change – comparing the “integrated infrastructure product” category and the “mix and match” category.

  • you change how you manage the integrated infrastructure (i.e. UIM vs. HP Matrix) vs how you manage your storage (i.e. EMC Unisphere vs. HP/3PAR storage management tools)
  • you change any integration you built (i.e. UIM API vs. HP Matrix API) vs. how integration you did with your storage (i.e. Unisphere API and HP/3PAR APIs)
  • you migrate from one integrated infrastructure stack to another (i.e. vmotion/svmotion or migrate from your old integrated infrastructure product to your new one) vs. migrate from one storage platform to another (migrate your data from EMC to HP/3PAR).

You can of course move to, or away from integrated infrastructure at any point you want.

THERE IS ZERO LOCK-IN.

Both the topic of flexibility and lock-in is generally vendor FUD from folks originating from those who don’t have a product offering in the “integrated infrastructure stack” and only play in the “mix and match” product market.   If you’re them, you MUST say that the whole idea of “integrated infrastructure stacks are bad”.

Q:  Some non-VCE stacks are sometimes criticized as being a “reference architecture” as opposed to a “full product” like the Vblock.  This is easily said in 140 characters or less,  but it seems like there are some real issues here that could be quite significant to customers.  What’s your take on this?

A: I think we covered this.  In case my previous analogies failed, here’s another one.    A reference architecture is, in essence “take these ingredients, follow this recipe, and bake your own cake”.   A product is, in essence “go to the store, and buy a cake”.    One has infinite flexibility, one is about agility.   Both categories are valid, and are different.

VMware, Cisco and EMC work together on reference architectures all the time – and customers can mix and match how they see fit.  Heck, we all are open and support everything.  You want Hyper-V on UCS on EMC?  GREAT!  You want Citrix on HP on IBM storage?  GREAT!   You want Citrix on HP with NetApp?  GREAT!

Do you want a product?  Try a Vblock!

Q:  In most cases it would likely be quicker to develop a reference architecture than develop an entire product.  Do you see this as a potential disadvantage for the Vblock – having potentially longer development times?

A: That’s very astute.

A Vblock will ALWAYS take longer to develop than a reference architecture.   Even though the joint roadmap means the bulk of the integration/testing work occurs long before the components are revised – at a minimum, VCE needs to ramp manufacturing for a change.

It would only be a negative thing only if VMware, Cisco and EMC did nothing but Vblock, and the only thing you could buy was a Vblock 🙂  If customers choose that they want mix and match – all the power to them, and we all fully support that.  You’ll get every technology the DAY it’s released if that’s the model you want, and you’ll learn the integration challenges at the exact same time that everyone else does.

The reality is that the time to develop and update the Vblock product is ALWAYS shorter than the “test/integrate” time that the customers are doing anyway with “mix and match models”.

Hence – that’s not a disadvantage for Vblock (or ANY integrated infrastructure product) – it’s an inherent part of their value proposition.

Q:  In addition to orchestration, in what other ways does the Vblock attempt to provide value, beyond other stack offerings?

A: If by “other stack offerings” you mean “integrated infrastructure general-purpose x86 offerings”, the competitors you’re talking about are HP Matrix and IBM Cloudburst.   In those cases:

  1. their orchestration tools are, in my opinion less advanced than UIM, and instead are a whole whackload of unrelated (and not integrated) tools.
  2. Their integrated support is, in my opinion, surprisingly still disjointed relative to VCE support (has anyone called HP support, started with Proliant, then needed to be xfered to the storage team?) .  I **think** this might be an artifact that the VCE support organization was built from the start to support the integrated infrastructure model, and the others, while always in one company, grew organically over time.
  3. VCE views the virtualization layer on top of the physical infrastructure as a CORE PART of the integrated infrastructure offering, not something you “put on top of it”.   That translates into the element parts of a Vblock being best of breed for VMware, the design of the Vblock itself (one example amongst many – there’s a core reason why “blade packs” come in units of 4, which is a function of vSphere fundamental behavior).

If by “other stack offerings” you mean “integrated infrastructure tightly coupled with the application software”, the competitors you’re talking about Oracle ExaLogic:

  1. It seems (to me at least) that to Larry, “all software runs on ExaLogic” means “all Oracle software” – and he said as much at Oracle OpenWorld.   If you are mostly an Oracle shop from a software standpoint, then the logic of tightly coupling the infrastructure stack to the application makes some sense.   I find most customers have a wide variety of applications, and the difficulty of changing applications is insurmountable – so they look for infrastructure that designed for general purpose.
  2. Points 1, 2 from above still hold in this case too, but it’s notable that 3 does not.  Oracle ExaLogic has Oracle VM built in, just like Vblock has VMware built in.

I’m not aware of any other integrated infrastructure offerings – but would love to hear about any others.

Of course – I’m biased.   But, I’d encourage customers interested in integrated infrastructure products challenge Vblock and its competitors to prove the statements I make to them as they engage with you.

If you’re not interested in integrated infrastructure, but rather simply “recipes” (reference architectures) with “ingredients” (products) – then of course there’s an infinite number of players, and it’s a question of deciding which are your favorite ingredients, and then how you will integrate them best.

Q:  The VPLEX has some interesting storage technology, especially in a multi-site configuration. Can we expect to see in the future Vblocks using VPLEX technology to faciltate DR and other multi-site flexibilities?

A: Yes.

The Vblock, like any product, has a product roadmap.   That roadmap has the usual “faster/better/stronger/more efficient” stuff.  It has more and more around tight coupling, orchestration, end to end fault/root cause/correlation and more.   But, it also focuses on enabling new USE CASES.   The demands of Vblock and VCE are significant influences on the roadmap of the companies that provide constituent technologies into a Vblock.   So, expect to see things like Cisco’s DCI, EMC’s VPLEX and VMware vMotion enabling inter-Vblock and inter-site workload mobility as part and parcel of a Vblock sometime soon.

One interesting thing is a core design principle of a Vblock is to never let it become an unwieldy “Christmas Tree” for technologies from EMC and Cisco.  When I say “Christmas Tree” I mean it in the sense that Vblock gets decorated with EVERY ornament for everything under the sun from Cisco and EMC.   Vblock is fundamentally a general-purpose x86 integrated infrastructure product.  Putting TOO much on it means that updating and managing the lifecycle of the Vblock becomes increasingly impossible for VCE.   VCE are very, very focused on the target of being the best general-purpose x86 integrated infrastructure product.    This means that until technologies are very integrate-able (for example OTV being N7K only, or VPLEX being additional hardware elements make them harder to add without fundamentally changing the Vblock itself), VCE is very hesitant to add them.

Q:  EMC has a deep portfolio of storage offerings, some of which could be relevant for certain virtual infratructures, such as Data Domain as a backup target for just one example.  Can we expect to see other such solutions integrated into Vblock offerings or will these be kept separate allowing the customer to tailor their infrastructures?

A: Yes.

Today, backup solutions are part of the Vblock in one of two flavors.  Most customers consider backup to either be something that is done ON infrastructure, or as PART of infrastructure.

In the first case (“backups run ON infrastructure!”), typically want Vblock to integrate with their existing backup approach.   This is almost invariably either backups in guests (in which case, you just keep doing that) or SAN-based backups (which Vblocks can integrate with).    If they want to improve their backup targets, they can of course add Data Domain, but Data Domain isn’t part of the Vblock (remember – “Vblock is a product, a x86 general purpose compute appliance”)

In the second case (“backups runs as PART of infrastructure!”), customers add VMware-integrated array snapshots and Avamar.   Avamar is one of the world’s most popular backup applications for VMware environments for loads of reasons (source based dedupe, vCenter integration, VADP support and more), and since on a Vblock, it’s always VMware – it’s a good optional Vblock component.

Q:  Some organizations may find it necessary to restructure their silos and leverage virtual/cross-functional teams to effectively enable the benefits that are possible with a well-integrated stack.  Can you share any observations — internal or customer — on how organizations have restructured their teams to take full advantage of the Vblock for example?

A: Another astute observation.

One of the core premises of Vblock, or any integrated infrastructure product, is that in a virtual environment, the commodity servers, network, and storage platforms must operate as a tightly integrated and orchestrated system to support the virtualization layer.

This runs headlong into organizations that have “cylinders of excellence” or “silos that don’t talk to one another” 🙂   What we’ve been observing is that many orgs have started to realize that their old way (storage people who don’t talk to server people and both don’t talk to network people) is not a recipe for “cloud-like agility” 🙂   Almost everywhere, we find “virtualization teams” or “cloud infrastructure” teams emerging.  There is a common formula in enterprises:

  • Someone senior realizes that it is easily possible to create an agile, flexible and hyper-efficient “internal cloud”/IaaS model using their existing tech, but their org is part of the challenge.
  • They create this “ranger squad” to go off and build the new thing, and are not constrained by the past model.
  • They put someone in charge who is smart, collaborative, and likes to try new risky things.
  • They pull some of the best people from the “cylinders of excellence” and put them on that team.
  • The team is told “build it, build it fast, and stick to IaaS principles”.

That is usually when the idea of a Vblock becomes very interesting.  I’ve also seen it at customers where the Vblock is used as a hammer to FORCE organizational change (less effective, but it works), where they say “we are collapsing old datacenters to one or more new ones.   The new ones will be built on Vblock/HP Matrix/IBM Cloudburst/HP POD.   Deal with it, or I outsource the whole thing to IBM”.

Often, the people (like me) who are very close to the technology don’t realize that Amazon EC2 has made people in senior parts of their org ask “I don’t get it – why are they able to be so agile, so elastic compared to me?”  Quickly the answer becomes obvious “they focus on just x86 workloads, they build it in very commodity building blocks, and they don’t have a ‘every app gets its own infrastructure’ model”.   They then realize “we can do that too for all our x86 workloads – which is a HUGE amount of our IT spend”.

Q:  At the end of the day it seems that there are several different stacks that can be used to build a strong private cloud platform.  NetApp’s FlexPod gets mentioned frequently partly because it uses many of the same hardware components as the Vblock (storage being the differentiating hardware component).  Customers have a great deal of choice here.  In choosing a stack, does a lot of it come down to what vendors, solutions and support models are the best fit for the organization?

A: ANY combination of servers, storage, network can build a private cloud platform.   I can understand how people might think FlexPod and Vblock are similar, but it’s as different as the following… I’ll try another analogy, just for fun:

1.     V+C+E = me giving you all of the parts that make up a Honda Odyssey and the detailed instructions on how to put it together (VMware + Cisco + EMC).

2.     FlexPod = me giving you all of the parts that make up a Honda Odyssey, replacing the engine with the engine from a Toyota Sienna and the detailed instructions on how to put it together (VMware + Cisco + NetApp)

3.     ____ + ____ + ____ = me giving you the body of one Minivan, the interior of another, and the drivetrain of another, with detailed instructions on how to put it together.

4.     Vblock = I give you a Honda Odyssey, and ask you what features you want, and which options.   You drive it off the lot.

The core decision is “do you want to mix and match”, or “do you want to buy a product that does that”.

If the answer is the former (“I want to mix and match”) – you’ll do SOMETHING like the following:

  • Examine VMware, Cisco and EMC.
    • You’ll see presentations and messages about why EMC works well with Cisco and VMware, why Cisco works well with EMC and VMware, presented by 3 companies.  There will be lots of claims of “uniqueness” which you should examine with a skeptical eye and challenge.
    • It will be coupled with the Reference Architecture (which is based on Vblock design principles), which is a very good reference architecture (“recipe”) of how to put Cisco UCS, VMware and EMC products (“ingredients”) together.   If you ask questions about what you can change, it will be “almost anything”
    • Determine what orchestration software you want from BMC, Newscale, CA, or anybody else, and how you will integrate it.
    • Be ready for the same support experience you are used to from 3 companies, regardless of “joint escalation agreements” (which all major technologies players have had for years)
    • Determine the best channel to buy from – you will need to either issue 3 POs, or work with a system integrator, who will work to put it on a single quote, but it WILL arrive as a bunch of different parts that need to be put together by you or the system integrator, following the recipe.
  • Examine FlexPod.
    • You’ll see presentations and messages about why NetApp works well with Cisco and VMware, why Cisco works well with NetApp and VMware, presented by 3 companies.   There will be lots of claims of “uniqueness” which you should examine with a skeptical eye and challenge.
    • It will be coupled with the Cisco Validated Design, which is a very good reference architecture (“recipe”) of how to put Cisco UCS, VMware and NetApp FAS products (“ingredients”) together.   If you ask questions about what you can change, it will be “almost anything”
    • Determine what orchestration software you want from BMC, Newscale, CA, or anybody else, and how you will integrate it.
    • Be ready for the same support experience you are used to from 3 companies, regardless of “joint escalation agreements” (which all major technologies players have had for years)
    • Determine the best channel to buy from – you will need to either issue 3 POs, or work with a system integrator, who will work to put it on a single quote, but it WILL arrive as a bunch of different parts that need to be put together by you or the system integrator, following the recipe.
  • Examine ____, _____, and _____.
    • You’ll see presentations and messages about why ____ works well with _____ and _____, why ____ works well with ____ and _____, presented by 3 companies.
    • It will be coupled some sort of documentation which will be some sort of reference architecture (“recipe”) of how to put _____, _____ and _____ products (“ingredients”) together.  If you ask questions about what you can change, it will be “almost anything”
    • Determine what orchestration software you want from BMC, Newscale, CA, or anybody else, and how you will integrate it.
    • Be ready for the same support experience you are used to from 3 companies, regardless of “joint escalation agreements” (which all major technologies players have had for years)
    • Determine the best channel to buy from – you will need to either issue 3 POs, or work with a system integrator, who will work to put it on a single quote, but it WILL arrive as a bunch of different parts that need to be put together by you or the system integrator, following the recipe.

If the answer is the latter (“I want to buy a product that does that”):

  • Examine Vblock.
    • You’ll see presentations and messages about that tend to focus less the technology that composes the product (which is of COURSE pretty good – after all, it does very well in the “mix and match” market) and the more about the PRODUCT.  It will presented by one or more companies together based on how they engaged with you, and you engaged with them.
    • It is backed by VCE, which manufactures the product – Vblock.   If you ask questions about what you can change, it will be:
      • “there are three types of Vblock which represent different functions, scales, and capabilities” (just like with a cars, there are hatchbacks, minivans, sports cars, and SUVs).
      • You’ll also hear “within each Vblock, you can add blade packs and disk packs within a min/max range”.   (just like with cars, you there are “core choices” like getting a leather interior, or a canvas interior – or a V6 or a V8).
      • And, you’ll hear “you can have optional things on a Vblock, like vCloud Director, or backup” (just like with a car, there are options beyond the “core choices” like “do you want GPS?”)
    • It comes with end-to-end orchestration for the integrated infrastructure product – UIM. There will be lots of claims of “end-to-endness” which you should examine with a skeptical eye and challenge.  Ask to see it.   Evaluate it.   Ask how it can be used with vCloud Director for self-service portal for end-user consumption (this idea is layered on EITHER the integrated infrastructure model, or the mix-and-match model).
    • Demand detail about integrated product support.  There will be lots of claims of “true integrated support” which you should examine with a skeptical eye and challenge.  How does it work?   How are cases handled?  Who do you call?  The answer should start with “always” and include “no transfers, single party accountable end to end”.   Unlike the “mix and match”, the answer is crystal clear, always.
    • Determine the best channel to buy from – EMC, Cisco, or your VCE-certified System Integrator.   No matter what, you will issue a single PO, and it will arrive as a single part.
  • Examine HP Matrix and IBM Cloudburst.
    • You’ll see presentations and messages about that tend to focus less the technology that composes the product (which is of COURSE pretty good – after all, it does relatively well in the “mix and match” market) and the more about the PRODUCT.  It will presented by one or more companies together based on how they engaged with you, and you engaged with them.
    • It is backed by HP or IBM, which manufactures the product.
    • It comes with end-to-end orchestration of some kind for the integrated infrastructure product. There will be lots of claims of “end-to-endness” which you should examine with a skeptical eye and challenge.  Ask to see it.   Evaluate it.   Ask how it is coupled with vCloud Director for self-service portal for end-user consumption (this idea is layered on EITHER the integrated infrastructure model, or the mix-and-match model).
    • Demand detail about integrated product support.  There will be lots of claims of “true integrated support” which you should examine with a skeptical eye and challenge.  How does it work?   How are cases handled?  Who do you call?  The answer should start with “always” and include “no transfers, single party accountable end to end”.   Unlike the “mix and match”, the answer is crystal clear, always.
    • Determine the best channel to buy from – HP/IBM, or your System Integrator.   No matter what, you SHOULD issue a single PO, and it SHOULD arrive as a single part.

=================================================================================

Thanks again Chad for taking the time to to answer these questions!  This was an informative discussion on stacks and value, although I must admit I’m a bit disappointed that you didn’t use the word orthogonal at all 🙂

Blue Shift just started a series on Agility (Part One here) and in future posts we will try to look at several of these issues — including stacks — from multiple vantage points.

8 Responses to Stacks, the Vblock and Value — A Chat with EMC’s Chad Sakac

  1. Kevin,
    Lots of good information. The organizational shifts are a big challenge for customers – most CIOs aren’t talking about “convergence”, but are feeling the pressure from cloud on agility and cost. If you look at Cisco UCS sales or EMC storage sales, Vblock is a small volume although not insignificant from a revenue standpoint. Thanks for sharing.

  2. Mike Shea says:

    *Lots* of information indeed! In fact the Middle East political situation has been completely described with less.

    I find that anytime an avalanche of verbiage comes my way, something is being obfuscated. Really, does it take this much to describe a ‘stack’?

  3. Andy Ruggiano says:

    A simple concept rebranded? The concept of improving the probability of success is well established in the form a franchise. Franchises provide a proven business strategy, name recognition, pre-established supply lines, training programs and a built in support system. To your point franchises also limit choice to ensure consistency and repeatability. Is the vblock simply the BIG MAC of the technology stack?

    It boils down to a single skew for a pre-engineered solution with all the things customers want: single throat to choke, risk mitigation, co terminus maintenance (the contract guys love this), rapid time to productivity.

    Vblock – VCE figured it out so customers don’t have too?

    Almost like buying the answers to the test

  4. Pingback: Poll: Agility Series | Blue Shift

  5. Pingback: vExpert 2011! | Blue Shift

  6. Pingback: The NoCloud Organization Part 1: Would You Like Fries With Your Cloud? | Blue Shift

  7. Pingback: The Stack Market: Vblock, FlexPod, VSPEX (and me) | Blue Shift

  8. domain says:

    My spouse and I absolutely love your blog and find the majority of your post’s to be exactly what I’m looking for.
    Do you offer guest writers to write content in your case?
    I wouldn’t mind composing a post or elaborating on a
    few of the subjects you write related to here. Again, awesome web site!

Leave a Reply

Your email address will not be published. Required fields are marked *