Bits And Buzz, by @JeremyChone

One of the biggest fears of any IT manager about cloud computing is the lack of openness. In other words, they ask, “How easy is it to get in and out? Or they might ask, “How portable is a cloud application?”

Ideally, enterprises should be able to take applications and data in or out of a cloud as business requires without having to rewrite the application or transform the data.

As discussed in the article “Don’t Get Stuck in a Cloud ,” cloud portability tends to be a factor related to the type of cloud one uses.

Here is a quick portability analysis of the three big Clouds on the market:

1) Force.com

While it is possible to develop an application on Force.com that does not integrate with SalesForce.com applications, the true value of doing so is the integration of the two. Force.com has a very powerful and highly integrated platform and application cloud. However, Force.com is designed on proprietary technologies. Force.com has a custom language, which looks like Java but is not Java, and its own SQL/ORM layer. The technical tradeoff allows a Force.com application to take full advantage of Force.com scalable architecture and to integrate deeply with SalesForce.com applications.

Consequently, if you are doing an enterprise application that integrates into SalesForce.com, Force.com is definitely the appropriate choice. However, if you are implementing a standalone application with no integration to SalesForce.com applications or ecosystem, you might want to look at more portable platform clouds.

2) Google App Engine

Google went all the way by supporting true Java on its platform cloud. There are still some restrictions, but most of the common Java libraries and frameworks can be used on the Google App Engine.

The only catch, as previously alluded to, is the data layer. Google App Engine uses JDO for its data layer or a subset of JPA. JDO is fine for some types of applications but can be hard and even costly to adopt for enterprise application (e.g., JDO does not support delete-cascade! Extra work is needed to support delete-cascade -needs to implement jdoPreDelete-). And the JPA support is not complete yet. Therefore, moving an application from SQL/Hibernate to AppEngine will require some rewriting but is still manageable for a well-architected application, especially with JPA is used in both environments.

3) Amazon WS

Being an infrastructure cloud, Amazon WS does not provide any platform cloud service and therefore does not restrict application developers to any technology. The downside of this type of cloud is that SaaS developers will have to develop their customized, highly-scalable architecture. This is less of a problem for IT developers, as they will probably want to reuse their application framework, which is already designed to scale to meet their needs.

This has been another look at the cloud market space. Obviously, the market is moving fast, and it is most likely that this map will change over time, but this matrix should give you a relatively accurate view of the current state of the market.

I hope this series of cloud computing articles will be useful for people in the midst of the decision-making process.

If you liked this article a +1 on HN or a re-tweet are greatly appreciated. (see R-Tweets)

Posted: Wednesday, September 16th, 2009
Tags: Enterprise Web 2.0.
Actions: RSS 2.0 feed. You can leave a response, or trackback from your own site.