posted on Thursday, April 01, 2010 3:25 AM
If we do it right, cloud interoperability could be as easy as a URL rewrite – a la API refactoring. Not kidding. Question is, can we do it right?
Watching the emergence of a new technology is both fascinating and frustrating. In the case of cloud computing it’s fascinating to see the “process” of standardization and positioning taking place but it’s frustrating to see the same hurdles whittling away at the potential for true interoperability because of the silos that continue to exist not only in the organization but amongst the broader industry that provides infrastructure and services to those organizations.
On the one hand we’ve got storage and networking vendors trying to develop APIs and models. On the other hand we’ve got developers and application-oriented vendors trying to develop APIs and models. And neither of them has the expertise of the other that’s required to take on the birds’ eye view of cloud computing and interoperability that’s necessary – absolutely necessary – to achieve what could be the most elegant interoperability standards to date. We’ve got silos, people, and we need to get out of them and meet in the barn sooner rather than later if we want true interoperability to succeed. It is possible, but it won’t happen while we’re locked away in our silos (ivory towers) ignoring the “other half” of the equation.
A UNIFIED MODEL
If we could agree on a unified model to codify the meta-data necessary across the entire spectrum of application and network infrastructure services and then further agreed to standardize on a REST-based API we could, in fact, arrive at a point where the issue of cloud interoperability is resolved with little more than a URL rewrite.
If the model is consistent across cloud computing environments – public, private, hybrid, local, external, internal - much in the same way HTML is consistent across web applications, then the differentiation across providers becomes the services and processes that orchestrate those services into an efficient, fast, secure application delivery system. If the model is consistent then an application can be described in a consistent, unified way and the implementation of the policies required to support the application and its infrastructure needs (security, acceleration, QoS, optimization, data integration, backup, storage) remains the demesne of the cloud computing provider.
Much in the same way custom HTTP headers can be ignored or interpreted based on support by any given network or application network component to provide specialized services, the cloud computing provider is able to interpret the meta-data that describes the full application stack and implement policies as needed based on their unique infrastructure.
For example, let’s say part of the infrastructure model (based on Hoff’s Info/Infra/Meta-structure model) contained a description of the application’s need for persistence in load balancing, and further provided the “key” upon which that persistence is based.
Let us pretend for a moment that we actually have this model, and the meta-data is provided in a well-understood attribute-value pair mechanism (JSON, XML, INI style). The actual implementation language is not nearly as important as the definition in a standard AVP-style so that the cloud provider and ultimately individual components can interpret it effectively to create and/or apply the proper policies.
The meta-data can be provided to the cloud provider via an API. It matters not that “Cloud A” requires the submission of application meta-data via the URL:
http://controlplane.clouda.com/management/metadata/configuration
and that “Cloud B” requires the submission via the URL:
http://management.cloudb.com/configuration/update/application
as long as they both accept the same meta-data model. I can easily enough change the URL either manually or dynamically to address a different (or perhaps both) cloud provider.
The cloud provider, upon receiving the data, is then tasked with distributing it throughout the infrastructure in its own, unique way. At this point the cloud truly becomes a “black box”, at least to the consumer, and how the meta-data is disseminated across the infrastructure is entirely up to the provider and its especial processes for provisioning and management of its infrastructure. What’s important to the consumer is that they were (a) able to specify infrastructure services in a common, easy to understand way and (b) they don’t need to worry about the implementation details because the “infrastructure” is someone else’s problem, i.e. it is up to the provider.
EXTENDING INTO THE INFRASTRUCTURE
This dream extends into the infrastructure, lest cloud providers feel as though they’re bearing the brunt of the interoperability burden. If the infrastructure and services utilize a common model, it too, can be managed and configured and orchestrated in a similar fashion, with only the end-point changing as required. Rather than develop a lot of infrastructure solutions specific integration code – which any enterprise software developer can tell you is painful and results in the “L” word (lock-in) – we can then leverage the ubiquitous URL as an integration point. That integration point is simple to change and can even be used simultaneously across multiple infrastructure solutions to find the “best fit” solution for a given application.
It really could be that simple, if only we could unify the model used to describe the services.
A COMMON MODEL ENABLES the EVALUATION PROCESS, TOO
Using a common model in this way has broader impact on the entire “cloud acquisition” process. It makes it possible to use the same metadata to submit a query to the cloud provider to determine whether they can, in fact, support the infrastructure and application services required. Rather than submitting the model to a configuration or deployment service URL, the consumer submits the metadata to a query URL:
http://controlplane.clouda.com/management/metadata/inquiry
The cloud provider can parse, interpret, and determine whether or not it can support the requirements as provided by the consumer in the metadata, and the consumer can determine whether the provided response – which should ultimately contain pricing and other pertinent information – offers the set of services best suited to scale and deliver their application. This is very much the focus of James’ Urquhart’s pCard proposal, the definition of the metadata necessary to describe and subsequently deploy and support a complete application. Similarly, we could use that model of inquiry inside the cloud provider infrastructure, to determine which of several infrastructure components is the best fit in terms of capabilities, performance, and price to the requirements provided by the consumer in their “pCard” describing their application needs.
I have a dream, and I recognize that it’s very much a dream that is unlikely to be realized because of the chasm that continues to exist between the network and the application, not only in the organization between teams responsible for each, but in the broader industry. It’s a case of niche foci, of storage vendors and constituents being focused on storage and interoperability between storage solutions; of network vendors and constituents being focused on network and interoperability between network components. Cloud providers, too, are separated by their interests and needs, with a focus on management APIs of the services they expose externally.
There exists not a concerted effort to bring them all together and force them to view the cloud and APIs and interoperability through a broader, more holistic set of lenses.
It is possible that we can piecemeal together a single metadata model from the disparate models that will appear from each niche industry. But perusing the specifications beginning to trickle out of such efforts it is clear that the focus of these efforts is an API, not a model. It’s all about functions, and operations, with not nearly enough focus on the model and whether or not that model will support both existing and future infrastructure definitions in the particular space.
We need to focus on the models, not the APIs, because it is the models that will provide the interoperability and portability desired both across and within cloud computing environments.
