Google App Engine Comes Closer to Enterprise Adoption

cowphysicistInternet and Web Development

Dec 4, 2013 (4 years and 6 months ago)


Publication Date: 4 May 2009 ID Number: G00167581

© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form
without prior written permission is forbidden. The information contained herein has been obtained from sources believed to
be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although
Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal
advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors,
omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein
are subject to change without notice.
Google App Engine Comes Closer to Enterprise
Benoit J. Lheureux, Tom Austin, Yefim V. Natis, Ray Valdes, Eric Knipp, David Mitchell Smith
We examined Google's announced enhancements to the Google App Engine (GAE)
from four points of view, assessing the viability of each to support business applications.
Although GAE is now more suitable for some enterprise projects, remaining functionality
gaps limit which type of business applications can be deployed.

Key Findings
• GAE is increasingly suitable for new, opportunistic Web-centric applications, but is not
appropriate as a destination platform to port well-established, systemic Java-based
• The Google Datastore application programming interface (API) provides GAE-based
applications with scalable persistence for Java-based objects, but does not support
SQL-based relational database management system (RDBMS) capabilities widely used
in business applications.
• Secure Data Connector (SDC) offers GAE and Google Apps users a moderately viable
approach for integrating their Google applications with on-premises business
applications and data.
• Developers working on new, opportunistic Web-centric projects that can start small and
grow should explore GAE as one of several cloud-based alternatives.
• Enterprise IT departments should not plan on migrating their current Java business
applications to GAE/Java, because the product is not designed for this purpose and, in
most cases, is not functionally complete enough to fulfill this role.
• Use SDC agents natively for simple integration projects based on Web services, but rely
on independent software vendors (ISVs), system integrators (SIs) and other third-party
technology partners to leverage SDC for more-complex data and application integration
• Developers wishing to take advantage of the Datastore API should focus on using the
Java Data Objects (JDO) persistence interface, because JDO is designed to work with
object-oriented databases (OODBs), as well as with RDBMSs. Although BigTable is not
an OODB, it shares enough characteristics to make the implementation of JDO a good

Publication Date: 4 May 2009/ID Number: G00167581 Page 2 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Strategic Planning Assumption(s).....................................................................................................3


1.0 A Compelling Vision for Development Meets With Limited Enterprise Adoption...........3

2.0 The APaaS Market.........................................................................................................4

3.0 Enterprise Integration via the Google SDC....................................................................6

4.0 The Impact of BigTable and Java on Persistence..........................................................7

Publication Date: 4 May 2009/ID Number: G00167581 Page 3 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

By 2014, at least 20% of business application development projects will use application platform
as a service (APaaS), such as GAE or, up from less than 2% in 2009.
Google's CEO Eric Schmidt is occasionally credited with coining the term "cloud computing," so it
is not surprising that the company has many offerings in the categories that comprise the term.
More than two dozen vendors compete with one another in the cloud-based application
infrastructure market. Google's cloud strategy consists of offerings that are primarily at the level
of application infrastructure services and above in Gartner's cloud services taxonomy (see "Cloud
Computing Services: A Model for Categorizing and Characterizing Services From the Cloud" and
"Application Infrastructure for Cloud Computing: An Emerging Market").
GAE with new Java and SDC support — the focus of much of this research — comprises much of
what Google offers at the application infrastructure level. GAE is a classic example of an APaaS,
a cloud-based form of application servers and an important alternative to software-based
application infrastructure. SDC is a primitive enabling technology for integration as a service
(IaaS). Google Apps (consisting of Google Docs, Spreadsheets, Gmail and more) comprise most
of the application service offerings, and are also a part of SDC usage scenarios.
As with many cloud offerings, Google's do not necessarily layer neatly together — for example,
with some exceptions (such as Google Moderator), many Google Apps are not written using
GAE. Most of Google's revenue derives from advertising, which is purchased from Google as a
service (see "Forecast: Sizing the Cloud; Understanding the Opportunities in Cloud Services").
Google has, thus far, had very limited success in enterprises. With some well-known exceptions
(such as Genentech, with 15,000 users) in certain industries (such as government and
education), Google Apps use remains primarily limited to individuals and small firms, not in
enterprise-sanctioned (or the paid version) scenarios. GAE has attained high visibility in this
market, but has lacked support for enterprise development approaches (although that is
changing, with Java support and SDC), yet adoption has been slow (opportunistic versus
systemic), and it still has significant restrictions on utility. Additionally, all these offerings are still
labeled "beta." Although some (for example, Gmail) are mature, many enterprises are not
comfortable (or may have policies against) using products and services so labeled. Particularly
for its more-mature offerings, Google could lower barriers to enterprise adoption by removing this
designation and more decisively declaring its commitment to supporting and enhancing these
hosted services.
Remaining limitations in Google's offering and the availability of viable alternatives will continue to
limit Google's ability to achieve significant market penetration in the enterprise. However, with
these announcements, Google is indicating that it wants to have more impact directly in the
enterprise market. In this research, we evaluate the viability of the aspects of GAE that are
relevant to business application deployment, including its appeal to developers, the effect of GAE
on the APaaS market, the viability of integrating business data and applications with Google
applications using the new SDC, and the viability of persisting business information with GAE
using BigTable, Google's cloud-optimized persistence platform.
1.0 A Compelling Vision for Development Meets With Limited
Enterprise Adoption
Analysis by Ray Valdes

Publication Date: 4 May 2009/ID Number: G00167581 Page 4 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Since introducing GAE in April 2008, Google has marketed it directly to developers in a bottom-up
strategy, rather than targeting enterprises or IT development managers in a top-down strategy.
The core value proposition of GAE for developers is that it will enable them to write and test code
on a local machine, then upload it to Google's servers (see "Google App Engine Grows Up A
Little With Java"). After that, the practice of "fire and forget" prevails — that is, the resulting
application can be accessed by a single user or a million users, and may store data in a single
record or a million records, without any further intervention. (Google does, of course, require a
monthly payment for any use that exceeds the "freemium" threshold.)
The GAE platform offloads from the developer many mundane, but necessary, tasks relating to
operations and scaling, such as system administration, database administration and operational
monitoring. Key to the value proposition is a data persistence layer across Google BigTable, a
foundational data storage mechanism used throughout Google's portfolio of products and
services, a subset of which is exposed in GAE. If the developer works in a nonrelational manner,
then the classic "impedance mismatch" between objects in memory and persisted data on disk
Although the vision of smooth scalability and hands-off operation is compelling, in reality, the
operational and architectural constraints of the initial version of GAE have limited its adoption.
These constraints restricted applications on GAE to the following rather narrow scope: Python
language only, request-driven Web applications that must return results within a 10-second
timeout window (with limits on number of records returned per query, size of data records, size of
data transfers, lack of a relational data persistence model, and more). Google has removed some
constraints and loosened others, but some remain, along with architectural constraints, such as
the request-driven model with object-oriented data persistence. A key inhibitor has been the
Python language requirements. Developers have clamored for Java language capabilities, and
have also shown interest in PHP and Ruby. Gartner believes Google elected to add Java support
first for several reasons:
• Google has a strong organizational commitment to Java; it does not have such a
commitment to PHP and Ruby. Google's Android platform is built on Java, including a
proprietary Java Virtual Machine. Google's Ajax strategy consists of the Java-centric
Google Web Toolkit (GWT).
• The Java programming language has a long history of operating in sandboxed
environments where security is a concern — an essential part of cloud computing.
• Java is not .NET, the platform originating with Microsoft, Google's principal competitor.
• Developers working on new, opportunistic Web-centric projects that can start small and
grow should explore GAE as one of several cloud-based alternatives.
• Developers should not expect to easily migrate large, existing enterprise applications
written in Java or Python over to GAE without significant modifications to the data
access logic.
2.0 The APaaS Market
Analysis by Yefim Natis
Google has been a player in the APaaS market since the introduction of GAE (see "Introducing
SaaS-Enabled Application Platforms: Features, Roles and Futures"). The platform is less
commonly considered for enterprise projects because of its initial beta status, its distinct focus on

Publication Date: 4 May 2009/ID Number: G00167581 Page 5 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Web applications and its lack of support for programming languages other than Python. By
adding Java support, Google is clearly taking a step toward enterprise adoption. In aiming GAE to
become a successful enterprise-trusted cloud computing option, Google faces three kinds of
• Cloud platform innovators like, Bungee Labs and LongJump, which, like
Google, offer the shared-everything model of multitenancy (see "Reference Architecture
for Multitenancy: Enterprise Computing 'in the Cloud'")
• Well-established enterprise computing giants like IBM and Microsoft, which rely on the
more rigid (but backward-compatible) shared-hardware model
• A variety of traditional application servers (such as PHP platform, Java Platform,
Enterprise Edition or Ruby/Rails/Mongrel) converted to services using Amazon Machine
Instances (AMI) of Amazon Elastic Compute Cloud (Amazon EC2; see Note 1)
Although Java is the most commonly deployed modern enterprise computing language,
enterprise computing is not solely defined by the choice of language alone. GAE/Java is far from
a competitive enterprise computing platform, because:
• It lacks application infrastructure fundamentals, such as support for business process
management and orchestration, application integration features (such as translation; see
section 3.0) or a portal platform.
• It offers limited support for relational data management (see section 4.0).
• It is not designed to support service-oriented-architecture (SOA)-style application
topologies in which back-end software is separated from front-end software by way of
documented and registered formal interface definitions (see "Gartner's Reference
Architecture for SOA Application Infrastructure") — although, with additional effort, a
developer can deliver basic SOA topology using a combination of GAE and GWT.
• There is no direct support of Web services standards, including Web Services
Description Language (WSDL) and SOAP; although many applications can function just
as well using the natively-supported Representational State Transfer (REST) access,
Web services are a requirement in many enterprise settings. Again, with some additional
effort, a programmer can develop Web services wrappers, but such enterprise
application requirements are not the design focus of GAE.
• There are no provisions for contractual service-level agreements, including availability,
performance and data integrity (although Google has a strong scalability and availability
record, many enterprises require a contractual guarantee of minimal service levels).
Systematic enterprise projects demand most of these enterprise capabilities and, therefore, early
adopters of GAE/Java for projects in an enterprise context will likely focus on the less-demanding
departmental and situational projects. Typically, these projects are opportunistic in their
technology selection, development and deployment practices, value ease of use, rapid delivery of
results, competitive user experience, and dependable operation. Google is likely to focus on
further developing GAE/Java in these directions.
Most early business applications "in the cloud" are comprised of traditional business functionality
ported to the cloud computing environment. This is a typical early stage of adoption for most
innovations adapted to enterprise use. For example, for many mainstream IT organizations,
screen-scraping has been the first stage of adopting Web-to-enterprise computing. "True" cloud-
computing-based business solutions will emerge that are natively designed for global-class
computing scenarios, and that incorporate nonrelational data models, social context and event

Publication Date: 4 May 2009/ID Number: G00167581 Page 6 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

awareness. This next-generation business functionality will likely escalate the adoption of GAE
and the technology of other cloud innovators, challenging the established industry leaders'
traditional means of software engineering.
Enterprise Java technology leaders are likely to counter Google's initiative by offering enterprise
Java alternatives for cloud computing during the next six to 12 months. However, their strategies
will likely remain well-differentiated: Google will focus on supporting development of new
consumer-facing Web business applications, and enterprise-leading vendors will focus on
migrating traditional enterprise computing to the cloud.
• New cloud-native business application projects should consider GAE as an emerging
and not well-proven APaaS competitor, which offers the notable advantage of the
massively scalable Google computing platform (Googleplex) and its global market
momentum and presence.
• Enterprise IT departments should not plan on migrating their Java business applications
to GAE/Java, because the product is not designed for this purpose and, in most cases,
is not functionally complete enough to fulfill this role.
• The less-demanding enterprise and consumer business applications (departmental,
situational and other opportunistic projects) should consider GAE/Python and future
GAE/Java among the available emerging options for an application platform and
development toolset when cloud-based deployment and cloud scalability are part of the
objective of the project.
3.0 Enterprise Integration via the Google SDC
Analysis by Benoit Lheureux
SDC provides Google Apps, Google Gadgets and any GAE-based applications with a secure,
reliable HTTP pipe to integrate with any on-premises or cloud-based services. Before the
introduction of SDC, Google Apps could only access corporate resources through native Web
protocols like REST, which offered more-limited security and control.
Developed by Google, SDC is comprised of an SDC server — deployed by Google with GAE,
Google Docs and gadgets in Google sites — and an SDC agent, deployed by companies behind
their firewalls. SDC uses Secure Shell (SSH) and a reverse proxy to allow Google applications to
tunnel requests for services and data through firewalls. It also extends Google credentials
through SDC via OAuth, an open protocol that enables secure API authorization for remote
applications. Configurable filters enable SDC users to limit Google Apps users' access to
particular external applications and resources. Although these changes do not address all
aspects of security for cloud-based computing (see Note 2), SDC makes Google Apps and GAE-
based applications incrementally more suitable for use by companies in conjunction with business
The SDC agent has been released as open-source software for Linux. Used as is, it provides
secure access to on-premises enterprise resources. This will allow, for example, a GAE-based
composite application to invoke Web-services-based, on-premises corporate business
functionality and data for authorized Google Apps users. In this scenario, it is assumed that GAE
developers can easily incorporate such direct calls to remote resources.
SDC natively provides basic integration connectivity; however, used as is, it still does not provide
other general-purpose integration functionality, such as translation or adapters. When more-

Publication Date: 4 May 2009/ID Number: G00167581 Page 7 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

robust enterprise application integration capabilities are required, the SDC agent can also be
modified and embedded into other solutions from ISVs, SIs, software-as-a-service (SaaS)
vendors, cloud computing providers and IT end users. This will allow, for example, an ISV to
implement a prepackaged integration solution that links GAE-based applications with the data
and services of on-premises SAP or Oracle applications, or other cloud-based services, such as and NetSuite.
Initially, to address the latter SDC use scenario, Google announced a partnership with Cast Iron,
which provides cloud computing/SaaS integration (see "Who's Who in Cloud Computing/SaaS
Integration, Volume 1"). Cast Iron is Google's first Google Enterprise Partner to incorporate SDC
agent support into its cloud computing/SaaS integration solutions, including its integration
appliances and its Cast Iron cloud IaaS offering. It has released prepackaged integrations
(labeled "template integration processes") which can be used with Google Gadgets to accelerate
development time in select recurring integration scenarios, such as integrating Google
applications with or SAP. Although it may be priced a bit high for users with very
cost-sensitive projects, Cast Iron's mature technology and flexible deployment options (including
IaaS) make it particularly well-suited to help companies solve more-challenging integration
problems involving Google applications with any combination of on-premises applications and
cloud-based services.
Google has also partnered with Appirio, an SI that specializes in helping companies deploy and
extend cloud-based functionality, such as Google Apps and, in the enterprise. It also
offers a set of eight prebuilt integration solutions called "Cloud Connectors" that integrate certain
cloud-based data and processes. For example, the Appirio Premium Sync solution synchronizes
calendar or contact data between Google Apps and When available to match a
particular pair-wise integration requirement, such packaged integrations can substantially reduce
(and, at times, fully eliminate) development work.
We expect that other vendors such as Bluewolf, Boomi, Celigo and Pervasive Software, will likely
soon also implement native SDC support in their cloud computing/SaaS integration solutions.
Such moves will drive the proliferation of packaged integration, and will also give Google Apps
users more alternatives for robust GAE connectivity to support custom enterprise integration
GAE developers should:
• Use SDC agents natively for simple integration projects based on Web services, but rely
on ISVs, SIs and other third-party technology partners to leverage SDC for more-
complex data and application integration requirements.
• When available (for frequently occurring scenarios), consider prepackaged integration
solutions to save deployment cost and time for pairwise integrations between GAE-
based applications and on-premises applications.
4.0 The Impact of BigTable and Java on Persistence
Analysis by Eric Knipp
GAE is built on top of BigTable, Google's cloud-optimized persistence platform. Although most
Java developers are comfortable working with traditional database management systems using
relational models, BigTable doesn't fit in this category. In fact, it is a distributed data store,
partitioned across an arbitrary number of commodity servers spread around Google's data

Publication Date: 4 May 2009/ID Number: G00167581 Page 8 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

centers. This architecture is necessary to support BigTable's extreme persistence capabilities
(see "Global-Class Persistence for Cloud-Based Web Applications").
BigTable is designed for applications with massive transactional requirements. Developers
constructing GAE applications access BigTable's features via the Google Datastore API.
Applications that use the Datastore API can benefit from the scalability of BigTable, but they are
constrained from using multithreaded programming, which prevents the use of map/reduce, a
powerful feature Google uses with BigTable for its applications (such as search). The GAE road
map includes plans for a background-processing feature, which may support limited types of
multithreaded programming.
The Datastore API is used to persist Plain Old Java Objects (POJOs) and has been optimized for
read performance. Google partnered with DataNucleus, an open-source object-relational
mapping project, to enable access to low-level Datastore APIs using the industry standards JDO
and Java Persistence API (JPA). Developers choose from either of these tools, or use the low-
level APIs directly to access BigTable. In addition, Python developers have access to a separate
set of APIs that performs the same function, although they cannot be combined with Java into a
single GAE project.
Although the DataNucleus implementations of JDO and JPA offer an SQL-like syntax, the
Datasource API does not support SQL, the "lingua franca" of database development, nor will it
enforce schema or other constraints at the database level. GAE pushes the responsibility of
validating data integrity onto the developer, who must also become comfortable with using
denormalized data. The Datastore APIs' capabilities are impressive, but they expose a gap in
traditional enterprise developers' programming skills, which may prove to be a stumbling block to
• JDO is designed to work with a range of persistence mechanisms, including OODBs, so
developers wishing to take advantage of the Datastore API should focus on using it in
their GAE projects. Although BigTable is not a pure OODB, it shares enough
characteristics to make the implementation of JDO a good fit.
Additional review and analysis was provided by Peter Firstbrook and Jay Heiser.
Note 1
Using AMI
Users can leverage AMI by contracting with Amazon and their application server providers to
implement desired technology in AMI, or by leveraging application platform technology already
hosted in AMI in cases where platform vendors have already established partnerships with
Amazon (or its analogous virtualization service providers) and offer a preconfigured platform AMI.
These are logistical variations on the shared-hardware model of multitenancy, further challenged
by the lack of automatic elasticity in the AMI offering.
Note 2
Does the SDC Make Google Thoroughly Secure?
Google's SDC announcement provides enough technical information to make a decision about
the robustness of this new interface, but it leaves questions unanswered about the security of
what lies beyond the interface. Just as it cannot be assumed that a SaaS offering is secure
because it uses Secure Sockets Layer (SSL), SDC only addresses a relatively small number of
potential attack modes, and should not automatically be taken as assurance that Google is
adequately secure for sensitive information.

Publication Date: 4 May 2009/ID Number: G00167581 Page 9 of
© 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Before using Google to process or store private, regulated or confidential information, a careful
assessment should be made as to the degree to which Google will protect that information from
its staff, other customers and external attackers (see "Assessing the Security Risks of Cloud
Computing"). Such an assessment can only be made by reviewing Google's technology and its
security processes, and ensuring that appropriate contractual mechanisms are in place.

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
+1 203 964 0096
European Headquarters
The Glanty
Surrey, TW20 9AW
+44 1784 431611
Asia/Pacific Headquarters
Gartner Australasia Pty. Ltd.
Level 9, 141 Walker Street
North Sydney
New South Wales 2060
+61 2 9459 4600
Japan Headquarters
Gartner Japan Ltd.
Aobadai Hills, 6F
7-7, Aobadai, 4-chome
Meguro-ku, Tokyo 153-0042
+81 3 3481 3670
Latin America Headquarters
Gartner do Brazil
Av. das Nações Unidas, 12551
9° andar—World Trade Center
04578-903—São Paulo SP
+55 11 3443 1509