The Necessary Evolution of the Hybrid Cloud

But none of these have achieved significant market penetration to date. This is partially because the initial users of Private Cloud vs. Public Cloud were different groups (IT vs. developers). Additionally, most legacy applications weren't designed for the dynamic scaling or availability advantages a hybrid cloud might offer. Furthermore, many IT organizations didn't want to be locked into a single Cloud Computing model that didn't give them price flexibility, geographic flexibility or application flexibility. In spite of all of this, the appeal of "Hybrid Cloud" is still there for many Enterprises that wish to find a balance between control and flexibility, between internal and external resources.

In recent months, this space has become somewhat more complicated (new Cloud offerings from Google, Microsoft, Rackspace, Tier 3 [podcast] and Virtustream [podcast]) and even fragmented as some experts suggest that "Enterprise Cloud" could actually be an internal-hybrid (web-scale and virtualization segmentation, within the same Enterprise). In addition, we've seen:

• The introduction of several public and private OpenStack offerings 
• The introduction of several PaaS platforms based on VMware CloudFoundry (AppFog, Tier 3, Uhuru [podcast], as well as several Microsoft and non-Microsoft .NET environments (Azure, Apprenda [podcast], Tier 3 - IronFoundry, Uhuru)
• The introduction of several *-as-a-Service offerings to augment both public and private cloud offerings (eg. CloudPassage [podcast], CloudAccess [podcast], Cloudability [podcast]

The great news for IT organizations is that all of these new cloud offerings will drive competition, hence better pricing and flexibility for business needs. But the choices also create some new challenges - how to potentially manage many application across multiple clouds?

[UPDATE - July 2, 2012] George Reese wrote this post with his opinion about VMware's overall Cloud strategy, some of which was altered by their acquisition of DynamicOps.

What had been called "Hybrid Cloud" in the past was probably better characterized as "Hybrid Cloud v0.1". In some cases it worked, and it solved some challenges for the earliest of adopters, but it wasn't ready for mass adoption. But we've now moved into cloud maturity levels that should be called "Hybrid Cloud v1.0", where IT organizations (or lines of business) should be expecting greater flexibility:

• Companies should be able to deploy applications (DevTest, Production, various Tier levels) to any cloud through a fairly consistent management framework. 
• Companies should be able to automate the deployment of these applications, whether they are legacy (deployed in VMs), or modern applications (may or may not require VMs; eg. PaaS or SaaS environments).
• Companies should be able to have visibility and transparency of application costs, application/data geography, and application status/performance across any cloud through a fairly consistent management framework.
• Companies should have the flexibility to treat IT resources similar to other parts of the business, where different business demands require different resources (costs, regulatory, time-to-market, etc.). They should be able to describe the IT need in business terms, not be bound by cloud-specific capabilities.
• Companies may opt to evolve their Hybrid Cloud strategy to not be a mix of internal and external resources, but entirely external Cloud resources, across multiple cloud providers and deployment models (IaaS, PaaS, SaaS). 
• Companies should realize that "the journey to Cloud" may be more complicated from a people and process perspective, so it may make sense to create a fence around the legacy environments and look at more modern process and technologies to move IT forward. 
• Relying on a single "open API" to drive you Cloud strategy may sound good today, but may be cause for concern down the road.