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: , , , ,

Sunday, May 10, 2009

Unsticking My Kindle Downloads

This week my Kindle 2 mysteriously stopped automatically downloading content from the Kindle Store. I tried performing a "Check and Sync" from the main menu several times but no joy. Apparently, the way to jar your Kindle from this incommunicado state is to disable the wireless, restart the kindle from the settings page, then re-enable the wireless. It worked like a charm. My Kindle is now once again one with the Kindle Store. Many thanks to Amazon for helping me with this issue. Truly this is a remarkable device backed by a great service. Awesome.

Labels: ,

Wednesday, December 31, 2008

One Last Hack for 2008

Thanks to SnarkyBytes for this post on how to make a USB charger for the Kindle! A quick trip to RadioShack in downtown San Francisco and my Kindle is now charging. It will be more useful than a brick on the trip home. Amazon should have really fixed this problem for me but it feels good to do something like this for yourself. This is good behavior to continue into the New Year. Happy New Year everyone!

Labels: , ,

Monday, August 11, 2008

I want it on my Kindle!

kindle.png

Noticed this link on my latest Amazon book search. Not sure if it's new but it's the first time I've noticed it. Brilliant idea really. I'll be clicking that link a lot I imagine since I'm not much into the best sellers list.

Labels: ,

Monday, May 05, 2008

CommunityOne: Amazon EC2 and OpenSolaris

Sun is apparently poised to support Open Solaris on Amazon EC2. More information is available at http://sun.com/amazon. I've registered but haven't heard back. There are some limitations. The initial release only supports the 32-bit EC2 instances so that actually limits what you can do.

If I get a hold of the AMIs I'll try to post some notes on the experience.

Labels: , ,