ARIA and the ‘Least Common Denominator’ Problem of Cloud Portability
Hybrid cloud only works when applications are designed to run predictably across all the infrastructure choices in the IT portfolio. Most organizations achieve this through a “least common denominator” approach to design, one in which API abstractions are so thoroughly simplified that only the barest set of cloud services remain. This approach, while functional, strips away nearly all of the useful advanced features that different infrastructures offer.
A new Apache open source project, ARIA (Agile Reference Implementation of Automation) wants to solve this compromise.
Hybrid is Real, and it’s Hot
A recent survey by RightScale reported that cloud users leverage six different clouds on average, using a 50-50 mix of public and private clouds for experimentation and application deployment. Another survey by Veritas documented that roughly 74 percent of enterprises leverage two or more cloud infrastructure vendors to support their workload requirements, and 23 percent are using four or more vendors.
As these surveys suggest, hybrid clouds — the use of multiple clouds simultaneously, acting as one unified infrastructure — are a way of life, the “new normal” for IT.
However, there is no “standard blueprint” for a hybrid cloud, and the architecture for hybrid clouds can vary as much as the use cases for which the hybrid clouds are built. This leaves IT departments shouldering a heavy new mandate: portability. Cloud portability is the ability to run the same application on multiple cloud infrastructures, whether they be public or private, proprietary or open-source.
Why Cloud Portability is So Important
Today, the need for application portability across diverse cloud environments is mission critical. Consider just a few use cases where portability is crucial:
- Future proofing — In order to “future proof” your application from industry disruption and keep your options open to benefit from new developments as they happen, it is important to decouple the application from the underlying infrastructure by designing the application for cloud portability.
- Application deployment portability — Companies that develop software applications need to allow application portability to give their customers a simple way to provision and deploy their software products on their cloud of choice. In this context, cloud portability can be analogous to operating system portability between Windows, Linux and Mac or even mobile app portability across iOS and Android. Cloud represents a market and by designing for portability you maximize the reach of your products to those markets.
- Cloud bursting — Cloud bursting allows an application to run on a fixed pool of resources during its steady state periods and then span to on-demand cloud resources during peak loads. It’s a way to optimize resources (i.e., save on costs) and still provide access to capacity when needed.
- Migration — A common example is an organization that is migrating from their VMware environment into OpenStack or from private cloud into public cloud. Portability allows the organization to selectively transition the application between the two environments while at the same time managing them as one.
- Portability between the same cloud versions — Likely the most common cloud portability use case is the move between versions of the same infrastructure. One of the common strategies to allow upgrade of the infrastructure is to create new instances (cloud sites) of a newer version, and then gradually transition apps onto this new version.
The “Lowest Common Denominator” Approach to Portability
Without cloud portability, you can’t truly achieve hybrid cloud nor reap its benefits. Unfortunately, many of the existing solutions for cloud portability are not well suited to fit all of the diverse use cases described above because they take a “lowest common denominator” approach that inherently limits the power of the underlying cloud.
These solutions rely on a common layer of API abstraction across all clouds. The common API abstraction already limits itself to Compute, Storage and Network, and even at that layer the abstraction tends to be fairly simplistic and quite often doesn’t expose many of the more advanced features of the underlying infrastructure, nor does it allow access to the rich set of services that cloud infrastructure enables, such as database services, analytics services, LBaaS, etc. So, relying on this simplistic layer of API abstraction comes with a high toll; the lowest-common-denominator model forfeits many of the benefits that modern clouds provide.
Here’s the crux of the problem: Cloud portability solutions based on API abstraction leave out of the equation the most important element—the application. Running an application in a hybrid cloud environment requires managing the entire application stack in which the infrastructure is really only one component. The “entire stack” also includes configuration management, containers, monitoring, logging and policies, as well as maintenance of the application itself through its entire lifecycle.
Getting there with the ARIA project
So, rather than using the least-common-denominator method to achieve cloud portability, a better way would be to take the entire stack into account, and let the application developer drive the integration effort at a “higher denominator” level. That’s precisely the approach taken by in ARIA .
ARIA is a tool developers can use to deploy and orchestrate a single application on multiple infrastructures while retaining access to all the robust features and rich sets of services the cloud offers.
The diagram below shows how it works:
ARIA is built on three pillars that are needed to manage the entire stack and lifecycle of an application while circumventing the need for a single abstraction layer:
- An infrastructure-neutral, easily extensible templating language (TOSCA ): TOSCA (Topology and Orchestration Specification for Cloud Applications) provides far greater flexibility for abstraction than API abstraction as it allows easy extensibility and customization without the need to develop or change the underlying implementation code. This is done by mapping the underlying cloud API into types and allowing the user to define the way it accesses and uses those types through scripts.
- Cloud plugins: Built-in plugins for a wide range of cloud services provide out-of-the-box integration points with the most common of these services, but unlike the least common denominator approach, they can be easily extended to support any cloud service.
- Workflows: Workflows enable interaction with the deployment graph and provide another way to abstract common cloud operational tasks such as upgrades, snapshots, scaling, etc.
With these three components, ARIA gives the application developer a set of building blocks for managing the entire application stack and its lifecycle. It also provides a richer degree of flexibility, allowing users to define their own degree of abstraction per use case or application.
In this manner, cloud portability is achieved without the need to change the underlying code, and true hybrid cloud — with all its benefits — is realized.