Six (or more) Degrees of Hyperconverged Infrastructure
There seem to be a lot of arguments around what is and isn’t hyperconverged, with vendor after vendor saying things like, “Oh, vendor X isn’t really hyperconverged because they don’t do X, Y, and Z, but, of course, we are hyperconverged because we do all of those things.” This is not an issue limited to a single vendor. It seems like everyone is jumping into the space today and glomming onto the term “hyperconverged” because, well, it’s a hot market right now.
Fact: “Hyperconvergence” is a made-up word. The word was not carefully crafted by an independent standards committee. Like many trends in the IT industry, someone coined the phrase hyperconverged infrastructure and everyone ran with it. Over time, though, we’ve seen everyone and their brother either try to clarify what it means or come up with even more terms that just further confuse people. Bear in mind, folks, that part our goal in writing and providing information is to help end users better understand the technology they’re considering. Now, of course, some vendors are more than happy to muddy the waters and other have marketing groups that just jump from trend to trend to trend, never landing on any one thing.
For whatever reason, I’ve actually had people refer to me as “Mr. Hyperconverged” in recent months. It’s true that I’ve written short-form Dummies books for both Nutanix and SimpliVity that discuss Software Defined Storage (SDS) and Hyperconvergence, respectively. I’ve also been writing about the topic for a couple of years now, going even back to 2013 when I wrote a very long post for Wikibon on the vendor breakdown at the time. I’ve also done a whole lot of webinars and white papers for companies, including Maxta, Scale Computing, Stratoscale, and others.
Perhaps more importantly, I spent almost more than 20 years of my career on the end user side of the equation, with 10 years spent as a CIO. I have a very, very clear understanding of the challenges that face particularly SMB and midmarket organizations. And, here’s the deal: analysts and vendors are not doing enough to clear up market confusion. Whether this is intentional of not, it’s a fact.
With all of that in mind, I’d like to propose that we drop the terms that simply muddy the waters. This includes, unfortunately, “server SAN”, which was valiant effort by my friends at Wikibon to differentiate between different solutions but which, in my opinion, has simply introduced further confusion.
Baseline Hyperconverged Infrastructure
In order to be called hyperconverged, a solution must, at a minimum, enable the combination of storage and compute, with application virtual machines running alongside Virtual Storage Appliances (VSAs), SDS controllers, VSAN kernel modules, or whatever nugget of software manages the storage that is local to the node and that integrate storage management capability with compute management capability so they’re managed together in some form. The diagram below provides an overview for what this would look like for those solutions that operate using VSAs.
What this means is that hyperconvergence has been around a lot longer than just the last couple of years. This definition may, for example, include the original Left Hand VSA, which came out in the mid-2000’s. Obviously, today’s hyperconverged systems are far more capable than those early entries, but that’s the nature of the technology market; products undergo continuous improvements.
I think it’s important that the management component be included in the definition. But other than that, as long as the solution brings together compute and storage, it’s hyperconverged.
This means that pure software defined storage systems, such as Nexenta, remain just that – SDS. They are not hyperconverged because the storage remains separate from the rest of the environment.
Beyond the Baseline
Consider other technology market sectors, such as storage arrays. Just because an array might be all flash or might have deduplication or some other feature, we don’t try to rename the whole space. They’re still storage arrays, but just with qualifiers. By approaching the market in this way, we help guide customers down a funnel that helps them to better understand what they’re looking at and it gives us a way to reasonably compare and contrast different approaches to the solution. Rarely would someone say, “well, vendor Z isn’t really a storage array because they don’t do dedupe.” That would be the very definition of introducing FUD into the marketing equation.
So, hyperconvergence is compute + storage + integrated management. From there, everything else is simply a feature. Does vendor Q’s solution do full inline dedupe? Great. That’s easy to compare to vendor T that does post process deduplication just on the flash disks. We’re not out there trying to tell customers that Vendor T isn’t really hyperconverged – again, a made up word – just because they’re not doing the same things that vendor Q happens to be doing.
Personally, as an end user, this is a far more accessible way to better evaluate the various options available in the market. Further, as we see more and more players jump into this space, there must be some kind of baseline definition that can be agreed upon. Never forget that our end goals are to to what’s best for the people that will ultimately use the solutions that they buy from the various vendors in the space