If you’re just catching up, this is a part of a multi-blog post epic saga (ha!) with some things that are on my mind as I reflect towards 2018.

I’d encourage you to read the first part here, which discussed the way I see the HCI market choosing between “build” and “buy” choices, and reflected on how this isn’t a new thing – it’s a debate that occurs at every part of the stack.

PART 2: Hint, it’s not about infrastructure.

Just like I’ve always believed that no human ever woke up and said “I need a storage array” or “I need a server”, or “I need vSphere”.   Likewise, no human ever woke up and said “I need CI/HCI”.

What do I mean?

There are people that THINK they need server/network/storage/virtualization/HCI – but they are delusional, or put more nicely, they lack the macro right perspective.   All infrastructure exists solely to support use cases, workloads, and ultimately applications and business processes.

Infrastructure is purely a means to an end, not an end to itself.

Yes, the infrastructure matters, most of all in it’s availability, but also its performance, it’s economic envelope (which is measured in bunch of different ways)

What’s actually underneath the black drop cloth is not the important thing.  The outcome is the important thing.

This is a point that I think often IT practitioners need to keep very “front and center” in their minds.    The tendency to focus on components rather than systems is the essence of the “build” to “buy” continuum I discussed in part 1 of this blog post series.

So then… What are the outcomes our customers are seeking?

The most requested on-premises workloads are NOT a specific workload per se – but a generalized platform.     This is a switch from years past, when we would spend oodles of time testing, validating, documenting and building lab queens for singular workloads.

The demand has shifted to generalized workload platforms – specifically Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Desktop-as-a-Service (DaaS) and now Container-as-a-Service (CaaS) platforms.

I’m going to be pretty binary in the next statement – the infrastructure underpinnings – the “what’s under the black drop-cloth” under these *aaS platforms are HCI – period.

If the x86 server + virtualized compute/SDS/SDN have become the “bricks”, HCI has become the “foundation”, and these IaaS/PaaS/DaaS/CaaS generalized platforms are the “house”.  Why?

• You cannot build simplicity on top of complexity.   HCI and software defined approaches are simpler.   *aaS models demand simplicity – and have their own stacks with their own moving parts.  

• You cannot automate on top of rigidity.   HCI and software defined approaches are more programmable and API driven – they expect more frequent updates and change.   Trust me, as the person where the “buck stops” for thousands of the largest CI stacks, I know what goes into a life-cycle update.   We do it better than anyone else with VxBlock, and it involves engineering and services perfection, careful planning and maintenance windows.   Conversely, we do remote lifecycle updates of VxRail all day long during business hours.  You simply cannot lifecycle a *aaS on an infrastructure stack that itself is hard to lifecycle.

• You cannot make really good utility economic models on top of things that have massive “step functions” in their base cost of goods.   HCI and software-defined appraoches scale in a fundamentally different way – were “pay as you use” models have a strong benefit, as the infrastructure is supporting a platform where consumption is more difficult to predict.

It’s for those 3 reasons that when you are looking for an *aaS platform – odds are very, very good that the answer to “what is under the black drop cloth” is HCI.

SIDEBAR: Now, so people don’t get binary, let’s talk about where I see the answer under the black drop-cloth being CI, and not HCI.  

• Most SAP HANA and SAP projects are a better fit on things like CI.
• Most EPIC projects are a better fit on things like CI.
• Most Oracle ERP projects are a better fit on things like CI.

These examples that tend to “CI” (and others like them) are due to several factors:

1. Legacy data service requirements (some of these have very specific legacy remote replication behaviors)
2. Long cycle time for application stack validation.   In several of the cases above – the validation process is very geared towards “legacy” stack design, and they are tried and true.
3. Risk aversion (even if it’s not for real technical reasons).   In the list above – the infrastructure is a tiny, tiny fraction of the overall cost, and I find that customers (and the systems integrators/business consultants that invariably are attached to those projects) tend to “stick with what they know”.
4. Unusual CPU/Memory vs. Persistence ratios.   While the old canard that “HCI doesn’t scale CPU/Memory independently” is no longer explicitly true (many HCI platforms have many node types, can add memory/storage to nodes independently, can mix clusters of different node types) – it’s still true that if you need a LOT of CPU/Memory and a LITTLE storage (or vice versa), the economics of traditional CI models win over HCI (even factoring in operational benefits). 
5. Very “bound” multi-year scaling models.  In the examples above, in general there is an understanding of the economic model over a multi-year consumption basis – and in fact a large capital economic step-function is a benefit, not a negative.

Each of these factors have two important qualifiers: “most” and “for now”.   “Most” = there are some projects where either legacy data services are relaxed, or parts of the stack are validated (parts of EPIC are supported on HCI for example), the customers is less risk adverse etc.

But – for the world of IaaS, PaaS, CaaS, DaaS – those platforms are the “raison d’etre” of HCI.  

This is the basis of the “Hint: it’s not about infrastructure”.   The growth in HCI is a head-fake.   The real battleground is “can we make private, enterprise cloud work?”

In Q4 2017, we came to an observation that we HAVE to make our Hybrid Cloud offers that focus on outcomes versus foundational elements simpler, easier, and more aligned.

Going into 2018:

• IaaS = I’m laser-focused on making our VMware Hybrid Cloud on VxRack SDDC simple to acquire, consume, lifecycle – a VMware Ready System, and our Dell Technologies aligned IaaS answer.   We will of course continue to support “build it yourself” IaaS stacks in a wide variety of choices (VxBlock, VxRack FLEX, VxRail – heck, piece parts), with services to put it together.   BUT – if you want “esay button IaaS” – this, along with it’s off-premises instantiation (VMware on AWS) is my focus – period.  
• PaaS/CaaS = I’m laser-focused on making PCF 2.0 (including Pivotal Container Services) on VxRail simple to acquire, consume, lifecycle – a Pivotal Ready System, and our Dell Technologies aligned PaaS/CaaS answer.   We will of course continue to support “build it yourself” PaaS/CaaS stacks in a wide variety of choices (VxBlock, VxRack FLEX), with services to put it together.   BUT – if you want “esay button PaaS/CaaS” – this, along with it’s off-premises instantiation (PCF on AWS/Azure/GCP) is my focus – period.  

Sidebar: Attentive readers may wonder why we use VxRack SDDC for IaaS, but VxRail for PaaS/CaaS.   This is very intentional.   PaaS/CaaS use cases are linked to specific HA design at the PCF layer, as well as correlate nearly 100% with SDN network segmentation – in our case NSX-T.    Whereas IaaS use cases are well covered in VCF 2.3/VxRack today – the VCF/VxRack SDDC roadmap through 2018 will broaden to bring in the PaaS/CaaS use cases.   VxRail can cover these use cases today.    It also means that we MUST integrate VxRail and VxRack SDDC such that customers can start with VxRail and move non-disruptively to VxRack SDDC.  On it.

… This is interesting, because it’s a reflection of two things:

• HCI isn’t about HCI.  HCI is about making private enterprise clouds really possible with sufficient simplicity to scale.   This is not new (we’ve been at this for years), but the learning has culminated in a realization of the need for maniacal focus.
• It is a segue into tomorrow’s topic…

Next up tomorrow, a longer term (and perhaps the most controversial) post: Vertical “Stack Wars” are upon us.