The Hybrid Cloud Misconception

“Hybrid Cloud”, is a common term used in the IT industry. It’s mostly reduced to an empty marketer term, not depicting what the “Hybrid Cloud” should be about. Lets analyze it, and define the true meaning of it.

When people use or think about the term “Hybrid Cloud” I believe they assume one of these two cases.

Public Cloud Migration

This scenario is about enterprises, having both a legacy datacenter for older workloads, and newer workloads running on AWS/Azure/Google etc.

They are migrating some of the applications that will benefit from better agility enabled by the public cloud, and while they do so will have to control costs, and maintain IT governance and control over both environments, which are very different by nature.

Existing Workload Mobility

This scenario talks about enterprises, having applications that migrate as necessary from private to public cloud (often, monolithic apps). These apps are being moved without any changes to the code base. They are just an effort for CIO’s to claim they are “in the cloud”. While this may help to bring IT’s TCO down, it won’t actually improve business agility in any significant way.

Breaking the Myth

Let’s stop and break-down these use cases into their actual meaning and business value. Assuming that IT’s main purpose is to enable the business, whether it’s doing it by helping developers move fast, or by keeping the lights on.

In the first ‘public cloud migration’ scenario, the hybrid cloud is nothing more than a migration phase necessity. This scenario, uses the business value in public cloud, assisting the developers to move quickly by using elastic cloud services thus providing business agility. Problem here though, is cloud lock-in, and rising TCO with every month that goes by using services like lambdas, RDS, and object storage.

The second ‘workload mobility’ scenario, helps lowering TCO of existing apps by removing DC hardware, co-locating to the public cloud; but misses the opportunity to enable the business properly by faster time to market. Lowered cost is achieved by keeping the workload itself as is, without using any cloud services other than the basics.

Hence, in order to utilize the best of both these scenarios, “Hybrid Cloud” should really be redefined as “Compatible Hybrid Cloud”.
Where in “Cloud” I mean Public Cloud, and by “Compatible” I refer to developer APIs and every other process involved in deploying, delivering, and operating software.

Lets imagine such a “Compatible Hybrid Cloud”. It’ll provide us with the known costs of our private cloud, helping us leveraging our current investment, together with the modern way of developing cloud native applications. In this approach, we gain both cost control and business agility enabled by faster R&D.

But actually, we don’t even need to imagine such a solution. Such solutions already exist in the likes of Stratoscale’s Symphony or Microsoft’s Azure Stack.


The original term or model known as “Hybrid Cloud” misses the point entirely. Private clouds, as they are built today, mostly focus on automating old & redundant ITSM and ITIL processes.

These kinds of private clouds implementations, mostly undermine the true meaning of cloud. Often missing the business goal of enabling agile R&D and business development.

As Sysadmins, DevOps personas, CIO & CTOs, we should all strive to enable businesses to move faster than before. Having a fast business, means supplying developers with the modern tools & building blocks they need in order to develop applications quickly.

To be continued…

Harvey Specter
Posted at 12:04 am February 19, 2017
Giuliano Bertello

Hi Omer,
Very nice article however to u are also making a big assumption by saying that “fast business = developers can do their job faster”
Not every company has developers and faster business could be driven by something that has nothing to do with developers. Right ?

    Harvey Specter
    Posted at 12:04 pm February 19, 2017
    Omer Kushmaro

    I agree that not every company is “developers centric” but when I was consulting for VISA, TEVA pharmaceuticals, Big Banks, big insurance companies, etc.
    Although they were not “developer centric” companies, they were definitely using in-house developers to enable their business to work digitally. Whether it’s enabling new digital services, or making old operations faster and modern.

    If companies don’t do this kind of transformation, they would not survive facing the Ubers, Lemonade (look them up), Air bnbs of the world, and will die, slowly, but surely.

Leave a Reply