1,490
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:
- 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.
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.
