From Private to Multi to Hybrid Cloud in the Enterprise - What, Why & How / by James Kelly

From the results of recent RightScale and Gartner surveys on cloud, hybrid cloud is the ideal goal for about 75% of enterprises, especially with increasing importance on the near-seamless compatibility with the quickly growing public side. Let’s break down the differences between the private cloud, multi-cloud and hybrid cloud, so we can define them, investigate why hybrid is the destination, and see how to climb to such hybrid cloud heights.

 Private cloud: In this case we’re looking at a single in-house data center or site of data centers, orchestrated as one internal private cloud. This is a building block for hybrid and multi-cloud.

Although my blog title begins with private, private clouds are less common than you may think because IT shops will often puff up their chest so to speak, to inflate their cloud ego that their virtualized data center is a private cloud. Knowing that enterprises and vendors do “cloud wash” and mix virtualized and software-defined data center messaging with cloud messaging, we probably ought to define our cloud in less “cloudy” terms. The NIST definition of cloud computing offers a concrete definition that includes the characteristics of on-demand self-service, broad network access, multi-tenant resource pooling, rapid elasticity, and measured service (SDN Era Side Note: notice how the values behind these traits align with the values of SDN – I guess that’s a separate blog though). While cloud service and deployment models differ, traits do not. Put differently, one can think of the characteristics of prominent public clouds like AWS, and ask if one’s private data center IT meets those same principles. On the journey to really achieve these cloud characteristics, different enterprises are at different places and moving forward at different speeds.

I often liken the journey to climbing Mount Everest. There are a number of basecamp milestones that one usually passes en route to the peak. Most enterprises are taking these milestones as steps in turn from their history of being entrenched in the valleys of IT silos. Some have the luxury of little legacy IT and are able to leapfrog to higher basecamps, just like some climbers take a helicopter ride as far as possible up the mountain. In any case, the path is not simple and straightforward, and without proper preparation in future-proofing for the final destination, like climbing, what gets you part of the way, may not work to get to the summit.

 Multi-cloud: Multi-cloud is the notion of multiple interconnected private clouds. The clouds are interconnected with unified monitoring, management, and automation across globally distributed private clouds.

 Hybrid cloud: A lot of enterprises—at least those not constrained by internal data locality regulation—are already using public IaaS and PaaS cloud resource elasticity or virtual private clouds—managed or hosted by a public provider. To elevate their game to hybrid cloud, they need a better way to integrate management, or in other words hybridize it, with their multiple private clouds. Like the multi-cloud notion above, they seek to unify and orchestrate applications, software platforms, and infrastructure resources with a centralized system working across private and public clouds.

Why Hybrid?

The purely private, in-house multi-cloud models described above necessitate a reserve and capital expenditure beyond the current needs of the organization. Furthermore, private clouds don’t offer the public cloud’s as-a-service economics of choosing OpEx over CapEx. Beyond economics, the behemoth size and multitude of public cloud providers offers enterprises of any size a way to increase the resiliency and globalization of their IT footprint.

Personally, I related to hybrid cloud like my credit cards. They give me the elasticity to buy whatever I need on credit margin rather than saving. It can be a lifesaver in an emergency. For a businesses, not buying, but rather investing, elasticity is crucial to business agility to seize a business opportunity. As they say, “luck favors the prepared.” Fully realizing hybrid cloud, enterprise IT can prepare by design for infinite scale.

Getting to the summit: Realizing Hybrid

Getting to real hybrid cloud requires embracing the open source ecosystem. I realize that’s a bold statement. I don’t mean enterprises need to partake in open source projects, but they do need to heed them. Let me explain.

There is a saying I like going around that, “cloud is the new computer.” You’ll recall the terminal-mainframe model, then the client-server model, and now the app-cloud model. Cloud is the new application backend.

We know that COTS servers and storage is the assumed basis for cloud hardware. The network hardware is best served by providing a standard (ubiquitous like COTS) IP fabric, as long as it is scalable. Don’t read this as me saying there’s no innovation happening in cloud hardware. Quite the opposite is true, but the interface it provides is increasingly homogeneous.

The software side of cloud infrastructure is shaping up much the same way whereby a homogeneous platform will benefit applications (the ultimate driver of IT value) and devOps (drives application value faster). Remember the server software battle between Windows Server, UNIX variants and Linux? When Linux became the clear winner, it provided an obvious platform of choice for application developers. Much the same thing is happening today in cloud. If cloud is the new computer, ask yourself what will be the new cloud operating system. The only cloud management platform (aka OS) gaining momentum this year is OpenStack. Just passing its fourth birthday, it now has many robust distributions. I think there is a parallel to be drawn between the previous battle and this one for the cloud operating system. The OS with the largest open source following won the battle. The reason why open source wins this battle has many variables, and nowhere is it more important than for cloud infrastructure on which enterprises require application, application platform, and devops-automation portability across multiple private clouds and the public clouds. For enterprise cloud, the choice of an OpenStack-based cloud-OS foundation clearly aligns them for hybrid cloud success because by design, the OpenStack API hybridizes well with the leading public clouds, namely AWS, GAE/GCE, and increasingly Azure. Furthermore, OpenStack is increasingly the choice cloud OS of the other public, managed, and hosted cloud providers like Rackspace. To summarize what Randy Bias at CloudScaling covers in his Hybrid IT webinar, running OpenStack for the private cloud is the simplest path to hybrid cloud which, for the portability described above, requires approximate hybrid cloud parity between clouds in two ways with respect to a standard infrastructure and interface: functionally and non-functionally. Functional compatibility is required in APIs, in infrastructure (e.g. object storage, block storage, compute, VPC networking), and in other behavior (e.g. configuration semantics and default settings). Non-functional compatibility centers around availability, performance, and QoS. A third axis would also be around the economics because the public vs. private clouds must be roughly the same economically, so that neither is prohibitively expensive to use. OpenStack doesn’t guarantee these parities, but it is the best place to start because a number of distributions and integrating technologies (even from VMware) are focused on these parities, understanding that hybrid cloud is the best objective for customers, and that they drive sales.

I have been saying for a while that cloud infrastructure is simply too important and ubiquitous not to innovate in open source, with open standards and open interfaces, but I must say, I love how Jim Whitehurst at Red Hat draws an analogy for executives from the national interstate highway system to talk about standardization.

So back to my original statement, “hybrid cloud requires embracing the open source ecosystem.” Why “requires?” After all couldn’t we have a highway system that isn’t all freeways, but instead all express toll routes? I wouldn’t want to, but I suppose we could. They wouldn’t be as popular as they are, and they wouldn’t have revolutionized the logistics industry and our travel and commute accessibility. Like I indicated above, the cloud transformation for enterprise IT is done for the sake of a few things. Firstly, it’s motivated by devops automation, built out of programmability, best with open source, and whose portability is hampered by heterogeneous APIs. Secondly, it’s motivated by applications and application platforms. Many of these themselves are increasingly open source and designed for cloud-native scale out. These open source developers will choose to align with communities of their open source kin when it comes to choosing cloud OS APIs so as to optimize their applications for cloud. Furthermore, choosing enterprise cloud infrastructure is vastly more important than choosing something like, say, a smartphone. We know that open sourced Android is a great model for application portability across phone vendors and it has dwarfed Apple iOS in its worldwide popularity. Still, there are a lot of iPhones out there and some people have happily bought and locked into Apple’s ecosystem. Getting bought and locked into closed cloud infrastructure is prohibitive for an enterprise on a far more massive scale of investment, and it’s especially unwise if you’re betting against aligning the public cloud providers building their clouds on open source-based infrastructure.

Please leave your comments and thoughts below on what you think will rise to the top as the new cloud operating system. I know it is a journey of a thousand miles, and some enterprises are just taking the first step. Heck, some are still looking at the map as the technology landscape evolves! Whatever the case, it is a journey fit to organize the best of our abilities as we strive to stake our enterprise’s flag into the summit amongst the clouds.

This was originally published on the Juniper Networks blog and ported to my new blog here for posterity.