Enterprise Realities Around 'Hybrid' Cloud

Yes this is yet another post about hybrid cloud, but hear me out.

By way of analogy, hybrid cloud is the “essential oils” of tech. The concept makes great promises but the reality of the matter is that there’s really no substance to it. In theory, the hybrid model is supposed to let you seamlessly “move” between your on-premises and your cloud provider(s). Before we even get into the technical impracticalities of this in practice, we should first address the fact that there really is no legitimate use case here.

Many will call out “bursting into the cloud” as one conceivable use case. On paper, like communism, it makes sense. You have a deployment that is comfortably living on-premises when suddenly it gets hit to a point where it needs to scale beyond and into the cloud. Let’s talk about this “need” for a hot second. Where is it coming from? Except in the rare case, bursting is exactly that, it’s a rare circumstance that must be dealt with. Yet here we are literally rearchitecting, at a minimum, our deployment infrastructure for an outlier use case.

Another argument in support of investing the gigantic overhead of adopting a hybrid model tends to be the following: Sure it’s an outlier use case, but it’s the perfect forcing function to promote modernization in our organization and our journey into the cloud.

That’s nobly intended. But your journey to the cloud is going to be relatively complex in even the simplest case, why choose a scenario that is basically going to up-end your status quo through shock and awe and bring mountainous complexity along with it? It’s a disservice to your IT organization as a whole. At a minimum, you’re looking at the following requirements to just establish a hybrid cloud architecture, nevermind a proper cloud presence:

* Kubernetes is somehow going to be involved, so skill your org up here (and buckle up)
* Skill your org up on the cloud provider of your choice
* Make your peace with your current network architecture (which is likely the result of many compromises and short-term path-of-least-resistance decisions over the course of years) because *I guarantee you* it's going to destroy your happiness as you try to extend it into cloud networking models with hybrid in mind
* Rearchitect your deployment architecture because hybrid means "movement" and "bursting". There is really no magic button here.
* Retrain your devs on the new deployment architecture (once you've figured it out) because invariably, your developers probably have their hands in the deployment process far more than they should
* Rearchitect your application(s) that you intend to bring into this hybrid quagmire, inclusive of a brand new data architecture (this is probably the part where you deeply regret the hybrid decision if you didn't already from the networking).
* Prepare to hate DNS even more.
* Figure out what an outage even means anymore in a hybrid architecture. This will probably further complicate your desire for a stable SRE practice due to the organizational trauma of this whole experience.

Cloud adoption is a necessity, to be sure. Even in cost models where cloud turns out to be fiscally more expensive than the current status quo up front, the returns for the enterprise organization as a whole are far greater in the longer term. However “hybrid” cloud, if there can ever really sensibly be such a thing, is the red herring of this current tech era.

Your journey to the cloud should be as boring as possible. It should be comprised of a sensible strategy with qualified workloads to start, with mitigations accounting for skillsets, technical complexity, maintaining the status quo of business operations, and a deterministic switch over of those very same business operations when the time comes. You need a partner who’s going to effectively walk with you here. More on that in another post, I think.

To keep this short, do yourself and your enterprise organization a favor. Before committing to a hybrid cloud model, first figure out why you think it’s a good idea. Then, look at who else has done it successfully, and if that success can be meaningfully applied to your organization. Finally, re-read this post and talk yourself out of it.