With all due respect to industry analysts, I’ve now been able to create a fairly accurate model of what most people are looking for — and it’s not exactly the picture that the analysts are painting.
Sampling bias aside, I’m finding that the more I talk to people, the more the observed customer shopping lists tend to converge into a very short, understandable agenda.
Keep in mind, the hyperconverged segment is moving fast, with many players and interesting choices. What was new and innovative a few years ago is simply table stakes today.
There’s now been enough real-world experiences that there are more than a few fully-informed buyers out there. And they certainly have strong opinions!
What’s All The Fuss About?
Hyperconverged buyers are looking for a simpler, cheaper infrastructure model than the typical disparate component approach. To the extent that compute, storage and networking can be collapsed into an integrated, all-software virtualized stack running on small, standard servers, that’s a win.
Put simply: they want to spend less on people and products, and spend more on doing things that really matter to the businesses they serve. Not an unreasonable goal …
But the market quickly segments after that — every vendor is offering a different combination of attributes. Some appeal to one segment, others appeal to others.
In my conversations with over 50 hyperconverged customers, here’s what I’m finding matters to them.
Does Integration Matter?
VSAN is deeply integrated with vSphere and the rest of the VMware universe. Other hyperconverged solutions can manage a few integration points, but not hundreds. With a non-VMware appliance approach, you’re essentially buying two products that are designed, sold and supported separately.
Does this matter to hyperconverged customers? Yes, and in a variety of ways.
I’ve spoken to people who’ve used VSAN as well as other hyperconverged products that use vSphere. They uniformly comment that day-to-day operations on the non-integrated products involved going back and forth between two environments: the native hypervisor and the vendor-supplied management GUI.
They tell me it’s livable, but not as slick as having everything under a single GUI.
More concerning, they tell me it’s possible to make perfectly acceptable changes — or enable specific features — in the hypervisor that are not well understood or recognized by the vendor-supplied management GUI. Ouch.
They say that learning curves are shorter and more predictable with fully-integrated environments: e.g. if you know vSphere, you know VSAN. That’s especially important if you’re using less-than-senior talent for day-to-day operations.
And then there’s support: these folks are already signed up for VMware support if they’re using vSphere — do they really want to put in a separate support call for the non-integrated portions of their hyperconverged environment?
Less is more, they say.
Does Choice Matter?
They tell me yes, and in a surprising variety of ways. VSAN supports a wide range of infrastructure consumption models: ReadyNodes, EVO:RAIL, the forthcoming EVO:RACK and — of course — roll your own from a very extensive HCL. The non-VMware appliance guys have far fewer choices, and somewhat limited configuration flexibility.
Maybe they’ve already standardized on a server vendor, and would like something consistent with what they already have. They’ve integrated this server vendor into all their processes: procurement, installation, operations, support, refreshes, etc. Why should they be forced to buy another server vendor’s product?
Maybe they like the idea of being able to expand in small increments, e.g. a single disk drive and not having to buy another appliance. Maybe they just don’t like the idea of being locked into a single hardware choice. Maybe there are some places where they want to use appliances, and other places not so much.
Their list goes on and on.
I wouldn’t have initially guessed this would come up so frequently in conversations, but it does — almost every time. It’s turned out to be a big deal for many hyperconverged shoppers.
Does Performance Matter?
Sometimes no, but often times yes. Most aren’t expecting to push a hyperconverged cluster so much at the outset, but — natural human behavior — they very much expect to load it up with as much work as it can handle before any performance limits are reached.
The higher those performance limits (and the less resources used), the more VMs they can potentially cram on to their existing cluster — and get a much better value in the process. More bang for the buck.
There’s another aspect as well: no one wants to spend time isolating and resolving application performance issues. The more inherent performance a product offers, the less likely it’s going to be that you’ll be dragged into some sort of performance issue.
Our internal tests have consistently shown substantial and meaningful performance differences — using identical configurations — between VSAN and non-VMware appliance-based alternatives.
For the customers who have had the luxury of doing their own head-to-head testing, they’ve seen it as well. And they tell me it matters to them.
Does Cost Matter?
Yes, obviously. It would be a rare IT person indeed that didn’t care about bang-for-buck to at least some degree.
VSAN directly leverages the most efficient IT hardware distribution and support channel in the market today: those of the server vendors. It’s a mature, proven, competitive and cost-effective model. Nothing can beat it in terms of reach and effectiveness.
The non-VMware appliance vendors have to purchase equipment, bring it into their factories, ship it out again — as well as build their own one-off installation and support networks. None of that is cheap, and it’s reflected in the prices charged.
One of the things we uniformly hear from VSAN customers is just how much more cost-effective the VSAN solution was compared to other appliance-based hyperconverged solutions. While actual numbers will vary, “half the cost” isn’t unusual.
Is There More On The List?
Certainly: everyone has one thing or another that matters specifically to them — specific feature support, global coverage, flexible licensing, multi-hypervisor support, exporting storage protocols, etc.
Certainly, all are relevant, but apparently not as important as the short list: integration, support, choice, performance and cost. In each and every conversation, these are usually the “trump cards” that end up deciding the head-to-head evaluations.
What’s on your list?