Google App Engine - what about existing applications?
Posted 20 April 2008 @ 8:36 am by Nati Shalom
Recently, Google announced Google App Engine, another
announcement in the rapidly growing world of cloud computing.
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:
- 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.
- 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.
- 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.
So how do we go about that?
- 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.
