Open Clouds Preserve Choice and Portability

In prior posts, we have seen how open source combined with independent communities, open standards and the freedom to use IP combine to give you access to innovation, put you in control of your technology roadmap, and ultimately help you get the most out of cloud computing. In this final post of the series, we'll show you how another three aspects of openness combine to give you the greatest choice in where and when you run your applications.

Red Hat's approach to hybrid cloud management provides an additional layer of abstraction above virtualization, physical servers, storage, networking and public cloud providers. It's not that we at Red Hat can't offer you a rich set of enterprise infrastructure products of our own including virtualization, Linux, middleware and storage. We can.

However, we also believe that cloud management should not be tied to a specific virtualization and other foundational technology. If all you can do with a cloud is to add a self-service portal and some automation to a single vendor's proprietary virtualization product, you may have gained some efficiencies, but you haven't extended the flexibility of a cloud to all your IT infrastructure. Doing that requires the ability to span physical servers, multiple virtualization platforms and a wide range of public cloud providers, including top public clouds.

It requires being able to deploy to the platform of your choice, not just now but in the future. It requires being able to choose where you run your applications not just now but in the future. You can't do that if you're restricted to a single technology stack. (And you're also locked in to whatever technology or business decisions the owner of that single technology stack makes for you.)

An important capability for ensuring deployment flexibility is a cloud that is pluggable and extensible with an open API.

A pluggable and extensible architecture is important to allowing users to add features, providers and technologies from a variety of vendors or other sources. The API also needs to be open and not restrict how users can make use of associated IP. However, even an open API can be hard to extend and even make use of if it's designed in a monolithic way that makes it difficult to incrementally add to—or that requires interfaces to be written using specific languages or frameworks.

Critically, the API also cannot be under the control of a specific vendor or tied to a specific implementation, but must be under the auspices of a third-party organization that allows for contributions and extensions in an open and transparent manner. As with other aspects of open source, it's not just about availability of source code, but the ability to truly take advantage of the innovation and community leverage that open source can deliver.

Deltacloud, an API that abstracts the differences between clouds, provides a good example of an open approach to APIs. It is a top-level project under the governance of the Apache Software Foundation and is neither a Red Hat-controlled project nor tied to a particular implementation of cloud management. It's accessed through a RESTful lightweight Web API and can therefore be used together with client libraries written in any of a number of languages. It's also modular and flexible in the way it talks to cloud providers when it comes time to deploy to cloud infrastructure, whether on-premise or a public cloud provider. Modular code chunks called drivers are all that need change in order to add an additional cloud provider.

Implicit in a cloud approach that provides support for heterogeneous infrastructure is that investments made in developing for an open cloud be portable to other such clouds. Portability takes a variety of forms, including computing services, programming languages and frameworks, data and the applications themselves. If you develop an application for one cloud, you shouldn't need to rewrite it in a different language or use different APIs to move it somewhere else. Furthermore, a consistent runtime environment across clouds that ensures retesting and requalification isn't needed every time you want to redeploy.

Portability is closely tied to, and in many ways is a product of, the other aspects of cloud openness. Without being able to deploy on the infrastructure of your choice, you don't have portability. Without freedom from the business practices and technology roadmaps of individual vendors, you won't have portability. Without open and extensible APIs, you can't have portability.

Red Hat also augments portability by providing consistent runtime environments across private and public clouds. With access to products such as Red Hat Enterprise Linux and JBoss Enterprise Middleware on public clouds, users get to use the exact same certified and reliable Red Hat infrastructure and Platform-as-a-Service (PaaS) software on which many of the largest organizations in the world depend for their most demanding and important applications.

The ability to run workloads in a consistent way across a hybrid environment spanning both heterogeneous internal resources and public cloud providers is essential to effectively and efficiently take advantage of cloud computing. Without this portability and choice, a cloud is a point solution that may deliver some local value but will not be transformational.