Rich Miller, in response to some questions I maintain on meta-data ownership and interoperability with regards to the CCIF's efforts in defining a cloud interoperability specification, had some questions of his own:

The part I'm itching to ask her about ... or start a more open conversation: the possibility of "a specification regarding application network delivery metadata" which, if properly (??) abstracted and generic, could "allow the meta-data policies to be transported and applied across different cloud implementations while preserving the specific details of implementation within the cloud computing infrastructure."  Whoa!! Tall order, isn't it?  What does it imply we've done with respect to a standardized representation / standard semantics of peripatetic workload computing? (Sorry... couldn't bring myself to say "cloud" again.)

First, I love the "peripatetic workload computing" moniker. Pedantic, descriptive, and avoids the use of "cloud". Beautiful.

So the question is "what does it imply we've done with respect to a standardized representation / standard semantics." Hopefully my statements and concerns were not taken as disparaging the efforts currently underway with regards to a standard semantic representation of the cloud. Indeed, such efforts are only beginning, which is why I raised the concerns and questions now rather than later. That Rich (and many others) are interested in such a conversation speaks well of efforts currently underway.

My concern comes from efforts such as Hoff's cloud computing taxonomy which is ambitious and broader than most, yet fails to recognize the existence of application delivery as part of the taxonomy and an integral part of a successful cloud computing or virtualized infrastructure. For example, in the "Core Connectivity" layer we see "LB", clearly indicating "Load balancing" but we see nothing regarding more advanced application delivery connectivity concepts such as caching, optimization, etc. I assume that such advanced aspects of application delivery are included in the very generic overarching "Infrastructure" portion of the taxonomy, with what that entails left to the imagination of those interpreting the taxonomy.

While it's heartening to see load balancing recognized as a core concept within cloud computing (indeed, without load balancing as a foundational technology cloud computing and virtualized dynamic architectures would likely not exist) there are associated technologies, derivatives if you will, that are just as integral to cloud computing that certainly should be considered when developing a specification designed to transport an "application" from one cloud infrastructure to another.

The problem is two-fold: first, application delivery-oriented policies are often ignored in the definition of an "application" and second, assuming they aren't this time (and shouldn't be) we then encounter the diverse nature of application delivery solutions and the myriad problems associated with abstracting a generic definition of what application delivery meta-data is relevant and required for any given application to be interoperable across cloud computing implementations.

Assuming the first problem is addressed and that it is agreed that application delivery meta-data is an integral part of the definition of an application and the components necessary for it to be migrated, deployed, and run in a variety of cloud computing environments, the problem returns to the disparity in the definition across vendor implementations and the decisions regarding just what meta-data is "standard" and what isn't.

For example:

  1. Session persistence. Session persistence is nearly mandatory for web-based applications in a load balanced environment such as cloud computing or virtualized architectures. Session persistence is a layer 7 construct, not specifically germane to load balancing which is often implemented at layer 4. Is this (or should this be) a standard part of an application delivery taxonomy designed for interoperability?
  2. Layer 7 load balancing. Layer 7 load balancing is specific to the application in question by definition, but is not normally considered part of "load balancing" (hence the specific qualifier in the descriptive name). Yet layer 7 load balancing (by host, by content type, by payload as a content based routing mechanism, by URI, etc...) is often used in complex environments as a means to architect a more efficient, well-performing application and, in some cases, as a way to combat the rapid depletion of IPv4 addresses. Again, traditional layer 4 "load balancing" does not and cannot address this advanced mechanism. Is this (or should this be) a standard part of an application delivery taxonomy designed for interoperability?
  3. Caching and compression. Caching and compression features are often implemented by the application delivery network infrastructure as a means to offload overhead from application servers and improve overall capacity and response time. Yet these features are considered "advanced" and not a part of the standard load balancing definition. Is this (or should this be) a standard part of an application delivery taxonomy designed for interoperability?

The core problem of differences in implementation and support of such features can be addressed by ensuring that the exchange format (the specification) is implemented in an extensible data format like XML, and indeed likely will be. But we have to be careful about assuming that extensible means interoperable, as such ambitious attempts in the past have failed. I give you the failure that is BPEL (Business Process Execution Language) as a prime example of an extensible meta-data description language designed for interoperability that has completely failed to achieve its goal of portability. Even SOAP and WSDL, specifically and carefully designed for interoperability and portability continues to suffer from backwards compatibility issues. Adoption of WS-I Basic Profile as a means to combat the initial interoperability problems provided some measure of relief, but it was not complete and it already has begun to slip into obscurity and irrelevance.

Assuming the definition and format of such a specification can be agreed upon (and we can make it work), there remains the question of who owns these policies? It is clear that the developer of the application "owns" the virtual image(s) created but when those images are deployed into an environment "in the cloud" and leverage an infrastructure that is not theirs by definition, the ownership of those policies becomes unclear. Almost all advanced application delivery features are implemented apart from the application and the image as it leverages infrastructure owned and managed by the provider. The policies used to provide session persistence, layer 7 load balancing, caching and compression, therefore, are deployed separately and often managed by someone other than the application owner. They may, in fact, be a part of the 'secret sauce' or 'value add' of the provider that allows them to differentiate from competing providers. There is very little impetus for the provider to share those policies with others or provide the means by which they can be easily transferred to a competitor.

We are very early - very early - in the process of defining a cloud interoperability specification. The efforts currently underway are looking ahead purposefully, to try to avert the problems that will arise in the future but are currently not on the radar of most organizations. Because it is so early it makes sense to ask - and hopefully answer - these questions now, before they become a roadblock to portability.

Never before has an interoperability specification effort spanned such a broad spectrum of infrastructure. The taxonomy created by Hoff spans all layers of the stack, necessarily. The change in deployment model introduced by cloud computing constructs has necessarily forced us to consider all aspects of that model, from the network layer to the application, and to be more mindful of how these components interact and, more importantly, rely on one another to deliver up an application to users.

Thus I raise such concerns over ownership and inclusion of application delivery meta-data early, that we might keep in mind that in a distributed deployment model like the cloud we cannot ignore their relevance nor importance to the overall definition of an "application".

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share