Watching the current raft of hyperconverged players go at it in the blogosphere has turned into a movie where I've lost all interest in the plot and characters. Here's just one recent example of yet another intense piece from my colleague Chad Sakac.
The problem is that I'm just not interested anymore. I know how the movie predictably ends.
That wasn't always the case. Long-term readers will remember me going on and on about hyperconverged, etc. etc. Things change. I move on. Maybe you should too?
Here's the pitch: for medium-to-larger IT shops, hyperconverged isn't strategic, it's just a tactical cost-reduction tool. And if something isn't strategic to the people who buy large amounts of IT stuff, it's not strategic to me either. Everything else gets quickly commodotized.
Since I've historically done a decent job predicting shifts in the IT world, you might want to invest a few moments and understand my thinking.
Agree or disagree -- it's up to you.
What's This All About?
Look beyond the buzzword, and you'll find some very simple ideas. A hyperconverged architecture generally involves implementing storage functionality in software and using server-resident storage devices vs. a traditional external storage array.
The resulting environment can be simpler, less expensive and easier to manage with this approach. And then the debates start: who's got the most technically elegant implementation, which environment is the easiest to manage, has the best feature set, is the least expensive, and so on.
At one time, I thought the idea was pretty revolutionary, and devoted much time to it. And then I stepped back and realized it was more of a band-aid then a cure.
Looking At The Enterprise Application Landscape
Simply put, IT's core job is to deliver the applications people want to use. But not all applications are created equally, are they?
One bucket is clearly about taking the cost out of application infrastructure that can't justify something differentiated. Think virtualization, hyperconverged, and all that.
And another bucket consists of the enterprise applications that the business uses to run the business: ERP, SCM, financials, and so on. You'll rarely find familiar x86 virtualization, or hyperconverged approaches that use it.
Maybe separate buckets for things like VDI, or big data, and so on. Every decent-sized environment is a little bit different.
Here's the point: enterprise IT thinks about each bucket very differently. Yes, you will meet zealots who think that every class of workload can run on a single class of infrastructure, but that noble idea doesn't scale well beyond very modest environments.
For the cheap-and-cheerful bucket, it's really all about achieving the lowest cost. For the bet-your-job workloads, it's all about delivering predictable results at all times, followed by cost.
And the differences in approach matter to the folks who pay the IT bills.
Generic Infrastructure For Generic Workloads
One of the underlying design principles of virtualization is to attempt to treat all workloads relatively equally. Pool your resources, everyone gets their fair share. That's its strength when it comes to generic workload consolidation.
Although there are certainly knobs that try to single out especially important VMs (e.g. CPU affinity and the like), these are mostly suggestions, introduce unwanted complexity, and aren't generally effective for most differentiated workloads.
What's a differentiated workload?
Big, honking databases and the demanding enterprise apps that use them. Large scale open analytics based on Hadoop. Real-time in-memory analytics. High-end transactional systems. You know, the really demanding stuff.
Typically, these workloads deliver oversized economic value back to business as compared to generic workloads. So the business -- and IT -- thinks of them quite differently.
"Fairness" isn't top-of-mind, getting results is. Not all workloads are created equally.
While it is theoretically possible to run these demanding workloads in a hyperconverged or typical virtualized environment, you'll almost never find this in the wild. And for a good reason: that wasn't the design point.
To be fair, virtualization (and now potentially hyperconverged) has done a great job of helping IT take cost out of the "long tail" of generic workloads (aka craplications) that can't justify isolated or differentiated infrastructure.
But, as always, there's an end to the road, and it isn't pretty. As I've said, we've all seen this movie and we know how it ends.
Racing To The Bottom
If you're a student of this industry, you know how the movie plays out.
A category gets established, initial players are somewhat differentiated, over time everyone ends up doing pretty much the same thing, the category gets largely commoditized, and it ends up being a race to the bottom.
The only question that then matters: who can do it the cheapest?
Servers and desktops have been there for a while, big pieces of the storage and network market are clearly heading in that direction, and hypervisors aren't far behind.
Now consider hyperconverged: who will be able to justify a premium in the long term, and why? Its mission in life is consolidating generic workloads on generic hardware infrastructure as cheaply as possible.
Sorry, I can't see how the entire category can avoid the black hole of commoditization, which is just one reason why I'm losing interest quickly.
And Then There's This "Cloud" Thing
Let me share even more cynicism: what's the cheapest place to run generic workloads? Yep, a public cloud. Why invest in equipment, software and people when you can just swipe a credit card for what you're going to use this month? And -- before long -- easily move to someplace better/cheaper/faster should the need arise?
To be fair, there are many reasons why public clouds aren't more popular for this use case today, but that shows every sign of changing before long, especially as better workload portability and control planes hit the market. We've already seen a race to the bottom for generic IaaS pricing, and there's no reason to believe it shouldn't continue.
The few surviving hyperconverged vendors will find themselves increasingly compared to public cloud services, as their only raison d'etre is saving money.
Unfortuantely, none of the hyperconverged players have a public cloud, nor the resources to build a viable one.
A quick side note: I am continually amused by the hyperconverged vendor cloudwashing that ignores a fairly obvious truth. Being "AWS-like" is not the same as being AWS, nor is being "Google-like" the same as being Google. That's like saying I'm as fast as Usain Bolt because I wear the same shoes.
But What About Cloud-Native Applications?
There is an interesting school of thought that deserves a mention: cloud-native applications that are designed to run well in generic environments, whether they be on-premises or using generic IaaS. And, no doubt, most new applications being created are moving towards this model.
But look at the proposition from a purely business perspective: invest many millions of dollars and several years to re-architect and re-create the essential applications that are running the core of the business today, just so you can have the privilege of eventually running on more generic infrastructure? Errr, when do the savings start?
Yes, you see it being done in a very few situations; but for most it's just not a reasonable option. Which helps explain why mainframes and UNIX systems and bare metal and similar are still with us.
Briefly putting on my Oracle hat, it is fair to say that Oracle has an offering that falls into the hyperconverged category, although it is certainly not marketed that way. It's the Oracle Database Appliance, or ODA.
It is extremely differentiated, as it was designed by the same team that is responsible for the Oracle Database. Yes, that is an unfair advantage.
It is not like -- nor does it attempt to be like -- generic hyperconverged approaches. If you've got a handful of oh-so-important applications that use the Oracle Database (and there are a LOT of those), it immediately becomes an interesting offering.
Otherwise, not so interesting.
To sweeten the deal, the same set of capabilities are available via the public Oracle Cloud via DBaaS. Workloads are easy to migrate back and forth as it's basically the same software running in two different places. As a result, cloud just becomes an extension of what you're already doing today.
The Life Cycle Of An Industry Category
In our infrastructure industry, categories are a result of both supply and demand: technology innovation and how IT organizations prefer to consume those technologies. They born, garner initial interest, mature and eventually sink into the sea of marketing mush.
You can ignore the category, and thus miss out on all the excitement and customer interest. You can join the category and battle it out with all the other players, thus accelerating the commoditization of the category. You can take a deep breath, and establish your own category, which -- if successful -- will quickly attract other players and eventually commoditize.
Or, you can choose to transcend the typical category game by precisely targeting an enterprise IT need that existed decades ago, and will likely exist decades from now: optimizing for the critical and demanding workloads that power the core of any modern enterprise.
When it comes to the hyperconverged category, I've lost all interest. We all know how this movie is going to end.
Like this post? Why not subscribe via email?