The ongoing evolution of HCI – 2017, 2018 and beyond – in three parts.

In 2016, EMC (and then Dell EMC) and VMware started with several goals – one of which was to become #1 in the HCI market by the end of 2017. That mission was accomplished mid-year 2017, so check.

That said, as the calendar comes to a close, and I reflect a bit on the HCI market – I know we’re just getting started.

I also know that people will try to make this black and white. I’ve noticed that if I write a post on a topic, people sometimes assume it’s the only side of the story, or an official position.   It’s a weird accidental byproduct of Virtual Geek being a personal blog (off domain, I pay for it myself, and I compose during strange hours). Virtual Geek, remains my own labor of love – but naturally biased by what I do at work.

I’ve also found people want to be binary, to polarize every topic. People will read into this post series that it’s about CI **OR** HCI. Hint: it’s not – the Converged Infrastructure market will be the same size as the HCI market through 2020. Others will read into part 3 of the post that I’m saying that the “vertical stack wars” era means that there isn’t a need in the market for horizontal, open ecosystem CI/HCI stacks. Nope. Those are both are going a step too far in my humble opinion.

IT Industry transitions simultaneously are fast (grow rates shift seismically, and new ideas take hold quickly) but also take a long time (big long tails and complex systems with material and real inertia).

Back to the “where do I see HCI going next?”

There are two distinct HCI mega-trends that we are simultaneously leading (the largest player in the HCI ecosystem and are part of (in the broader ecosystem).

Here’s I’m not talking about the shift TO HCI from traditional 3-tier IT stacks of server/network/storage. That is a transition is in flight (again, CI will be as big as HCI until a crossover I believe will be in 2020).

The drivers for HCI are basic, simple and clear:

• A fundamental IT need for simplification/automation through software (much lower costs to operate, and much better ratios of people/time : value)
• The ongoing shift of value to software + industry standard hardware (faster tech adoption curve + scaling model)
• The increasing recognition that infrastructure is something to be consumed, not constructed – and that shift keeps moving “northward” in stack (never ending commoditization at the bottom layers, and shift up the value stack).

What AM I talking about?

There are 3 essential strategic observations about the market from where I sit – and I’m reflecting on as we enter 2018:

1. There are two HCI “ways forward” that are emerging. These two that fall into the natural “build” to “buy” continuum.  Here, it’s about two ways that customers consume HCI: Software led + open ecosystem hardware (“Build”) and Integrated Systems (“Buy”).
2. It’s NOT about HCI – it’s about cloud.   The HCI value proposition is evolving northwards into turnkey cloud stacks (IaaS, PaaS, CaaS, DaaS), and increasingly I’m finding (and everyone is finding!) that you need the simplification of HCI as the “base strata” of a sustainable cloud stack.
3. That we are in the first pitches of the first inning of an era of “vertical stack wars”.   This isn’t just about us – there are many examples across the industry.

I think that these will be “challenging ideas” as they butt heads with things people have been doing for eons. I think that it means we’re also entering an era where ecosystems that have been around for decades will be challenged.

Personally, I’m determined to tackle these with the same ferocity and willingness to self-disrupt that has been necessary in tackling the first chapters of the HCI industry transition.

I’m convinced that these 3 simple observations will be taking a lot of my own cycles, and I suspect the cycles for many as we all participate in the next orbit around the earth, and I’m noodling furiously on it.

Read on for more!

PART 1: Two ways the market is choosing to move forward with HCI…

One of my favorite people to follow in the twittersphere is @kelseyhightower.  Kelsey is a Staff Developer Advocate at Google, and one of the people in the Kubernetes community with a “large impact radius”.   Check out his github repo here: https://github.com/kelseyhightower

Where am I going with this?  Consider these three posts:

These three tweets are fascinating for me – because they make it clear: the “‘build’ to ‘buy’ continuum” is a generalizable idea, perhaps a reflection of human nature and personal perspectives.  None of these tweets are about the infrastructure domain, but the layers above – and the sentiment/learning is completely applicable there, but also above, and below.   These tweets represents the “buy” and “build” choice.

• The first is a link to a github repo to help people learn Kubernetes from the ground up – no scripts.  For someone who wants to learn, and to have ultimate flexibility and control, a great way to start.   This is was a super-popular tweet, and a great resource.   To me – this highlights the great burning desire for people to learn, to play.  “Builders” are everywhere (I’m one myself).
• The second started a huge dialog/flamewar – read the tweet stream.   This is fascinating because I think Kelsey is reflecting something I see.   The reaction highlights that often people underestimate the power of the platform layer “above” them.   You can imagine that people who LOVE playing at the container orchestration layer found this tweet to be “blasphemous”.  It’s also interesting because it highlights that when you challenge the value or even point out the trade-offs of building to a “builder”, the arguments about lock-in, closedness come fast, and they come furiously.
• The third is particularly fascinating to me, and not only because Kelsey said it so succinctly, and so much better than I do 🙂   He so accurately captures the trade-off.   He captures that often people have to have the experience of building (to learn, including learning how hard it really is to maintain and sustain).

With a year under our belt, I can say with confidence that this choice is playing out clearly in the HCI market via the two ways people like their HCI:

1. Software-led + open hardware ecosystem (“build”)
2. Integrated Systems (“buy”)

Its funny to see this not just through the lens of “gut” or “opinion” – but black and white data.  

I see all the data on the breakdown of customers that take vSphere + vSAN and pick the open ecosystem of servers that are part of the vSAN ReadyNodes HCL program. Ditto with VMware Cloud Foundation on same said open ecosystem of vSAN ReadyNodes.

Whether they are doing it consciously or not – these customers are examples of the Software-led “build” approach to HCI stacks.

Conversely, I see the data representing the customers that pick integrated systems – the corresponding stacks to the above manifesting as VxRail and VxRack SDDC.

Integrated systems are not simply bundling or factory load of the software-led + open hardware ecosystem – it’s a whole set of IP (intellectual property), software tools, engineering and support mechanics that mean that there is not a “software/hardware” distinction.   

It’s critical to grasp that core distinction: “build” choices represent improvements over what you do today – and you retain the responsibility of how it works; “buy” choices represent a transfer of that responsibility to someone else.

What does the data show?

The data shows that the “build” marketplace relative to the “buy marketplace” is somewhere between 50% of the revenue total and 60% of the revenue total. This has held up to be remarkably consistent all year long.  

Between the consistency (and here we’re talking about many, many thousands of customers) over time – and the fact that it’s not just us, this suggests this is something fundamental.

Who else is doing this? Nutanix is an example – see their position on trying to transition to being a software company, and changes in how they compensate their field only on software – encouraging their customers to pick their hardware in an open ecosystem (BTW – this is all public info in their earnings calls).    We have some interesting thoughts on this as you can imagine – and it likely isn’t what you think (but that’s for another blog post).

Microsoft is an example where their position on Azure Stack is the other way – only being offered in Integrated System form… but where they charge for their software being consumed on said integrated systems.  

Net: I think the HCI market having these two variations: 1) software-led, open hardware ecosystem (“build”); 2) Integrated Systems (“buy”) is a fundamental reality of the HCI market.

Now, which one of these is “right” or “better”?

That’s not the right lens. They are different – and it’s important to be thoughtful (and honest) in which is right for you – consider Kelsey Hightower’s quote:  “Build vs Buy.   The challenge is understand what you can build, and maintain, may not be better than what you can buy or adopt.  Sometimes you have to build it before making that decision.”

Now – what happens over time?   I don’t know.   I suspect that over the long arc of history, there a couple things that play out:

• A trend towards “buy” for things that are common.   This takes time for any set of technologies to sink into the zeitgeist.    This is offset by a constant trend of new “build” layers appearing on top of the commoditized layer.
• Ongoing commoditization and automation in the “build” domain. 

That said, while features/functions vary over time (and there’s a never-ending treadmill of commoditization of the bottom part of integrated systems value and life-cycle automation, with net new value and innovations constantly being added in)… there are certain intrinsic pros/cons, or said otherwise value/trade-offs in these two approaches.

Consider these trade-offs and apply them not only to what I do at Dell EMC, but as a more generalized observation about the HCI market (and frankly “build” and “buy” choices more generally) as a whole.

Now, I have a strong personal opinion as you can imagine. 

1. If we ever stop offering these two choices, customers will be pissed – they like choice.
2. At the same time, I think customers need to question long and hard the value they get out of building things themselves, and I would encourage you dear reader to look into your heart.

This is a “challenger” dialog to be sure.

I’ve been an Exchange admin in my career. I’ve been an engineer at a startup helping build a product. I have built many a vSphere/vSAN cluster in my days, and I LOVE it. I like to build, I like to play. The intrinsic values of flexibility, broad ecosystem of hardware to choose and control over specific features is a strong siren call.

That said – I rarely think practically about how much time/effort I spend in that zone.

Likewise, in many cases, I’ve found that customers have a hard time putting a number on “operational expense of system-level integration”, and struggle when they measure it against the very clear “price premium” of integrated systems.

BTW – I’ve found that the price premium of integrated systems (as someone running very large business that does this) has an upper-end maximum.

Go above this, and it becomes too much for the market to bear.

Below that – it’s a function of just how good the integrated systems experience is – ergo, how much do you REALLY offload from the customer, and how good are you at explaining that value to the market at large, and to a customer specifically.

It’s important to understand that you can end up at the same place technology stack-wise using a “build” or a “buy” approach.   It’s also important for each and every customer to think through what’s right for them.

I talked about this idea here – but my own thinking was not complete, and I don’t think it was adequate.  I had just left a customer meeting where we didn’t explain the difference well enough, or the customer didn’t agree with our explanation – and I think I let my frustration show. There are very legitimate reasons people go one way or the other.

Let’s look at ONE example in more depth.

In particular, consider the process of doing a lifecycle update of an HCI stack through the “builder” lens and the “buyer” lens.

When a customer takes a Software-led (“Build”) approach – they place a lot of value on the fact that they can tap into a broad ecosystem, leverage the hardware vendor they have/like. They are perfectly find in carrying the integration workload. VMware will keep making this easier for them (this is the constant over time commoditization of the “base”).

• First – they acquire the software first – and then pick hardware by evaluating against their criteria. In the case of vSphere/vSAN, the customers picks vSAN ReadyNodes from the support matrix – which is simple and visible here.
• When they do an update, VUM with vSAN 6.6.1 will HBA firmware issues (an example of the ongoing simplification/automation in the open ecosystem)
• They can use VMware’s vSAN Configuration Assist tool to catch and remediate HBA firmware gaps relative to the vSAN ReadyNode HCL.
• If they are using Dell EMC PowerEdge, they are perfectly happy to use iDRAC and scripting to do other firmware updates (bios/NICs, SSDs, etc). People that love this get into bar fights over iDRAC vs. ILO.   If you’re one of these people – you’re likely a “builder” 🙂   These people accept/recognize (even if they aren’t conscious of it) that they own doing this right.
• They like using the server vendor tools (again, if they are using Dell EMC PowerEdge in this case it would be OpenManage Essentials vCenter plugin in) to manage their hardware separately.
• They may pick a higher-level orchestration/automation engine to coordinate these tasks
• They completely understand, and in fact WANT their support from VMware to be from VMware, and their support from the hardware vendor from the hardware vendor.

This reflects the intrinsic benefits of the “build it” approach to HCI (tons of flexibility, tons of control) – but the customer accepts (consciously or not) the trade-off of owning the integration and support model. There is someone at the customer who accepts, embraces (relishes?) the process of integration testing/validation, automation, etc. In fact, often those people don’t even acknowledge, and sometimes dismiss the trade-off that they are intrinsically accepting.

Conversely – all those exact same steps are in essence embedded in the integrated system model – someone else does it so you don’t have to.

• The integrated system vendor owns the hardware selection. In the case of VxRail and Dell EMC’s vSAN ReadyNodes – we work to make these match as closely as we can. There’s a whole whack load of testing and integration. We push as much as we can into the vSAN testing cycle and are working to make them as coincident as possible. But, there’s also testing into other parts of the embedded stack (like VxManager that does some stack-level management, integrated fault management and alerting systems, and integration with RecoverPoint, Cloud Array, Data Protection)
• When you do an update of an Integrated System, all the hardware/software elements are integrated not only in testing, but also in the update process. The steps noted above are integrated into the offer, and the update in the software. There is a internal REST API call to “update system” – which then goes about all the steps. This can be batched and automated easily, because all the steps are already automated. Unlike in the “build” case where the customer is integrating the stack, in the “buy” case it is already integrated. That means, by definition a trade-off in the loss of open ecosystem choice.
• The Integrated System customer does NOT want as much choice. They don’t view that as a trade-off, they view it as a benefit. They want to get out of the business of putting the stack together and maintaining it. That customer accepts that it’s going to come at a premium to the “sum of the parts”, because there is more than the “sum of the parts” (the “sum of the parts” in this case vSphere/vSAN and a Dell PowerEdge server + additional software and data protection). The incremental ingredient is the embedded integrated engineering / integration / support – and the software that pulls it together.

To be very clear, any example where someone claims that a “bundle” is the same as an integrated system I would humbly suggest doesn’t understand the delta.   The easy test is to ask questions which poke at the “transfer of responsibility” that is fundamentally the delta of “build” and “buy”.

I’ve seen this error get made – sometimes by customers, sometimes by SOME people at a customer (usually a single customer has “builder” advocates and “buyer” advocates). I see this error get made by our own teams that specialize in one part of the stack or another.

Integrated Systems are a non-trivial lift.  Above and beyond all the great humans we have building software at VMware and software + hardware at Dell EMC are the ingredients that go into Integrated Systems, we literally have hundreds of people working on making sure that VxRail and VxRack SDDC are the best Integrated System manifestations for our VMware-vertically aligned stack. Uniquely – we have both offers from one place for a common stack. While there is a broad ecosystem for vSAN, for VMware Cloud Foundation (representing “software-led build”) – VxRail and VxRack SDDC are the Integrated System manifestations.    The same is true further up the stack into IaaS/PaaS/CaaS domains – but more on this in the next post.

By the same token – anyone who suggests that the only way for customers is the integrated system approach doesn’t appreciate how much of the market actively wants and chooses the software-led “build” approach for its intrinsic benefits and trade-offs.   I have people on my own team that can get too passionate on this topic.   I have an opinion – but my opinion also recognizes the reality I see in the marketplace.

Also note that in the example above you get to a very similar place (how the stack gets life-cycled), but in a totally different way, and with two totally different operational models.

I’ve found more often than not – customers have a very clear preference one way or another.

I’ve also found that as you work with the IT administrators, they tend to like the “build” approach, and as you work with the IT senior leadership – they tend to like the “buy” approach.

I think this is a dialog that needs to happen in every IT shop, and they need to come to their own conclusions.

My 2 cents? I think we’re on the steps of an inevitable journey where infrastructure is consumed, not constructed – whether it’s private or public, whether it’s on-premises or off-premises.

The next 2 posts will reflect on two linked observations – the move up the value stack from HCI today to full IaaS, PaaS, CaaS stacks, and also the emerging era of vertical “stack wars”.

What do YOU think?   What are your experiences – positive, negative – with regard to the “build” to “buy” continuum?