posted on Monday, January 26, 2009 3:40 AM
Open APIs are a matter of much discussion these days in the realm of cloud computing. Just take a peek at the discussion that occurred via Twitter during Cloud Connect. Many folks were not shy in putting forth the notion that cloud portability and interoperability can only be achieved through accepted "cloud" standards. Integration standards, for the cloud, if you will.
The fear is that any emerging standards will focus only the portability of the application or virtual container environment. They are likely to ignore the fact that no application is an island, and that the application delivery infrastructure (load balancing, acceleration, optimization, security) should be included in interoperability standards because the policies surrounding these application networking functions are application specific. If they aren't, then you are (or your provider is) doing it wrong.
It seems a simple thing to define an open API through which clouds can be integrated, using it to move virtualized applications from one data center to another. But if you moved only the application, what happens to the access policies? The acceleration policies? The security policies? The load balancing policies? The storage policies? What happens to all the rest of the components necessary to deliver that application in a way that ensures it is reliable, available, secure, and fast?
The monitoring and management of load balanced applications in an elastic environment are critical to ensuring the availability and reliability of that application. But without a way to exchange that information, to exchange the policies between clouds, that meta-application data is lost and needs to be recreated.
The optimization and acceleration policies, too, are integral to not only the well-being of the application but to your budget, as well. Optimizations such as TCP multiplexing reduce the load on application servers and make them more efficient, meaning you can serve more customers using less compute resources. If those optimizations are lost in the transfer from one cloud environment to another, that application may suddenly require more resources, which in the cloud computing vernacular translates to "mo money for the provider". The loss of such meta-application data can increase the price of running an application in the cloud, offsetting the reduction in operational costs oft cited as a reason to move to the cloud.
Now just wait a minute, you say. Cloud is all about abstracting the infrastructure in such a way that users don't need to concern themselves with all those details. We shouldn't need to care about that.
No, you shouldn't. And that's the point. If cloud interoperability efforts ignore the (necessarily) close relationship between application delivery policies and applications you will have to care about it, because you'll need to reconfigure and redeploy those policies when you move from one cloud environment to the next.
As long as application delivery infrastructure providers adhere to a standards-based API through which such standard delivery policies can be automatically redeployed, and we remember to include that infrastructure as part of the definition of an "application" when moving from one environment to another, the promise of the benefits of infrastructure abstraction through cloud computing can come to fruition.
Technorati Tags:
MacVittie,
F5,
application delivery,
cloud computing,
cloud interoperability,
cloud connect,
interoperability,
portability,
virtualization,
acceleration,
security,
optimization,
standards,
cloud,
web,
internet,
blog
