Skip to content
GigaSpaces Logo GigaSpaces Logo
  • Products
    • InsightEdge Portfolio
      • Smart Cache
      • Smart ODS
      • Smart Augmented Transactions
    • GigaSpaces Cloud
  • Roles
    • Architects
    • CXOs
    • Product Teams
  • Solutions
    • Industry Solutions
      • Financial Services
      • Insurance
      • Retail and eCommerce
      • Telecommunications
      • Transportations
    • Technical Solutions
      • Operational BI
      • Mainframe & AS/400 Modernization
      • In Memory Data Grid
      • Transactional and Analytical Processing (HTAP)
      • Hybrid Cloud Data Fabric
      • Multi-Tiered Storage
      • Kubernetes Deployment
      • Streaming Analytics for Stateful Apps
  • Customers
  • Company
    • About GigaSpaces
    • Customers
    • Partners
    • Support & Services
      • University
      • Services
      • Support
    • News
    • Contact Us
    • Careers
  • Resources
    • Webinars
    • Blog
    • Demos
    • Solution Briefs & Whitepapers
    • Case Studies
    • Benchmarks
    • ROI Calculators
    • Analyst Reports
    • eBooks
    • Technical Documentation
  • Contact Us
  • Try Free

Google App Engine – what about existing applications?

Subscribe to our blog!

Subscribe for Updates
Close
Back

Google App Engine – what about existing applications?

Nati Shalom April 20, 2008
9 minutes read

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:

Nextgenappserver_2

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.

CATEGORIES

  • GigaSpaces
Nati Shalom

All Posts (167)

YOU MAY ALSO LIKE

January 23, 2008

I Am Legend – XAP…
13 minutes read

March 26, 2014

NoSQLNoCompromises
7 minutes read

November 10, 2008

The impact of cloud computing…
6 minutes read
  • Copied to clipboard

PRODUCTS, SOLUTIONS & ROLES

  • Products
  • InsightEdge Portfolio
    • Smart Cache
    • Smart ODS
    • Smart Augmented Transactions
    • Compare InsightEdge Products
  • GigaSpaces Cloud
  • Roles
  • Architects
  • CXOs
  • Product Teams
  • Solutions
  • Industry
    • Financial Services
    • Insurance
    • Retail and eCommerce
    • Telecommunications
    • Transportation
  • Technical
    • Operational BI
    • Mainframe & AS/400 Modernization
    • In Memory Data Grid
    • HTAP
    • Hybrid Cloud Data Fabric
    • Multi-Tiered Storage
    • Kubernetes Deployment
    • Streaming Analytics for Stateful Apps

RESOURCES

  • Resource Hub
  • Webinars
  • Blogs
  • Demos
  • Solution Briefs & Whitepapers
  • Case Studies
  • Benchmarks
  • ROI Calculators
  • Analyst Reports
  • eBooks
  • Technical Documentation
  • Featured Case Studies
  • Mainframe Offload with Groupe PSA
  • Digital Transformation with Avanza Bank
  • High Peak Handling with PriceRunner
  • Optimizing Business Communications with Avaya

COMPANY

  • About
  • Customers
  • Management
  • Board Members
  • Investors
  • News
  • Events
  • Careers
  • Contact Us
  • Book A Demo
  • Try GigaSpaces For Free
  • Partners
  • OEM Partners
  • System Integrators
  • Value Added Resellers
  • Technology Partners
  • Support & Services
  • University
  • Services
  • Support
Copyright © GigaSpaces 2021 All rights reserved | Privacy Policy
LinkedInTwitterFacebookYouTube

Contact Us