INTO THE CLOUD

20.07.2010 An evaluation of the Google App Engine

Chornyi, Dmitry

Riediger, Julian

Wolfenstetter, Thomas

Into the Cloud

Page 1

Into the Cloud A N E V A L U A T I O N O F T H E G O O G L E A P P E N G I N E

Abstract

Cloud Computing is often glorified as one of the most important IT paradigms to shape the

next decade of IT. In this paper we illustrate the concepts as well as the technology behind

Cloud Computing in general and analyze one of the currently most popular platforms, the

Google App Engine. For this purpose we developed a sample application utilizing many of

the platforms features. Based on experiences that were made during implementation and

scalability testing we evaluate the Google App Engine and discuss whether it satisfies the

requirements of state-of-the-art software engineering. Finally we present an outlook on the

way ahead in Cloud Computing.

Keywords:

Cloud Computing, Google App Engine, Evaluation, Scalability testing, PaaS

Into the Cloud

Page 2

Content

OUTLINE .............................................................................................................................. 3

CLOUD COMPUTING IN A NUTSHELL .................................................................................. 3

Motivation .................................................................................................................................................. 3

Definition of Cloud Computing ............................................................................................................... 4

Service delivery models .......................................................................................................................... 4

GOOGLE APP ENGINE ......................................................................................................... 6

Architecture ................................................................................................................................................ 6

Costs ............................................................................................................................................................ 6

Features ...................................................................................................................................................... 7

Runtime Environment .............................................................................................................................. 7

Persistence and the datastore ............................................................................................................. 8

Services .................................................................................................................................................... 9

App Engine for Business ....................................................................................................................... 11

APPLICATION DEVELOPMENT USING GOOGLE APP ENGINE .......................................... 11

General Idea ......................................................................................................................................... 11

Requirements and functionality ........................................................................................................... 12

Implementation ....................................................................................................................................... 12

Development Environment ................................................................................................................. 12

Application Environment .................................................................................................................... 12

Application Architecture .................................................................................................................... 13

Platform Limitations ............................................................................................................................ 17

SCALABILITY TESTING ....................................................................................................... 18

Testing approach ................................................................................................................................... 18

Application scalability .......................................................................................................................... 19

DISCUSSION ....................................................................................................................... 20

Software Engineering Aspects ............................................................................................................ 20

Outlook: the way ahead in Cloud Computing ................................................................................. 23

New application opportunities and use cases............................................................................... 23

Challenges of Cloud Computing ...................................................................................................... 24

CONCLUSION .................................................................................................................... 26

ABBREVIATIONS ................................................................................................................ 27

TABLE OF FIGURES ............................................................................................................ 28

LITERATURE ....................................................................................................................... 29

Into the Cloud

Page 3

OUTLINE

In this paper we want to discuss the omnipresent topic Cloud Computing with a special focus on

application development using Googles platform-as-a-service (PaaS) environment, the Google App

Engine. First we give a general introduction on Cloud Computing where we will outline the motivation

behind this hype, give a definition of the term and explain the three service delivery models of Cloud

Computing. In a next step we draft a detailed picture of the Google App Engine, illustrating its

architecture, services and API. This section is followed by a report on an exemplary application

development project on the platform. Additionally, we sum up our experiences made during scalability

testing, before we finally discuss whether Google App Engine and Cloud Computing in general meet the

requirements of modern software engineering and if there is a paradigm shift in the mindsets of software

developers.

CLOUD COMPUTING IN A NUTSHELL

Motivation

In October 2008 the British weekly, The Economist praised Cloud Computing as the coining technology

for the IT world:

THE RISE OF THE CLOUD IS MORE THAN JUST ANOTHER PLATFORM SHIFT THAT GETS GEEKS EXCITED. IT WILL

UNDOUBTEDLY TRANSFORM THE IT INDUSTRY, BUT IT WILL ALSO PROFOUNDLY CHANGE THE WAY PEOPLE

WORK AND COMPANIES OPERATE. IT WILL ALLOW DIGITAL TECHNOLOGY TO PENETRATE EVERY NOOK AND

CRANNY OF THE ECONOMY AND OF SOCIETY, CREATING SOME TRICKY POLITICAL PROBLEMS ALONG THE WAY

(1).

Indeed, when looking at the Google Trends graph for search volume worldwide, (see Figure 1) one

realizes that since 2007 the term Cloud Computing has become increasingly popular, at least in terms

of online search behavior.

FIGURE 1: GLOBAL SEARCH VOLUME INDEX FOR CLOUD COMPUTING (2)

The dream behind Cloud Computing is that, as long as users can connect to the Internet, they have the

entire Web as their computing center. When compared to the infinitely powerful Internet Cloud, personal

computers seem like lightweight terminals allowing users to utilize the cloud. From this perspective, Cloud

Computing may seem like a return to the original mainframe paradigm from the 60s to 70s (3). Critics

therefore accuse Cloud Computing to be old wine in new skins. They argue that it is just a temporary

fashion term within the IT community. No matter whether The Economists optimistic scenario will occur or

the critics will be right after all, the technology behind Cloud Computing is more than interesting enough

to be studied in detail.

Into the Cloud

Page 4

Definition of Cloud Computing

Recent literature review (4) has shown that Cloud Computing is still a fuzzy term and all existing

definitions have little in common. Moreover, distinguishing Clouds from Grids is definitely not trivial as

both approaches are closely related to each other. The most noticeable differences is that in contrast to

Grid Computing, which focuses on sharing distributed resources dynamically at runtime, Cloud Computing

aims at virtualization (5). In this context there are several approaches that aim at combining the

advantages of clouds and grids, which can also be seen as a combination of advanced networking with

sophisticated virtualization (4). When looking for a universal definition of Cloud Computing, one has to

consider multiple aspects. The essential characteristics of Cloud Computing can be circumscribed as on-

demand self-service, rapid elasticity, resource pooling, ubiquitous network access and measured service

(6). Furthermore, there are different deployment models. Cloud Computing can be operated as a

private, public, community or hybrid Cloud. Public Clouds are available to everybody in a pay-as-you-

go manner. Current examples of public Clouds include Amazon Web Services (7), Google App Engine (8)

and Microsoft Azure (9). Private Clouds on the other side refer to internal datacenters of a business or

other organization that are not made available to the public. Community Clouds are shared by several

organizations and are usually setup for their specific requirements. Hybrid Clouds are a mixture of the

above three deployment models. Each Cloud in the hybrid model can be independently managed but

applications and data are allowed to move across the hybrid Cloud. Therefore hybrid Clouds allow

cloud bursting to take place, which is where a private Cloud can burst-out to a public Cloud when it

requires more resources (10) (11). Based on these observations we adopt the Cloud Computing definition

by Vaquero et al. (4):

CLOUDS ARE A LARGE POOL OF EASILY USABLE AND ACCESSIBLE VIRTUALIZED RESOURCES (SUCH AS

HARDWARE, DEVELOPMENT PLATFORMS AND/OR SERVICES). THESE RESOURCES CAN BE DYNAMICALLY RE-

CONFIGURED TO ADJUST TO A VARIABLE LOAD (SCALE), ALLOWING ALSO FOR AN OPTIMUM RESOURCE

UTILIZATION. THIS POOL OF RESOURCES IS TYPICALLY EXPLOITED BY A PAY-PER-USE MODEL IN WHICH

GUARANTEES ARE OFFERED BY THE INFRASTRUCTURE PROVIDER BY MEANS OF CUSTOMIZED SLAS.

Service delivery models

In general Cloud Computing services can be divided into three different service delivery models:

Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). As it

is shown in Figure 2, these delivery models can be seen in a hierarchic context. To the end user only SaaS

is visible, while developers use PaaS and IaaS to deploy their applications. Subsequently, the three

occurrences of Cloud Computing are introduced individually.

Into the Cloud

Page 5

FIGURE 2: SERVICE DELIVERY MODELS OF CLOUD COMPUTING (12)

Infrastructure-as-a-Service

IaaS products deliver a complete computer infrastructure remotely via the Internet. They provide machine

instances to developers, which essentially behave like dedicated servers, controlled by the developers.

This means that the developer has full responsibility for server operation and once a machine reaches its

performance limits, the developer has to manually instantiate another machine and to scale the

application out to it. To sum up, IaaS is intended for developers who want to write arbitrary software on

top of the infrastructure with only small compromises in their development methodology (12).

Platform-as-a-Service

PaaS are situated one level higher within the Cloud Computing hierarchy. They provide a full or partial

application development environment that abstracts machine instances and other technical details from

the developer. The applications are executed within data centers, not concerning the developers with

matters of allocation. In exchange for this, the developers have to handle some constraints that the

environment imposes on their application design, for example the use of special data stores instead of

relational databases (12).

Software-as-a-Service

At the consumer-facing level there are the most popular examples of Cloud Computing, with well-defined

applications offering users online resources and storage. This differentiates SaaS from traditional

websites or web applications which do not interface with user information or do so in a limited manner

(12). SaaS offers complex applications such as CRM or ERM online (5).

Figure 3 illustrates the different service delivery models of Cloud Computing and lists major vendors of

each domain as an example.

Into the Cloud

Page 6

FIGURE 3: MAJOR TYPES OF CLOUD SERVICES (ADAPTED FORM (5))

GOOGLE APP ENGINE

Architecture

The Google App Engine (GAE) is Google`s answer to the ongoing trend of Cloud Computing offerings

within the industry. In the traditional sense, GAE is a web application hosting service, allowing for

development and deployment of web-based applications within a pre-defined runtime environment.

Unlike other cloud-based hosting offerings such as Amazon Web Services that operate on an IaaS level,

the GAE already provides an application infrastructure on the PaaS level. This means that the GAE

abstracts from the underlying hardware and operating system layers by providing the hosted

application with a set of application-oriented services. While this approach is very convenient for

developers of such applications, the rationale behind the GAE is its focus on scalability and usage-based

infrastructure as well as payment.

Costs

Developing and deploying applications for the GAE is generally free of charge but restricted to a

certain amount of traffic generated by the deployed application. Once this limit is reached within a

certain time period, the application stops working. However, this limit can be waived when switching to a

billable quota where the developer can enter a maximum budget that can be spent on an application

per day. Depending on the traffic, once the free quota is reached the application will continue to work

until the maximum budget for this day is reached. Table 1 summarizes some of the in our opinion most

important quotas and corresponding amount per unit that is charged when free resources are depleted

and additional, billable quota is desired.

IaaS

Amazon EC2 Joyent Sun Microsofts Network.com HP Flexible Computing Services

IBM Blue Cloud 3tera OpSource Jamcracker

PaaS

Bungee Labs Bungee Connect

Etelos Coghead Google App Engine HP Adaptive Infrastructure as a Service

Salesforce.com LongJump

Saas

Oracle SaaS platform Salesforce Sales Force Automation

NetSuite Google Apps Workday Human Capital Management

Into the Cloud

Page 7

Free Default Quota Billing Enabled Default Quota Cost

Daily Limit Maximum Rate Daily Limit Maximum Rate

General Limits

Requests 1.3 mio 7,400 req/minute 43 mio 30,000 req/min n/a

Bandwidth In 1GB 56 MB/minute 1,046 GB 10 GB/min $0.10/GB

Bandwidth Out 1 GB 56 MB/minute 1,046 GB 10 GB/min $0.12/GB

CPU Time 6.5 CPU-h 15 CPU-min/min 1,729 CPU-h 72 CPU-min/min $0.10/CPU-h

Data Store

Stored Data 1 GB no maximum $0.15/GB/month

# of Indexes 100 200 n/a

Queries 10 mio 57,000/min 200 mio 129,000/min n/a

CPU Time 60 CPU-h 20 CPU-min/min 1,200 CPU-h 50 CPU-min/min n/a

Mail Service

Recipients 2,000 8/min 7.4 mio 5,100/min $0.0001/recipient

URL Fetch Service

API Calls 657,000 calls 3,000/min 46 mio. calls 32,000/min n/a

Memcache Service

API Calls 8,600,000 48,000/min 96,000,000 108,000/min n/a

Task Queue Service

API Calls 100,000 n/a 1mio n/a n/a

Stored Tasks 1 mio max 10 mio max n/a TABLE 1: GAE QUOTA AND BILLING (ADAPTED FROM (8))

Features

With a Runtime Environment, the Datastore and the App Engine services, the GAE can be divided into

three parts.

Runtime Environment

The GAE runtime environment presents itself as the place where the actual application is executed.

However, the application is only invoked once an HTTP request is processed to the GAE via a web

browser or some other interface, meaning that the application is not constantly running if no invocation or

processing has been done. In case of such an HTTP request, the request handler forwards the request and

the GAE selects one out of many possible Google servers where the application is then instantly

deployed and executed for a certain amount of time (8). The application may then do some computing

and return the result back to the GAE request handler which forwards an HTTP response to the client. It is

important to understand that the application runs completely embedded in this described sandbox

environment but only as long as requests are still coming in or some processing is done within the

application. The reason for this is simple: Applications should only run when they are actually computing,

otherwise they would allocate precious computing power and memory without need. This paradigm shows

already the GAEs potential in terms of scalability. Being able to run multiple instances of one application

independently on different servers guarantees for a decent level of scalability. However, this highly

flexible and stateless application execution paradigm has its limitations. Requests are processed no

longer than 30 seconds after which the response has to be returned to the client and the application is

removed from the runtime environment again (8). Obviously this method accepts that for deploying and

Into the Cloud

Page 8

starting an application each time a request is processed, an additional lead time is needed until the

application is finally up and running. The GAE tries to encounter this problem by caching the application

in the server memory as long as possible, optimizing for several subsequent requests to the same

application. Furthermore, the stateless execution creates the need for a sophisticated solution for

persistence which will be presented in detail in the following chapter.

The type of runtime environment on the Google servers is dependent on the programming language

used. For Java or other languages that have support for Java-based compilers (such as JRuby, Rhino and

Groovy) a Java-based Java Virtual Machine (JVM) is provided. Also, GAE fully supports the Google

Web Toolkit (GWT), a framework for rich web applications. For Python and related frameworks a

Python-based environment is used.

FIGURE 4: STRUCTURE OF GOOGLE APP ENGINE (13)

Persistence and the datastore

As previously discussed, the stateless execution of applications creates the need for a datastore that

provides a proper way for persistence. Traditionally, the most popular way of persisting data in web

applications has been the use of relational databases. However, setting the focus on high flexibility and

scalability, the GAE uses a different approach for data persistence, called Bigtable (14). Instead of rows

found in a relational database, in Googles Bigtable data is stored in entities. Entities are always

associated with a certain kind. These entities have properties, resembling columns in relational database

schemes. But in contrast to relational databases, entities are actually schemaless, as two entities of the

same kind not necessarily have to have the same properties or even the same type of value for a certain

property.

The most important difference to relational databases is however the querying of entities within a

Bigtable datastore. In relational databases queries are processed and executed against a database at

application runtime. GAE uses a different approach here. Instead of processing a query at application

runtime, queries are pre-processed during compilation time when a corresponding index is created. This

index is later used at application runtime when the actual query is executed. Thanks to the index, each

query is only a simple table scan where only the exact filter value is searched. This method makes

queries very fast compared to relational databases while updating entities is a lot more expensive.

Into the Cloud

Page 9

Transactions are similar to those in relational databases. Each transaction is atomic, meaning that it either

fully succeeds or fails. As described above, one of the advantages of the GAE is its scalability through

concurrent instances of the same application. But what happens when two instances try to start

transactions trying to alter the same entity? The answer to this is quite simple: Only the first instance gets

access to the entity and keeps it until the transaction is completed or eventually failed. In this case the

second instance will receive a concurrency failure exception. The GAE uses a method of handling such

parallel transactions called optimistic concurrency control. It simply denies more than one altering

transaction on an entity and implicates that an application running within the GAE should have a

mechanism trying to get write access to an entity multiple times before finally giving up.

Heavily relying on indexes and optimistic concurrency control, the GAE allows performing queries very

fast even at higher scales while assuring data consistency.

FIGURE 5: BIGTABLE STRUCTURE (14)

Services

As mentioned earlier, the GAE serves as an abstraction of the underlying hardware and operating

system layers. These abstractions are implemented as services that can be directly called from the actual

application. In fact, the datastore itself is as well a service that is controlled by the runtime environment

of the application.

MEMCACHE

The platform innate memory cache service serves as a short-term storage. As its name suggests, it stores

data in a servers memory allowing for faster access compared to the datastore. Memcache is a non-

persistent data store that should only be used to store temporary data within a series of computations.

Probably the most common use case for Memcache is to store session specific data (15). Persisting session

information in the datastore and executing queries on every page interaction is highly inefficient over the

application lifetime, since session-owner instances are unique per session (16). Moreover, Memcache is

well suited to speed up common datastore queries (8). To interact with the Memcache GAE supports

JCache, a proposed interface standard for memory caches (17).

URL FETCH

Because the GAE restrictions do not allow opening sockets (18), a URL Fetch service can be used to send

HTTP or HTTPS requests to other servers on the Internet. This service works asynchronously, giving the

remote server some time to respond while the request handler can do other things in the meantime. After

the server has answered, the URL Fetch service returns response code as well as header and body. Using

the Google Secure Data Connector an application can even access servers behind a companys firewall

(8).

MAIL

The GAE also offers a mail service that allows sending and receiving email messages. Mails can be sent

out directly from the application either on behalf of the applications administrator or on behalf of users

Into the Cloud

Page 10

with Google Accounts. Moreover, an application can receive emails in the form of HTTP requests initiated

by the App Engine and posted to the app at multiple addresses. In contrast to incoming emails, outgoing

messages may also have an attachment up to 1 MB (8).

XMPP

In analogy to the mail service a similar service exists for instant messaging, allowing an application to

send and receive instant messages when deployed to the GAE. The service allows communication to and

from any instant messaging service compatible to XMPP (8), a set of open technologies for instant

messaging and related tasks (19).

IMAGES

Google also integrated a dedicated image manipulation service into the App Engine. Using this service

images can be resized, rotated, flipped or cropped (18). Additionally it is able to combine several

images into a single one, convert between several image formats and enhance photographs. Of course

the API also provides information about format, dimensions and a histogram of color values (8).

USERS

User authentication with GAE comes in two flavors. Developers can roll their own authentication service

using custom classes, tables and Memcache or simply plug into Googles Accounts service. Since for most

applications the time and effort of creating a sign-up page and store user passwords is not worth the

trouble (18), the User service is a very convenient functionality which gives an easy method for

authenticating users within applications. As byproduct thousands of Google Accounts are leveraged. The

User service detects if a user has signed in and otherwise redirect the user to a sign-in page.

Furthermore, it can detect whether the current user is an administrator, which facilitates implementing

admin-only areas within the application (8).

OAUTH

The general idea behind OAuth is to allow a user to grant a third party limited permission to access

protected data without sharing username and password with the third party. The OAuth specification

separates between a consumer, which is the application that seeks permission on accessing protected

data, and the service provider who is storing protected data on his users' behalf (20). Using Google

Accounts and the GAE API, applications can be an OAuth service provider (8).

SCHEDULED TASKS AND TASK QUEUES

Because background processing is restricted on the GAE platform, Google introduced task queues as

another built-in functionality (18). When a client requests an application to do certain steps, the

application might not be able to process them right away. This is where the task queues come into play.

Requests that cannot be executed right away are saved in a task queue that controls the correct

sequence of execution. This way, the client gets a response to its request right away, possibly with the

indication that the request will be executed later (13).

Similar to the concept of task queues are cron jobs. Borrowed from the UNIX world, a GAE cron job is a

scheduled job that can invoke a request handler at a pre-specified time (8).

BLOBSTORE

The general idea behind the blobstore is to allow applications to handle objects that are much larger

than the size allowed for objects in the datastore service. Blob is short for binary large object and is

designed to serve large files, such as video or high quality images. Although blobs can have up to 2 GB

they have to be processed in portions, one MB at a time. This restriction was introduced to smooth the

curve of datastore traffic. To enable queries for blobs, each has a corresponding blob info record which

is persisted in the datastore (8), e. g. for creating an image database.

Into the Cloud

Page 11

ADMINISTRATION CONSOLE

The administration console acts as a management cockpit for GAE applications. It gives the developer

real-time data and information about the current performance of the deployed application and is used

to upload new versions of the source code. At this juncture it is possible to test new versions of the

application and switch the versions presented to the user. Furthermore, access data and logfiles can be

viewed. It also enables analysis of traffic so that quota can be adapted when needed. Also the status of

scheduled tasks can be checked and the administrator is able to browse the applications datastore and

manage indices (8).

App Engine for Business

While the GAE is more targeted towards independent developers in need for a hosting platform for

their medium-sized applications, Google`s recently launched App Engine for Business tries to target the

corporate market. Although technically mostly relying on the described GAE, Google added some

enterprise features and a new pricing scheme to make their cloud computing platform more attractive for

enterprise customers (21).

Regarding the features, App Engine for Business includes a central development manager that allows a

central administration of all applications deployed within one company including access control lists. In

addition to that Google now offers a 99.9% service level agreement as well as premium developer

support.

Google also adjusted the pricing scheme for their corporate customers by offering a fixed price of $8

per user per application, up to a maximum of $1000, per month. Interestingly, unlike the pricing scheme

for the GAE, this offer includes unlimited processing power for a fixed price of $8 per user, application

and month. From a technical point of view, Google tries to accommodate for established industry

standards, by now offering SQL database support in addition to the existing Bigtable datastore

described above (8).

APPLICATION DEVELOPMENT USING GOOGLE APP ENGINE

General Idea

In order to evaluate the flexibility and scalability of the GAE we tried to come up with an application

that relies heavily on scalability, i.e. collects large amounts of data from external sources. That way we

hoped to be able to test both persistency and the gathering of data from external sources at large

scale.

Therefore our idea has been to develop an application that connects people`s delicious bookmarks with

their respective Facebook accounts. People using our application should be able to see what their

Facebook friends delicious bookmarks are, provided their Facebook friends have such a delicious

account. This way a user can get a visualization of his friends latest topics by looking at a generated tag

cloud giving him a clue about the most common and shared interests.

In order to provide such a service within our application we had to integrate both Facebook as well as

delicious and persist the fetched data in the GAE datastore. Although all data could as well always be

fetched in real-time, there are two reasons to persist bookmarks from delicious as well as personal

details from the respective Facebook accounts. First, from a user perspective, reading out the information

from a GAE data store is much faster than re-fetching everything at runtime. Second and more important

Into the Cloud

Page 12

for this project is the need to test the scalability of the data store and the GAE in general. So in order to

draw substantial conclusions about the scalability of the GAE, testing persistency remains essential.

Requirements and functionality

Before we started implementing the application we studied the relevant APIs of affected service

providers as well as similar applications. Furthermore, we asked a number of potential users on their

opinion how the user interface should look like and aligned them with our own design visions. The result

was a collection of requirements which is illustrated in Table 2.

Functional Requirements Non-functional Requirements

User Interface Backend

Login to a delicious

account

Filter friends and their

bookmarks

Filter bookmarks by tags

Visualize bookmarks in a

tag cloud

Show all bookmarks in a

list

Fetch bookmarks from

delicious and persist them

Fetch personal details and

friends from Facebook and

persist them

Update and persist new

bookmarks from delicious

Update and persist new

Facebook details

Application has to be

scalable up to 1000

parallel users

Secure & reliable

authentication with

Facebook & delicious

Application should run

within Facebook using an

iFrame

TABLE 2: APPLICATION REQUIRMENTS

Implementation

Development Environment

Because of our expertise in Java and familiarity with the Eclipse IDE, we decided to use both for

developing our application. Furthermore, by using Eclipse we were able to use the GAE plugin that

improves the development and debugging of a local GAE application significantly. Also, we agreed on

using the Google Web Toolkit (GWT), a Java framework that helps developing rich web applications

with AJAX-based user interfaces.

In order to develop our application supported by a proper source code versioning tool, we made use of

a free SVN server provided by Assembla.com.

Application Environment

As stated in the requirements, the application should run embedded within the Facebook website. As

depicted in Figure 6, a user can find and select the application via Facebook and send a request to start

the application within Facebook. This will trigger a request for an iFrame that is forwarded to the GAE

where the actual application is started. The GAE will then call the Facebook API and wait for a response.

As soon as the response is received by the GAE, it returns the iFrame with the application to the user. The

application is then visible within an iFrame in the Facebook UI and is ready to be used. If the user is not

yet logged in to delicious he can now do so. The login to delicious is done via Yahoo authentication. So

the GAE sends a request for authentication to Yahoos authentication servers and receives an access

token. With this access token our application running within the GAE can then access the user`s bookmarks

by requesting them from the delicious servers.

Into the Cloud

Page 13

FIGURE 6: APPLICATION ARCHITECTURE (OWN ILLUSTRATION ADAPTED FROM (21) (22) (23) (8))

Application Architecture

LAYER & COMPONENT OVERVIEW

Our application is based on a Three-Tier client/server architecture (24) incorporating a presentation, an

application/business logic and a data tier. Figure 7 shows an overview of the components and layers

involved. The presentation layer is represented by the component web browser. Based on the GWT, Java

code is automatically compiled into AJAX code running within the client`s web browser.

The depicted business logic component includes various services which interact with external service

providers APIs such as Facebook, Yahoo and Delicious as well as with the data and presentation layer.

With the presentation layer the business logic layer interacts via both HTTP requests and RPC calls.

Additionally, the business logic layer uses an XML parser to process data received from the delicious API.

The data layer is fully represented by the GAE. Although offering more services than data persistency,

the GAE serves as our main data layer. The business logic layer uses the Memcache API to store data

temporarily and utilizes the datastore API to persist data.

In addition to that the GAE also offers a Logging API and a Task API which we both utilize from the

business logic layer. These two features do not belong to the data layer, but have been added in the

diagram to show the whole functionality leveraged from the GAE.

Into the Cloud

Page 14

FIGURE 7: DIAGRAM OF LAYERS AND COMPONENTS (OWN ILLUSTRATION)

CLASS OVERVIEW

In the following paragraph we will present the applications architecture by showing a class overview for

each of the three layers, namely the business logic layer, the presentation layer and the data layer.

Business Logic Layer

Essentially, five classes build up the business logic layer. The class FacebookServiceImpl implements the

access to the Facebook API by providing methods for retrieving friends for a certain Facebook user.

DeliciousServiceImpl and DeliciousFeedConnector both implement the access to the delicious backend.

Access to the data layer via the datastore API is realized by the class PMF which returns a handle to the

GAE`s PersistenceManagerFactory. In order to communicate with the presentation layer, the class

UserServiceImpl implements the server side of the GAE`s RPC service.

Into the Cloud

Page 15

FIGURE 8: CLASS DIAGRAMM OF BUSINESS LAYER (OWN ILLUSTRATION)

Presentation Layer

The presentation layer is distributed over several sub-packages, in order to fulfill the division between

the parts of the presentation layer that are fully server- and those that are solely client-based. The

classes BookmarkTable, BookmarkWidget, FilterWidget and TagCloudWidget represent the main

functionality in terms of displaying bookmarks by user, filtering bookmarks and users and creating a tag

cloud navigation for accessing bookmarks within the web-based UI. Although these classes are written in

pure Java, the GWT automatically compiles them into AJAX-enabled JavaScript code. Both the

DeliciousLoginWidget and the FacebookLoginWidget classes provide functionality for the user to login to

Facebook and Delicious. The classes Gwtapp, Global and Modality represent GWT abstractions of the

actual presentation layer runtime environment in the clients web browser.

Into the Cloud

Page 16

FIGURE 9: CLASS DIAGRAMM OF PRESENTATION LAYER (OWN ILLUSTRATION)

Data Layer

In order to persist data within the GAE, we are using JDO classes. Although Googles BigTable is by

definition a schema-less database, the JDO classes serve as a means to define the schema for kinds of

entities (see GAE introduction).This way BookmarkJDO and UserJDO define the schema for bookmarks

that are persisted in the datastore as well as for user data that is stored.Not depicted in the diagram

above, data access classes such as BookmarkDO are used for data representation within the application.

Into the Cloud

Page 17

FIGURE 10: CLASS DIAGRAM OF DATA LAYER (OWN ILLUSTRATION)

Platform Limitations

At its core, GAE restricts the access to the physical infrastructure. This includes preventing the application

from opening sockets, running background processes (except cron jobs) and using other common back-

end routines that application developers normally take for granted (18). The following chapter dwells on

the limitations of the GAE that we directly encountered during our application development. We know

that there are several more limitations especially in terms of enterprise-centric applications for the GAE,

but these will be discussed later.

BACKGROUND PROCESSING

Due to the character of the GAE, intense background processing is not possible within applications. As

client requests are subject to a certain time limit, the ability to process large chunks of data is quite

limited.

TRANSACTIONS

Another limitation is the inability of using the Memcache and the data store within one transaction. This

limitation is quite a problem when processing large amounts of data. In our scenario we wanted to fetch

all user bookmarks from delicious and persist them in the data store. As the amount of entities that can be

handled per transaction is limited as well, we tried to buffer all data in the Memcache temporarily. From

there we wanted to persist small portions of the buffered data within the data store. After successfully

storing the extracted data from the buffer in the data store, there has been no way of accessing the

Memcache once again within this transaction and deleting the stored data from the Memcache. This way

it is unknown whether certain entities have already been stored when accessing the Memcache for the

subsequent transaction, trying to read the next chunk of buffered data to make it persistent within the

data store. The only way to circumvent this problem is by deleting the part of the data that is used by

the current transaction before the transaction is actually triggered. However, using this method means

risking the loss of already fetched data, in case the transaction fails.

Into the Cloud

Page 18

DATA STORE QUERYING LIMITATIONS

Although the underlying Bigtable data storage approach is quite different to traditional SQL

approaches, the used Java Data Objects Query Language (JDOQL) tries to provide an SQL-like query

language (25). However, certain features available in traditional SQL approaches are not available in

the GAE environment. By design joins of tables are not possible within the GAE because it features a non-

relational database. Also, certain combinations of filtering operators such as cannot be used

at the same time within a single query.

SCALABILITY TESTING Good on-demand scalability is one of the key features that the GAE offers. A scalable system should be

able to proportionally increase the amount of work it performs, as available resources increase. In order

to check whether GAE lives up to its promise of effortless scalability, we modified the described

application from the last chapter in order to gather and evaluate performance data.

Testing approach

With GAE application instances running on a standardized, relatively low-power virtual hardware and

having response time limited to 30 seconds for any request, scalability translates into parallelization. By

utilizing a concurrent algorithm and spreading work over multiple VM instances simultaneously, as the

number of VM instances grows, an application should ideally execute linearly faster, compared to the

sequential algorithm. This, of course, presumes that the algorithm it executes can be parallelized in the

first place.

One of the easily parallelizable tasks is crawling data sources for various datafor instance,

downloading existing bookmarks from delicious.com in bulk. Out of the described application in the last

chapter we developed a Delicious Crawleran application that starts with a random user, then

downloads and saves his bookmarks and friends. Then in turn, for each friend it downloads his

bookmarks, friends list, and so forth, effectively performing a breadth-first search. The Delicious crawler

saves a total of 100 users and 1600 bookmarks per run.

The operation of the Delicious Crawler is visualized in Figure 11. A request triggered by task queue

instructs the crawler to:

1. Take a UserJDO class (represents a delicious user) from the FIFO queue

2. For this user, read bookmarks and friends using the delicious.com JSON feed API

3. Convert received data to classes that can be persisted

4. Save the user and bookmarks to the Bigtable datastore

5. Enqueue the friends to the FIFO queue

6. Enqueue a task in the task queue

As these operations are executed, performance data is logged. This includes the time to execute

URLFetch and Persistence API requests, as well as the overall request processing duration.

Since the described workflow can be executed concurrently, thus processing multiple users simultaneously,

the developed Delicious Crawler is a suitable candidate for our scalability testing. By setting the rate

attribute of the task queue to 50/second (maximum), and varying the bucket-size between 1 (minimum)

and 50 (maximum), we were able to test the performance of the Delicious Crawler with 1 to 50

concurrent threads. The results are discussed in the next section.

Into the Cloud

Page 19

FIGURE 11. CRAWLER (OWN ILLUSTRATION)

Application scalability

Figure 12 shows the total time it took Delicious Crawler to process 100 users and 1600 bookmarks for

various bucket sizes. As we see, performance increases up to eight parallel threads and then levels.

FIGURE 12. TOTAL DURATION (OWN ILLUSTRATION)

One explanation for the disappointing results when using 16 or more threads could be possible

temporary technical problems at the App Engine at the time of testing, or an automatic throttling by

Google, as the error message presented in Figure 13 may suggest. Such errors occurred a total of 53

Into the Cloud

Page 20

times out of 700 task queue executions. These errors possibly explain the extreme outliers seen in Figure

14, where detailed data for bucket size 16 is shown.

FIGURE 13 ERROR MESSAGE IN ADMINISTRATION CONSOLE (8)

FIGURE 14 TIME PER REQUEST AND SERVICE (OWN ILLUSTRATION)

Since we only did a brief scalability testing, results may be affected by idiosyncrasies ranging from the

local network connection latencies to temporary technical problems at delicious or the App Engine itself.

Thus, the results should not be generalized for use scenarios beyond of what we tested.

DISCUSSION

The following section tries to discuss whether Cloud Computing in general and the GAE in particular are

able to serve the needs and requirements of modern software engineering. First each aspect will be

discussed in general terms which is followed by a GAE-specific reflection.

Software Engineering Aspects

Functional Aspects

As discussed in the introduction, PaaS environments set certain restrictions to the developer in terms of

programming techniques, languages and other elsewhere available functionality. In contrast to that, IaaS

environments such as Amazon Web Services give the developer more freedom and flexibility, however

at the cost of having less features or functionality pre-built. This shows the trade-off between developers

Into the Cloud

Page 21

flexibility and pre-built functionality. The more the application requirements match with GAEs pre-built

functionality, the easier and faster it will be to develop applications for the GAE compared to an IaaS

platform such as Amazon Web Services. However, if the match is quite low, GAEs restrictions outweigh

the benefits of the pre-built functionality and an IaaS provider might be the better choice in the that

case.

Usability

Cloud Computing adopts the concept of Utility Computing, which presents the very idea that users obtain

and employ computing platforms in Clouds as easily as they access a traditional public utility

infrastructure (such as electricity, water or telephone network) (22). The same expectations are there for

the GAE from a developer`s perspective. Usability-wise the GAE offers easy access to the domain of

Cloud Computing by providing abstractions for important services such as persistence as well as an easy

to use development environment.

Scalability

The central design goal of the GAE is to address concerns about scalability. The platform is built on the

concept of horizontal scaling. In essence, this means that instead of running an application on more

powerful hardware, the application is executed on more instances of less powerful hardware (16).

Being a PaaS solution, the GAE offers a wide portfolio of built-in services that can be easily integrated

into a GAE-deployed application. This includes its built-in scalability feature as well as its persistence

abstraction. At least in theory built-in scalability and the persistence abstraction can be seen as one of

the most interesting USPs that the GAE has to offer. Using the distributed application deployment

approach along with an extremely scalable Bigtable database approach, the GAE already delivers all

tools to build applications that are highly scalable. However, in reality certain purposely set restrictions

limit the scalability of the GAE at the moment, as our tests have shown. Nevertheless, numerous Google

services such as Gmail show the GAEs technical potential in terms of scalability as the underlying layers

for scalability and especially for persistence are the same. The emergence of Google App Engine for

Business shows that Google is currently trying to loosen the named restrictions and make the GAE

attractive for enterprise applications that may then fully utilize its scalability features.

Integration

The need will arise for migrating and integrating applications and data from different clouds. This will

bring a new form of cloud service, that is cloud integration service (23). At the moment the GAE does not

offer any direct support to do so, although data from external clouds can be integrated by the tools and

services offered within the GAE.

Availability

It is impossible to provide 100% availability, unless a high availability architecture is adopted and both

the platform and applications are fully tested. Enterprise users should seek service level agreements

(SLAs) that will motivate the vendors to ensure desired levels of availability. Besides the SLA, users who

require 100% availability may take a combination of precautionary measures. With data, they may

maintain a backup on on-premises storage, or use a backup cloud, or simply not store mission-critical

data on the cloud. With applications, the users may keep an on-premises version of the application, so

that they may work offline while the cloud is down (23).

In November 2007, RackSpace, Amazons competitor, stopped its service for 3 hours because of power

cut-off at its data center; in June 2008, Google App Engine service broke off for 6 hours due to some

bugs of storage system; In March 2009, Microsoft Azure experienced 22 hours out of service caused by

Into the Cloud

Page 22

OS system update. Currently, the public cloud provider based on virtualization, defines the reliability of

service as 99.9% in SLA (24).

Google itself does not guarantee any service level agreements for the basic version of the GAE.

However, the recently launched GAE for Business specifically includes a 99.9% SLA. It remains to be seen

how and if this promise will be met in future.

Support

In fact, cloud services should be designed for easier usability than on-premises computing in the first

place (23). Especially PaaS platforms such as the GAE have by definition a higher need for developer

support as the features/services provided are mostly non-standardized. In contrast to IaaS solutions

where the basic hardware and operating system layers are mostly the same to traditional deployment

approaches, PaaS platforms need a detailed description of the supported features and services. The

GAE offers some documentation on how to use the platform, but in the basic version no professional

support is available. The upcoming business edition of the GAE will offer a real support option, however.

Privacy

Customers may be able to sue enterprises if their privacy rights are violated, and in any case the

enterprises may face damage to their reputation. Current privacy concepts such as the Fair Information

Principles are applicable to cloud computing scenarios and mitigate the risks. Tips for SE:

1. Minimize personal information sent to and stored in the cloud

2. Protect personal information in the cloud

3. Maximize user control

4. Allow user choice

Privacy should be built into every stage of the product development process: it is not adequate to try to

bolt on privacy at a late stage in the design process. (25).

Cloud computing vendors must adopt the most sophisticated and up-to-date tools and procedures, and

strive to provide better security and privacy than is available for on-premises computing (8).

In terms of the GAE, Googles general privacy notes are applicable. To evaluate the real level of

privacy, especially of the data stored within in the GAE, one would have to perform further privacy-

related tests that can deliver meaningful insights.

User Authentication

For user authentication the GAE comes along with the Google authentication service. This enables

developers to easily integrate logins for Google accounts into their applications. Given the acceptance

of Google accounts, this feature is really useful and a great advantage compared to IaaS solutions

where authentication has to be handled by the developer on its own.

Legal Issues and Compliance

Enterprise users must maintain business legal documents and assure their integrity in order to comply with

various laws. Cloud computing vendors have to adopt technologies to ensure that their enterprise users

data satisfy their compliance requirements. Again, this does not seem to have received much attention yet

(23). At this stage the GAE does not make any specifications about legal issues and compliance. For

applications that are heavily dependent on such restrictions, the GAE might not be the right choice at this

Into the Cloud

Page 23

point in time. But once again, Google has to look into these issues when becoming a serious PaaS

provider on the enterprise level as its start of the GAE for Business suggests.

Cost

The 3rd party provider owns and manages all the computing resources (servers, software, storage and

networking) and electricity needed for the services. The users only need to plug into the cloud. The users

do not need to make a large upfront investment on computing resources; the space needed to house

them; electricity needed to run the computing resources; and the cost of maintaining staff for

administering the system, network, and database (23).

In terms of costs, the GAE offers a usage-dependent pricing scheme that starts with a basic version which

is free of charge but subject to certain limitations. The paid version of the GAE removes some of these

limitations, however other limitations still exist caused by the GAEs design. As no upfront investments are

necessary, the GAE is a good way to test new applications (even for free) and pay as the acceptance

and spread of the application grows.

Interestingly, the recently launched GAE for Business goes into a different direction, as Google now

offers a flat-rate pricing scheme for enterprise users.

Advantages for the software developer

In the next two decades, service-oriented distributed computing will emerge as a dominant factor in

shaping the industry, changing the way business is conducted and how services are delivered and

managed (32).

This example is not intended to discredit the paradigm, just the exaggerated and premature claims of

end-user empowerment. On the contrary, even if lay end users wont be able to whip up a serious

enterprise application in a matter of days, cloud computing opens up exciting new possibilities based on

a mix of old and new technologies for the next generation of software developers (33).

Outlook: the way ahead in Cloud Computing

New application opportunities and use cases

It is foreseeable that Cloud Computing will affect the world of IT in two ways. On the one hand it will

fundamentally change the way existing applications are designed and on the other hand it will create

whole new use-cases. Chun and Maniatis (31) describe one such use-case, where cloud computing enables

a technology which otherwise would not be possible: to overcome hardware limitations and enable more

powerful mobile interactive applications, external resources are used by partially shifting computations

from a smartphone into the Cloud. Although as enabler of new use-cases it will play a major role, the

impact on current applications is believed to be even bigger. Cloud Computing presents a unique

opportunity for batch-processing and business analytics. The rise of business analytics has manifested

itself in a growing share of computing resources being spent on understanding customers, supply chains,

buying habits and so on. Analyzing terabytes of data and can take hours on a single computer. If

computations can be parallelized using hundreds of computers for a short time costs the same as using a

few computers for a long time. Another group of ideal candidates for the Cloud are compute-intensive

desktop applications. Especially for new product development, moving simulations into the Cloud can

mean enormous cost savings compared with the traditional approach of buying computation time from a

data processing center. The latest versions of the mathematics software packages such as Matlab or

Mathematica are already capable of using Cloud Computing to perform expensive evaluations (10).

Into the Cloud

Page 24

Challenges of Cloud Computing

Of course, where there is light, there is also a shadow. Like every uprising technology Cloud Computing

has still got obstacles on its path that have to be overcome. This is especially true for enterprise

applications. Subsequently we point out some major obstacles of current Cloud Computing from a

business perspective and present corresponding solution opportunities (see Table 3).

Challenge Opportunity

Availability of Service Especially for enterprises, availability of certain

applications is business critical. Therefore they still shrink

from trusting Cloud providers with hosting critical software.

A possible solution would be to use multiple Cloud providers

to provide business continuity and utilize Cloud-elasticity to

defend against DDOS attacks.

Data Lock-In Many businesses fear that choosing a certain Cloud

provider also means losing a certain degree of freedom as

their data gets locked in. If APIs of different providers

where built on an industry standard, entry threshold would

definitely be lower.

Data Confidentiality and Auditability Another important issue is confidentiality in the Cloud. Even

if the provider is trustworthy it is still unclear on which server

data is located and which legislation is applied. A possible

work-around would be to deploy encryption, VLANs and

firewalls. A really clean solution would store data

geographically according to legal requirements.

Data Transfer Bottlenecks Only because high-speed broadband Internet is available

in some regions, this does not necessarily mean that each

branch can fall back on the same infrastructure quality.

FedExing disks is still a common activity throughout the

world. And also in the era of Cloud Computing enterprises

have to balance which data to move entirely into the Cloud

and where other solutions might be better suited.

Performance Unpredictability Especially for HPC applications it is essential that

computation performance is stable and predictable. To

solve this issue it is necessary to improve virtual machines,

for example by implementing gang scheduling. In some

matters of data storage flash memory instead of hard-

drives might greatly improve speed.

Scalable Storage Although current relational database systems support multi-

user access, Cloud Computing dimensions are in another

league. Although CC providers (e. g. Google) have

implemented special datastores, management of persistent

data is still a major bottleneck. Fundamental research on

data base technology is therefore indispensable.

Into the Cloud

Page 25

Challenge Opportunity

Bugs in Large-Scale Distributed Systems Current debugging technology is designed for traditional

software. The laws that apply in distributed virtual Cloud

systems are different from those in conventional systems. An

opportunity to approach this issue is to invent special

Debuggers for distributed VMs.

Dynamic Scaling State-of-the-art scaling is mainly manually or at most semi-

automatic. Although additional hardware is switched on in

case of need, this not until server load hits a certain level.

Using machine learning algorithms to predict workload and

dynamically allocate needed resources would improve

Cloud efficiency substantially.

Reputation Fate For CC providers reputation might become a problem,

because one customers bad behavior can affect the

reputation of the cloud as a whole. As soon as the Clouds IP

addresses become blacklisted e. g. because of spam all

applications on the Cloud that send emails out of it become

negatively affected. This issue could be resolved by

offering reputation-guarding services similar to trusted

email services. Also legal issues have to be addressed

since Cloud Computing providers surely not want to be held

liable for actions of their customers.

Software Licensing Another major issue are current licensing models, as they

restrict the computers on which the software can run. In this

context software vendors have to adapt their business

models and offer pay-for-use licenses. Many vendors have

already reacted and now offer SaaS themselves.

TABLE 3: OBSTACLES AND OPPORTUNITIES OF CLOUD COMPUTING (ADAPTED FROM (10))

Into the Cloud

Page 26

CONCLUSION

Cloud Computing remains the number one hype topic within the IT industry at present. Our evaluation of

the Google App Engine has shown both functionality and limitations of the platform. Developing and

deploying an application within the GAE is in fact quite easy and in a way shows the progress that

software development and deployment has made. Within our application we were able to use the

abstractions provided by the GAE without problems, although the concept of Bigtable requires a big

change in mindset when developing. Our scalability testing showed the limitations of the GAE at this point

in time. Although being an extremely helpful feature and a great USP for the GAE, the built-in scalability

of the GAE suffers from both purposely-set as well as technical restrictions at the moment. Coming back

to our motivation of evaluating the GAE in terms of its sufficiency for serious large-scale applications in a

professional environment, we have to conclude that the GAE not (yet) fulfills business needs for enterprise

applications at present. As the discussion showed, some of these needs are yet to be satisfied by Cloud

Computing platforms in general, others are GAE-specific issues. However, seeing the benefits and

potential of PaaS-based approaches such as the GAE, the question remains whether quite inflexible and

non-standardized PaaS platforms can establish themselves in the market for serious large-scale

applications or will remain platforms for small and simple applications as seen today.

Into the Cloud

Page 27

ABBREVIATIONS

AJAX Asynchronous JavaScript and XML

API Application Programming Interface

Blob Binary Large Object

CC Cloud Computing

DDOS Distributed Denial of Service

GAE Google App Engine

GWT Google Web Toolkit

HPC High Performance Computing

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IaaS Infrastructure as a Service

JDO Java Data Object

JDOQL Java Data Object Query Language

JS JavaScript

JSON JavaScript Object Notation

JVM Java Virtual Machine

PaaS Platform as a Service

RPC Remote Procedure Call

SaaS Software as a Service

SLA Service Level Agreement

SQL Structured Query Language

SVN Subversion (a revision control system)

VLAN Virtual Local Area Network

VM Virtual Machine

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

Into the Cloud

Page 28

TABLE OF FIGURES

Figure 1: Global Search volume index for Cloud Computing (2) ......................................................................3

Figure 2: Service Delivery models of cloud computing (12) ...................................................................................5

Figure 3: Major types of cloud Services (Adapted form (5)) .................................................................................6

Figure 4: Structure of Google App Engine (13) ........................................................................................................8

Figure 5: Bigtable Structure (14) .................................................................................................................................9

Figure 6: Application Architecture (Own Illustration adapted from (21) (22) (23) (8)) ................................. 13

Figure 7: Diagram of Layers and components (Own illustration) ....................................................................... 14

Figure 8: Class diagramm of Business layer (Own illustration) ........................................................................... 15

Figure 9: Class diagramm of Presentation layer (Own illustration) ................................................................... 16

Figure 10: Class diagram of Data Layer (Own illustration) ................................................................................ 17

Figure 11. Crawler (Own illustration) ....................................................................................................................... 19

Figure 12. Total Duration (Own illustration) ............................................................................................................ 19

Figure 13 Error message in Administration console (8) ......................................................................................... 20

Figure 14 Time per request and service (Own illustration) .................................................................................. 20

Into the Cloud

Page 29

LITERATURE

1. Let it Rise. The Economist. October, 23., 2008.

2. Google Inc. Google Trends. [Online] 07 17, 2010. [Cited: 07 17, 2010.]

http://www.google.com/trends?q=Cloud+Computing&ctab=0&geo=all&geor=all&date=all&sort=0.

3. Voas, J. and Zhang, J. Cloud Computing:New Wine or Just a New Bottle? IT Professional. 2009.

4. Vaquero, L, et al. A Break in the Clouds: Towards a Cloud Definition. ACM SIGCOMM Computer

Communication Review. 01 2009.

5. Leavitt, N. Is Cloud Computing Really Ready for Prime Time? IEEE Technology News. 2009.

6. NIST. The NIST Cloud Computing Project. [Online] 2009. [Cited: 07 17, 2010.]

http://csrc.nist.gov/cyber-md-summit/documents/posters/cloud-computing.pdf.

7. Amazon.com, Inc. amazon web services. [Online] 2010. [Cited: 07 17, 2010.]

http://aws.amazon.com/.

8. Google Inc. Google App Engine. [Online] 2010. [Cited: 07 17, 2010.]

http://code.google.com/intl/de-DE/appengine/.

9. Microsoft, Inc. Windows Azure Platform. [Online] 2010. [Cited: 07 17, 2010.]

http://www.microsoft.com/windowsazure/.

10. Armbrust, M, et al. Above the Clouds: A Berkeley View of Cloud Computing. s.l. : UC Berkeley

Reliable Adaptive Distributed Systems Laboratory, 2009.

11. Sriram, I and Khajeh-Hosseini, A. Research Agenda in Cloud Technologies. [Online] 10 2009.

[Cited: 07 18, 2010.] http://arxiv.org/ftp/arxiv/papers/1001/1001.3259.pdf.

12. Marinos, A and Briscoe, G. Community Cloud Computing. 2009.

13. Sanderson, D. Programming Google App Engine. Sebastopol : OReilly Media, 2009.

14. Chang, F, et al. Bigtable: A Distributed Storage System for Structured Data. ACM Transactions on

Computer Systems. s.l. : ACM, 2008. Vol. 26, 2.

15. Severance, C. Using Google App Engine. Sebastopol : OReilly Media, 2009.

16. Ciurana, E. Developing with Google App Engine. s.l. : firstPress, 2008.

17. Java Community Process. JCACHE - Java Temporary Caching API. [Online] 2001. [Cited: 07 18,

2010.] http://jcp.org/en/jsr/detail?id=107. JSR 107.

18. Roche, K. and Douglas, J. Beginning Java Google App Engine. s.l. : Apress, 2009.

19. XMPP Standards Foundation. The Extensible Messaging and Presence Protocol. [Online] 2010.

[Cited: 07 17, 2010.] http://xmpp.org/.

20. Internet Engineering Task Force. Request for Comments: 5849 . The OAuth 1.0 Protocol. [Online] 04

2010. [Cited: 07 19, 2010.] http://tools.ietf.org/html/rfc5849.

21. Yahoo! Inc. Yahoo! [Online] 2010. [Cited: 07 18, 2010.] http://www.yahoo.com/.

Into the Cloud

Page 30

22. Facebook, Inc. facebook. [Online] 2010. [Cited: 07 18, 2010.] http://www.facebook.com/.

23. Yahoo! Inc. delicious.com. [Online] 2010. [Cited: 07 18, 2010.] http://www.delicious.com.

24. Bruegge, B. and Dutoit, A. Object-oriented software engineering: using UML, patterns, and Java. s.l. :

Prentice Hall, 2009.

25. Tyagi, S., Vorburger, M. and McCammon, K. Core Java Data Objects. s.l. : Prentice Hall PTR, 2003.

26. Scientific Cloud Computing: Early Definition and Experience. Wang, L. and von Laszewski, G. 2008.

27. Won, K. Cloud Computing: Today and Tomorrow. Journal of Object Technology. 2009, Vol. 08, 01.

28. Qian, L., et al. Cloud Computing: An Overview. CloudCom 2009. Heidelberg : Springer, 2009.

29. Pearson, S. Taking Account of Privacy when Designing Cloud Computing Services. Proceedings of the

2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing. s.l. : IEEE Computer

Society, 2009.

30. Deelman, E, et al. The Cost of Doing Science on the Cloud: The Montage Example. Proceedings of the

2008 ACM/IEEE conference on Supercomputing. 2008.

31. Chun, B. and Maniatis, P. Augmented Smart Phone Applications Through Clone Cloud Execution.

Proceedings of the 12th Workshop on Hot Topics in Operating Systems. 2009.

32. Buyya, R, Pandey, S and Vecchiola, C. Cloudbus Toolkit for Market-Oriented Cloud Computing.

Proceedings of the 1st International Conference on Cloud Computing. Beijing : Springer, 2009.

33. Erdogmus, H. Cloud Computing: Does Nirvana Hide behind the Nebula? IEEE Software. 2009,

March/April.