Tuesday, June 02, 2009

Thoughts on Standard Cloud APIs (whatever that is)

Yesterday I attended a few cloud computing talks at the tail end of Community One. The first was on Cloud Storage which I found to be a fairly good survey of current "database" options for externally hosted systems or applications. The second was a session hosted by RedMonk on standardizing APIs for the cloud. It's this second session which has me thinking and the more I think about standardized APIs for cloud computing the more I don't think we need them, at least not for all things in the cloud. Standard APIs make no sense for the Platform as a Service and the Software as a Service players. I think what we need here is more innovation and support of multiple frameworks as opposed to standard APIs. That is standard APIs across these vendors. We need simpler interface implementations, more innovation, and some notion of application portability to some extent, e.g., it would be nice if writing Django or Java Servlet/JSP apps on App Engine didn't result in applications that couldn't run on standard app servers. Not that I think we are there today but moving your app on or off AppEngine does require some non-trivial effort. So maybe what we need here are implementation specifications or support for more seamless transitions between self-hosted and cloud hosted applications. Make it easier for me to use the standard frameworks I'm used to using or at least a large percentage of those frameworks. Users seem to be fixing things themselves in this regard. The app engine patch project allows users to run unmodified Django apps on app engine. Well mostly unmodified since the App Engine data persistence layer is clearly not a relational db. So do cross service APIs make sense. I don't think so. I don't want Amazon Web Services and Google App engine to have a standard API because I'm using them for different things.


What I believe we do want is for Sun, Amazon, and others who are selling me Infrastructure as a Service (IaaS) to implement some standard management interfaces and APIs for virtual cloud infrastructure. After all a system image, running instance, a network, a disk, or firewall all have common management "interfaces". This is where I probably want something like Sun's Cloud APIs. It makes much more sense to standardize this type of management. But I don't want it to stop there, and here is the challenge to the people who would specifies these APIs, I want those APIs to cut across my firewall. I'd like them to be able to manage my internal cloud as well, say my VMware or Xen infrastructure. That would allow me to seamlessly manage both internal and external cloud installations and might even let me migrate apps in and out of various external and internal cloud system infrastructure. It may even allow me to simplify getting extra capacity for my internal applications by firing up instances on an external cloud or at least it will allow me to use a single management tool/scripting language/console. As much as I'd like to think that IaaS providers would be willing to cooperate you only have to look at traditional system management to see that in the past common management frameworks have failed to materialize. Let's hope they can rise above that.


So let's let the PaaS/SaaS guys innovate. If you're worried about lock in then write and architect your app as you normally would and deploy on Amazon Web Services or Sun's cloud when it's live. Then let's engage IaaS providers and start to push them towards some kind of API standardization. As an alternative, maybe some smart people should write a nice adapter layer that speaks a standard API on one end and vendor specific APIs on the other. Not a bad idea.



Labels: , , , ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home