Vblock DNA, mutation, and why standards are important in converged infrastructure

This morning I had a really engaging customer conversation about Vblock^(tm) Platform standards.  This conversation included the discussion

“Why do all Vblock models have the Nexus 1000V in them, when the basic VMware switch suits my purposes?”

This kind of question is a great opportunity to talk about why Vblock standards are a strength, not a weakness.

But before we get into it, let’s have a word from Joel Spolsky who I’ve admired as a straight-forward talking purveyor of shrink-wrapped software.  If you read Joel’s article Set Your Priorities, he makes an argument for shrink-wrapped software that benefits both vendor and customer by making complex things cheaper and easier to buy.  If you’ve ever tried (and I have) to build a custom Vblock-like system from a loose collection of “best” practices with all the bells and whistles, adding replication and everything else, then unless you’re a mad man you’ll want to use a Vblock next time.  Or rather, the business paying the bills will.

So in my humble opinion, what Joel thinks about software (shrink-wrap better than custom-in-house development) I also think applies to converged infrastructure.  So let’s explore this, using the Nexus 1000V as one example of a Vblock Component Standard, but first a very quick recap of the current Vblock portfolio.

Each model in the series below can be customised significantly in terms of features, functions, sizes, upgradeability, add-on components.  If comparing these to software, think of the different models to be similar to software editions, and the modifiable customizations as installation and upgrade options:

• Vblock 300 Series has four models (EX, FX, GX, HX), with different VNX-backed storage arrays.  Each has different min-max sizes and more features higher up the range, but they all have common network/compute/storage DNA.
• Vblock 700 Series has two models (LX, MX), with different VMAX-backed storage arrays.  Again, common DNA.

The common DNA is really important because this defines the standards of a Vblock.  When VCE thinks about standards in a Vblock, they think of them in categories.  First of all there are the two core, DNA categories, Component and Platform standards:

• Component Standards - these are the reduced set of components from Cisco, VMware and EMC that VCE selects through an engineering process to make up the core DNA of the product portfolio – all series and models share a majority of component commonality, often the only real change is the back-end storage array.
• Platform Standards – this is how the Vblock is combined into a product.  This is also part of the DNA of the product portfolio and describes how the components are integrated and configured at a basic level.

Think of it another way: standards are rules to be followed; reference architectures are guidelines to be customised.  There is a difference between a standard and a guideline, and that’s why there’s a difference between a VCE Vblock and everything else out there.

So we’re back to the Nexus 1000V example: this component is part of the DNA of the Vblock.  It’s a Component Standard, and the way it is part of a specific product like Vblock 300 EX makes it part of that Platform Standard too.

On top of that foundation, every step in the VCE value chain expects the Nexus1000V to be there, from engineering through manufacturing through delivery through seamless support.  Any entropy (deviation from the standard) and it’s like a well run engine misfiring and quality/speed drops:

• Engineering – As VCE expands the portfolio and adds more products to the core, like RecoverPoint, or starts to build out solutions like FastPath for VDI – they all expect Nexus 1000V to be there.  If there are alternatives for each component then VCE needs to increase their engineering efforts.  And remember these are converged integrated systems, so it’s not just about one component, it’s about the architecture it fits in.
• Quality Assurance – VCE has a constant QA effort in labs staffed with significant investment in people, process and technology to make sure every Vblock works.  The more alternative products you add, the more complexity you add and ultimately, because we all have finite resources and time, if you have more products to integration test then you do less tests.  How about fewer products and more, deeper, better tests?  Would you prefer a bullet proof vest to be thicker or thinner?
• Solution Architecture – let’s pick VDI as a solution, but there are many use cases for Vblock that work just as well.  If you have alternative network switches you need to maintain different options in the solution architecture, be prepared to [waste|spend] time comparing and contrasting then putting that into a solution.  Isn’t it better to do this faster with productised approaches with a consistent, core product?  I know so: I have scars to prove it.
• Manufacturing – VCE has the equivalent of a Toyota Production Line in the US and in EMEA.  You can see a youtube of it in action here, but these guys are building many Vblocks per week to a high and consistent quality.  Keep providing alternatives and you complicate this process, introducing risk of reducing quality.
• Seamless Support – the VCE support team (over a hundred support staff with impressive processes and tools: much more than just a number) expect Vblocks to have a certain DNA so they can triage and fix problems promptly.  Customers want high availability, and adding more complexity puts this at risk.

So, in a nutshell: VCE chose the Nexus 1000V as a Component Standard to support our goal of deploying a standards-based platform around the world to a high level of consistency and quality rather (and here’s the tradeoff) than building on-site, hand-crafted, custom-deployments like other converged infrastructure or reference architectures.

Joel Spolsky used to be the Product Manager for Excel 97.  Microsoft shipped millions of units of this product and writing shrink wrapped software is different to writing in-house bespoke software.  There are tradeoffs to doing either shrink-wrapped or in-house bespoke, right?

On the one hand, million-unit shrink wrapped is good because it is feature rich, it works, there’s a massive ecosystem, world-wide established skillsets, and it is cost effective.  On the other hand, it’s not a custom piece of software and there will be features in it that you don’t use.  But someone out there does use that feature.  You could argue that Microsoft product “feature light” products, such as different editions of starter, enterprise etc.  but you also know that at the heart of them is the same code base, all the features are in there, but they are license enabled.  Kind of harder to do that with physical infrastructure, but perhaps with virtual appliances that will happen one day…

As for in-house bespoke software, it is very custom so you can finely tailor it to your unique requirements (if you truly have unique requirements…that’s debatable.  If everyone was unique then why do people put value in reference architecture and best practices?) but onsite hand-crafting doesn’t scale and it can have operational downsides (on time delivery, support levels etc), and let’s be honest: is the chief exec going to bet the business by putting his app on a handcrafted solution that someone can walk away from with a month’s notice?

So, back to Vblocks…they are very much like human beings, really:

1. You can’t change their DNA without hurting them in some unpredictable manner.
2. You can customize their environments, their behaviour, and the way they look.  That means you will always get a Nexus 1000V but you can change how it integrates, operates and is monitored and controlled.

DNA does mutate, sometimes for the better, sometimes for the worse.  Here’s a simple thought (that’s the only kind I have!):

• Healthy mutation is caused engineering standards, that leads to evolution that is useful.  This is a Vblock.
• Unhealthy mutation is caused by entropy by not adhering to standards through mechanisms like configuration drift, leading to an evolution that is not useful.  This is everything else that isn’t a Vblock.

Have a great day!