Google App Engine - what about existing applications?

Recently, Google announced Google App Engine, another announcement in the rapidly growing world of cloud computing. The announcement led to an interesting discussion on InfoQ, which included topics such as which applications are appropriate for the cloud and issues of vendor lock-in:

Floyd Marinescu gives his perspective on how this will impact that next generation of application platforms:

I think Google App Engine is the beginning of a whole new category of cloud computing offerings, making the total set in my view loosely similar to the following:

1. Grid or Master/Worker implementation clusters. This is the traditional view of cloud computing, where you just have a master/work type programming model with the workers being executed transparently across a grid of computers. This type of stuff is happening behind the firewall, I don't know of any internet/publically exposed services that do this.
2. The internet becoming a new middleware platform. This is where Amazon, Microsoft, Yahoo, and are playing. Middleware api's/products that previously were installed in the datacenter and charged on a license fee basis are now moving online with web service accessesible API's, charged on a utility computing model. Things like compute (Amazon EC2), Storage (S3, Microsoft SQL Data Services), Queing, domain-specific data sources (the realm of mashups and RSS), are part of this 'trend'. The internet is starting to provide middleware building blocks that are mashed up to build applications. Users can see massive cost savings compared to buying similar tools and maintaining them themselves in the data center.
3. The internet as an application hosting platform.So whereas the previous trend is about exposing middleware constructs on the net, this trend is about exposing a whole end-to-end application stack with API's for everything from MVC/web to messaging to data storage (entities) built in. As a developer now you don't even need to think about things such as scalability, about data storage format, etc. You just deploy your app to this 'platform cloud' and it just works. Google's cloud computing offering is thus a higher-up-the stack offering compared to Amazon.

Galen Gruman and Eric Knorr give a good review of cloud computing in a recent Infoworld article, entitled What cloud computing really means, in which they categorize this type of offering as Platform as a Service:  

Platform as a Service: Another SaaS variation, this form of cloud computing delivers development environments as a service. You build your own applications that run on the provider's infrastructure and are delivered to your users via the Internet from the provider's servers. Like Legos, these services are constrained by the vendor's design and capabilities, so you don't get complete freedom, but you do get predictability and pre-integration. Prime examples include Salesforce.com's Force.com and Coghead. For extremely lightweight development, cloud-based mashup platforms abound, such as Yahoo Pipes or Dapper.net.

What's interesting about all this is the gap that still exists between the Platform as a Service delivered by cloud providers and enterprise application developers. It is clear that neither Google nor Amazon thought deeply about what it means to run existing applications on the cloud, especially those already written with JEE or .Net. What's also interesting is the assumptions they are making with regards to the trade-offs among consistency, performance and reliability. For example, if you look at Amazon's SimpleDB service, the Amazon message queue and other web services, it is clear that they were designed to suit a certain type of application, designed in a very specific way..

In addition, and looking at Google's offering especially, it seems that they came up with their own way of doing things and are essentially dictating that way to anyone who wants to use their platform. As Jason Carriera commented in about Google (in comparison to Amazon):

I can't understand who'd want this... With Amazon Web Services, you get a VM hosting service where you can run any AMI

So while Amazon is still more open than Google, if you want to take full advantage of their Platfrom as a Service offerings, you are pretty much in the same boat.

This brings up some very serious questions:

• If we want to take advantage of one of the clouds, are we doomed to be locked-in for life?
• Must we re-write our existing applications to use the cloud?
• Do we need to learn a brand new technology or language for the cloud?

Geoffrey Wiseman's comment on the InfoQ thread highlights some of the common concerns:

..that scares me precisely because of the vendor-lock-in. I mean, I wouldn't necessarily be shocked to have an ISP reserve that kind of right -- only I would retain the option of hosting it somewhere else. With GAE [Google App Engine], if Google decides they want to take down your app, what's your next option?...

Garett Rogers published his view on ZDnet The problem with Google App Engine, in which he outlined similar risks to those described by Geoffrey:

• You are putting your application in Google’s hands

Think about that for a minute. You are at the mercy of Google — if disaster strikes and Google one day disappears, you are done to. Or, more realistically, if the Google App Engine goes down for an hour, you are also down for an hour — and you will have no idea what happened.

• It’s free right?

Not only are you locked in, you are completely at the mercy of Google’s future pricing strategy for the Google App Engine…

• Privacy should not be taken lightly

     Google has a very strong privacy policy — and personally I trust them. However, I’m trusting them with my personal information — you will be trusting them with all of your company’s data?...

• Once you are in, you are really in

      Using Google’s infrastructure is very tempting. But any smart company should have some sort of plan for the future…

It is clear that cloud computing is still in its early stages and it is, therefore, hard to tell how it's going to shape up. It's also very likely that we will see increasing competition among the cloud hosting providers which means that the last thing we want to do is lock ourselves to a specific provider's platform.

So how do we go about that?

The most important approach I would recommend is abstraction: write your code in a way that is agnostic to the environment in which it will be running. This may sound trivial, but it's not that simple. Following are  some practical suggestions for a practical way of doing this:

• Use development frameworks, such as Spring, Hibernate and Mule, to abstract your application from the underlying runtime implementation. Interestingly, now that Java has built-in support for scripting  languages you can also write pieces of your code in any of those languages, even keeping yourself abstracted from the use of Java.
• Use the runtime platforms of your choice to deliver messaging, parallel processing and data services based on cost/value. At the end of the day, it's the runtime platform's responsibility to deliver its services in a virtualized/cloud environment and abstract the complexity involved from the application using it. 
• Use the cloud of your choice. A cloud could be anything from your local PC to your corporate data center to a public Internet cloud such as Amazon EC2. 

After applying all of these principles, here's how your new application stack will look like:

Note that with this approach, the development framework doesn't even have to be bound to Java, .Net, C++ or scripting. It can combine all of them together.

This sounds a bit complicated -- if you are assuming you need to do it yourself, but the good news is that there is built-in motivation among the various players in that stack to play well together to ensure interoperability, without needing an external "guard" in the form of standards bodies. For example, the makers of Spring and Mule are motivated to support various runtime implementations, and therefore, do a good job creating the abstraction. In turn, the runtime platform providers, such as GigaSpaces, Oracle, IBM or Terracotta, are motivated to support the various development frameworks.

This type of abstraction already exists with various products in the marketplace. For example, GigaSpaces supports Spring, Mule and Hibernate for Java, as well as nHibernate and WCF for .Net.  We're seeing more platforms becoming a part of this ecosystem, such as Compass/Lucene and other projects in  our own OpenSpaces.org such as JPA adaptor, Memcached, SimpleDB and PHP integration (I'll be writing a separate post just about that).

Using that approach we can build our application today in a way that "future-proofs" it, and does not lock us in to a particular platform.

The different solutions compete on various aspects:

• Runtime capabilities, such as scalability, performance and reliability
• How well they provide an integrated solution with the different development platforms
• How well they support and integrate with internal and external clouds
•  How simple is it to develop and deploy an application

The result will be the next generation middleware platform, or Application Server. And IMO, Java, some aspects of JEE (API), and .Net will all play a part in this offering.

The good news with this approach is that if you already have existing applications written in Java or .Net, you can still benefit from the cloud, without needing to re-write your entire application or learn new technologies and languages.

I expect that at some point in the near future some of the cloud providers will support this type of model. By running the GigaSpaces Amazon Machine Images on Amazon EC2, you can already implement this approach today.