No doubt you’ve heard plenty about the concept of hybrid cloud (or even hybrid IT) recently.  Personally, my Twitter timeline has been rampant with opinion pieces (some good, some bad) and your usually array of bickering between the various factions as they have to do all they can to represent their brands.  My intention of this post is not to enflame those factions, but invariably, I’m sure I’ll have to defend my comments.  What I want to try to do is get down to the reasons as to why hybrid has become a rather hot topic and break down the various approaches that are now coming to market.

Why Hybrid (or even Multi-Cloud, for that matter)?

Well, first and foremost, if you like protecting internal silos and continuing the rationale that, as an infrastructure person, it’s your way or the highway when it comes to IT, you’ve missed some awfully big memos recently.  Not only that, YOU are part of the problem.  Most of these hybrid use cases stem from ineffective IT departments.

Let me explain.  It’s currently late October 2017.  Some of you are still provisioning internal systems like it’s 1999.  I’ll cut a little slack that there might actually be some shred of a business use case, however, I’d bet that most of it stems from the scared nature that somehow, as an infrastructure person, you aren’t going to be important in this new world.  So, rather than get on the wave of progress, you’ve chosen to entrench yourself in ancient IT methodologies and do your best to scatter as much FUD internally about anything that isn’t what you know.

This has led to extreme dissatisfaction between businesses and their IT departments.  The business, usually in the form of some sort of application development group, decides to circumvent the process and goes rogue.  Public cloud is leveraged, usually without the approval of IT, and thus are given tools to finally catch up to their pace.  Whether you want to admit it or not now, you and your IT department are in direct competition with the likes of AWS and Microsoft Azure.  And many of you are failing miserably.

Latency

So, your application developers went out and tried public cloud and while they like the overall interaction capabilities, the realization is that they need access to on-premises resources.  Unfortunately, line rates and long distances caught up to the application and latency reared its ugly head.  No matter what was tried, whether it’s faster connectivity with AWS Direct Connect or Microsoft ExpressRoute, it wasn’t able to solve the latency problem.  The need was to put the legacy components necessary to new application development in much closer proximity to the new breed of applications being developed.

Enter the Solutions

At this point, this is where the solutions deviate.  At their core, many address the latency problem but depend on different directions as to where workloads are shifted.  For instance, VMware Cloud on AWS wants you to move your legacy workloads (not just lift and shift, but due to the need to refactor applications around it) out of your datacenter and into an AWS datacenter.  Again, this will likely solve the latency issue, however, I still don’t feel this solves any sort of regulatory or sovereignty issues related to that data.  The focus of this blog post isn’t about those issues, so I’ll refrain from deep diving into it.  Just know that I consider latency AND sovereignty to be a couple of the major issues towards public cloud adoption.

That leads us to Microsoft’s solution in Azure Stack.  Unlike the VMware offering, Microsoft wants to try to address this problem in your datacenter, thus making the Azure extension feel much more like yet another private cloud service offering.  Selling Azure Stack as just a private cloud solution, unfortunately, does sell the offering well short of its intended mark.  There are some advantages to Azure Stack that may not be available in the VMware offering.  For instance, with being able to take advantage of everything in your datacenter, non-virtualized workloads can be accessible as legacy entities (my primary example would be something similar to an AS-400 system, where the processor types prohibit creation of a virtual machine on an x86-based platform).  I will admit, however, that this example is a very limited “advantage”, but in many enterprises, it does exist.

Thoughts

Whether the two camps (plus countless others that will crop up…cue the recent Google Cloud Platform and Cisco announcement) want to admit, they both are trying to address the same problem.  Latency is a public cloud adoption killer.  The major differences come down to what sort of legacy workloads do you have running on-premises and what the plans are for any sort of cloud-native application refactoring your organization has planned.  Sprinkle in whether you believe that your investments into certain legacy infrastructure tool sets are worth continuing (VMware really wants you to know you don’t have to get rid of your VMware admins, as an example, because someone still has to operate a vCenter instance) and you got a recipe for making a major decision.

If anything, what these moves have proven is that prior statements by some of the major public cloud providers were, in fact, categorically false.  No, you can’t run everything in the public cloud, especially if you’ve obtained years of IT baggage (i.e., any enterprise).  Not every IT organization is capable of being a stable for unicorns, nor should they be.  Welcome to the world of hybrid (or multi-cloud), folks.