Looking forward to 2018–Part 2: Hint, it’s not about infrastructure.
- December 22, 2017
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 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.
These examples that tend to “CI” (and others like them) are due to several factors:
- Legacy data service requirements (some of these have very specific legacy remote replication behaviors)
- 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.
- 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”.
- 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).
- 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:
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:
Next up tomorrow, a longer term (and perhaps the most controversial) post: Vertical “Stack Wars” are upon us.