I Eee Cloud Computing

cloud computing
IEEE
eScience
2
TYPE A dig ital m agaz in su ine the I pport of EEE Com putin Cloud g Init iative
PROT O
Identifying Risk
14
Google App Engine

8
The Essentials Issue

May/June 2012
cloud computing
IEEE
May/June 2012
e Essentials Issue
Innovations in virtualization and distributed computing, as well as a poor economy and increased access to high-speed Internet, have accelerated business interest in cloud computing. We explore the risks, security and privacy concerns, and the latest in working with the Google App Engine.
1 2
Guest Editors Introduction

Jon Rokne
Science in the Cloud: Accelerating Discovery in the 21st Century Cloud Computing: A Records and Information Management Perspective
Kirsten Ferguson-Boucher
Joseph L. Hellerstein, Kai J. Kohlho , and David E. Konerding
Evaluating High-Performance Computing on Google App Engine
Radu Prodan, Michael Sperk, and Simon Ostermann
14 Understanding Cloud Computing Vulnerabilities

Bernd Grobauer, Tobias Walloschek, and Elmar Stcker
Cloud Computing Initiative Steering Committee Steve Diamond, chair Nim Cheung Kathy Grise Michael Lightner Mary Lynne Neilsen Sorel Reisman Jon Rokne
IEEE Computer Society Sta Angela Burgess

Executive Director
Steve Woods
Manager, New Media & Production
Evan Buttereld
Director, Products & Services
Kathy Clark-Fisher
Manager, Products & Acquisitions
Lars Jentsch
Manager, Editorial Services
Monette Velasco and Jennie Zhu

Design & Production
Guest Editors Introduction
An Essential Initiative
Jon Rokne, University of Calgary
C
2012 IEEE
loud computing is transforming information technology. As information and processes migrate to the cloud, it is transforming not only where computing is done, but, fundamentally, how it is done. As increasingly more corporate and academic worlds invest in this technology, it will also drastically change IT professionals working environment . Cloud computing solves many problems of conventional computing, including handling peak loads, installing so ware
updates, and using excess computing cycles. However, the new technology has also created new challenges such as data security, data ownership, and transborder data storage. e IEEE has realized that cloud computing is poised to be the dominant form for computing in the future and that it will be necessary to develop standards, conferences, publications, educational material, and general awareness information for cloud computing. Because of this, the New Initiative Commi ee of the IEEE has
Published by the IEEE Computer Society
funded an IEEE Cloud Computing Initiative (CCI). CCI coordinates cloud-related activities for IEEE and has tracks for all of the identi ed aspects of cloud computing. e CCI Publications Track is tasked with developing a slate of cloud computing-related publications. e CCI provides seed funding for the publications developed by the CCI Publications Track and it has already developed a mature proposal for an IEEE Transactions on Cloud Computing, sponsored by ve IEEE societies. is transactions is slated to commence publishing in-depth research papers in cloud computing in 2013 following approval by the Board of IEEE at the June 2012 meeting. e second publishing initiative is to develop a cloud computing magazine. In preparation, the IEEE Computer Society publications team has created this supplement on behalf of the Cloud Computing Publishing Track. is supplement contains previously published articles that have recently appeared in several magazines. e aim of IEEE Cloud Computing magazine is to provide a focused home for cloud-related articles e magazine will be technically cosponsored by several IEEE societies. e CCI Publications Track would like to have a broad representation from IEEE societies with interests in cloud computing. If anyone wishes to participate in the ongoing discussion of the publications initiatives, please contact Jon Rokne at rokne@ucalgary.ca.
Jon Rokne is the CCI Publications Track
chair. He is a professor and former head of the Computer Science department at the University of Calgary and the past vice president of publications for IEEE.
IEEE Cloud Computing

3 billion pairs of nucleotides, the elements that encode information in DNA. These base pairs encode common human characteristics, benign individual variations, and potential disease-causing variants. It turns out that individual variation is usually much more common than are disease-causing variants. So, understanding how the genome contributes to disease is much more complicated than looking at the difference between genomes. Instead, this analysis often requires detailed models of DNA-mediated chemical pathways to identify disease processes. The human genomes size and the complexity of modeling disease processes typically require large-scale computations and massive storage capacity.2 A common pattern in eScience is to explore many possibilities in parallel. Computational biologists can align millions of DNA reads (produced by a DNA sequencer) to a reference genome by aligning each one in parallel. Neuroscientists can evaluate a large number of parameters in parallel to find good models of brain activity. And astronomers can analyze different regions of the sky in parallel to search for supernovae. That a high degree of parallelism can advance science has been a starting point for many efforts. For example, Folding@Home3 is a distributed computing project that enables scientists to understand the biochemical basis of several diseases. At Google, the Exacycle project provides massive parallelism for doing science in the cloud.
Science in the Cloud

Accelerating Discovery in the 21st Century
Joseph L. Hellerstein, Kai J. Kohlhoff, and David E. Konerding, Google Scientific discovery is transitioning from a focus on data collection to an emphasis on analysis and prediction using largescale computation. With appropriate software support, scientists can do these computations with unused cycles in commercial clouds. Moving science into the cloud will promote data sharing and collaborations that will accelerate scientific discovery.
Harvesting Cycles for Science
R
2
ecent trends in science have made computational capabilities an essential part of scientific discovery. This combination of science and computing is often referred to as enhanced scientific discovery, or eScience. The collection of essays in The Fourth Paradigm describes how science has evolved from being experimentally driven to being collaborative and analysis-focused.1 eScience has been integral to high-energy physics for several decades due to the volume and complexity of data such experiments produce. In the 1990s, the computational
demands of sequencing the human genome made eScience central to biology. More recently, eScience has become essential for neuroscientists in modeling brain circuits and for astronomers in simulating cosmological phenomena. Biology provides an excellent example of how eScience contributes to scientific discovery. Much modern biological research is about relating DNA sequences (genotypes) to observable characteristics (phenotypes) as when researchers look for variations in DNA that promote cancer. The human genome has approximately
Often, scientific discovery is enhanced by employing large-scale computation to assess if a theory is consistent with experimental results. Frequently, these computations (or jobs) are structured as a large number of independently executing tasks. This job structure is called embarrassingly parallel. The Exacycle project aims to find unused resources in the Google cloud to run embarrassingly parallel jobs at a very large scale. We do this by creating a system thats both a simplification and a generalization of MapReduce. Exacycle simplifies MapReduce in that all Exacycle tasks are essentially mappers. This simplification enables more efficient resource management. Exacycle
2012 IEEE
generalizes MapReduce by providing automation that monitors resources across the Google cloud and assigning tasks to compute clusters based on resource availability and job requirements. This provides massive scaling for embarrassingly parallel jobs. Google is very efficient at using computing resources, but resource utilizations still vary depending on time of day, day of the week, and season. For example, Web users most frequently use search engines during the day, and search providers typically direct traffic to data centers close to users to reduce latency. This leads to low data center utilizations during the data centers local night time. Still, low resource utilization doesnt necessarily enable more tasks to run in the cloud. Many tasks require considerable memory, or moderate amounts of memory and CPU in combination. Such tasks can run in the cloud only if at least one machine satisfies all the tasks resource requirements. One way to quantify whether tasks can run is to determine if suitably sized slots are available. For example, recent measurements of the Google cloud indicate that it has 13 times more slots for tasks requiring only one core and 4 Gbytes of RAM than there are slots for tasks requiring four cores and 32 Gbytes of RAM. In general, finding slots for tasks that require fewer resources is much easier. For this reason, an Exacycle task typically consumes about one core and 1 Gbyte of memory for no more than an hour. For cloud computing to be efficient, it must adapt quickly to changes in resource demands. In particular, higher-priority work can preempt Exacycle tasks, which must then be re-run. However, Exacycle throughput is excellent because in practice preemption is rare. This is due in part to the manner in which Excycle locates resources that run tasks. As Figure 1 shows, Exacycle is structured into multiple layers. At the top is the Daimyo global scheduler, which assigns tasks to clusters. The second layer is the Honcho cluster scheduler, which assigns tasks to machines. The Peasant machine manager in the third layer encapsulates tasks, and the bottom layer caches task results. The Honchos and Peasants cache information but are otherwise stateless. This simplifies failure handling.
www.computer.org/cloud
Compute cluster Honcho (per cluster) Assign task Honcho joins Honcho discovery services Daimyo watches Cached results Work unit storage Other compute clusters Assign task Peasant (per core)
Honcho watches
Daimyo (global manager) Submit Monitor User
Peasant discovery service Peasant joins
Result storage
Figure 1. Exacycle system architecture. Daimyo assigns tasks to clusters, Honcho assigns tasks to machines, Peasant encapsulates tasks, and the bottom layer caches task results.
Exacycle implements the same communication interfaces between adjacent layers. Communication from an upper to a lower layer requires the upper layer to cut data into pieces that it then passes on to the lower layer. Typically, this communication provides data to tasks within the same job. Communication from a lower layer to an upper layer involves bundling data to produce aggregations. These interlayer interfaces are scalable and robust with minimal requirements for managing distributed state. The primary mechanism Exacycle uses to scale is eliminating nearly all intercluster networking and machine-level disk I/O. An Exacycle task typically cant move more than 5 Gbytes of data into or out of the machine on which the tasks executes. Exacycle reduces network usage by managing data movement on tasks behalf. Typically, the thousands to millions of tasks in an Exacycle job share some of their input files. Exacycle uses this knowledge of shared input files to coschedule tasks in the same cluster. This strategy improves throughput by exploiting the high network bandwidths between machines within the same cluster. Furthermore, Exacycle uses caching so that remote data are copied into a cluster only once.
When Exacycle assigns a task to a machine, a timeout and retry hierarchy handles failures. This combination of timeouts and retries addresses most systemic errors. Because tasks have unique identifiers, the Exacycle retry logic assumes that two tasks with the same identifier compute the same results. For the most part, Exacycle doesnt employ durable cluster- or machine-level storage owing to its engineering costs and performance penalties. Instead, Exacycle optimistically keeps nearly all state in RAM. Robustness comes from having a single authoritative store and spreading state across many machines. If a machine fails, Exacycle moves tasks from the failed machine to another machine. If there is a failure of a machine running a Honcho clusterlevel scheduler, the Honcho is restarted on another machine, and uses discovery services to recover cached state. The Exacycle project began two years ago. The system has been running eScience applications in production for roughly a year, and has had continuous, intensive use over the past six months. Recently, Google donated 1 billion core hours to scientific discovery through the Exacycle Visiting Faculty Grant Program (http:// research.google.com/university/exacycle
3
GPCR Extracellular side
Ligand
cell nucleus through a channel known as the nuclear pore complex. Google has selected these projects based on their potential to produce scientific results of major importance. One measure of impact will be publishing in top journals such as Science and Nature. To better illustrate the potential for science in the cloud, we next look at one problem in detail.
Cell membrane
Ligand binding site
Simulating Molecular Dynamics

Exacycle has undertaken a project that relates to a class of molecules called G protein-coupled receptors. GPCRs are critical to many drug therapies. Indeed, about a third of pharmaceuticals target GCPRs. Despite this, scientists still dont fully understand the molecular basis of GPCR action. A bit of science is needed to appreciate the computational problem that Exacycle is addressing. GPCRs are critical to transmembrane signaling, an important part of many disease pathways. Scientists know that GPCRs embed in cell membranes to provide communication between extracellular signals and intracellular processes. This communication occurs when certain molecules bind to sites on GPCRs that are accessible from outside the membrane. However, scientists dont fully understand the sequence of changes that then lead to communication across the cell membrane. To gain a better understanding of GPCR activity, Exacycle is doing large-scale simulations of GPCR molecular dynamics. This is a challenging undertaking because of the detail required to obtain scientific insight. In particular, biomolecules at body temperature undergo continuous fluctuations with regard to atoms location and the 3D shape of molecules (referred to as their conformation). Many changes occur at a time scale of femtoseconds to nanoseconds (1015 to 109 seconds). However, most chemical processes of interest occur at a time scale of microseconds to milliseconds. The term trajectory refers to a sequence of motions of a set of atoms under study over time. Figure 2 depicts the insights possible with trajectories of different durations. Understanding GPCR actions requires simulations that generate data over milliseconds.
May/June 2012
Intracellular side G protein binding site
Salt bridge formation nanoseconds 101 102 103
Ligand binding microseconds 104 105 106
Major conformational change milliseconds 107 108 109 Time Total core hours
Figure 2. Trajectory durations for G protein-coupled receptors (GPCRs). These receptors are critical to many drugs effectiveness because of their role in communicating signals across cell membranes. The upper x-axis shows the trajectory duration, whereas the lower x-axis shows the core hours required to compute trajectory durations. Computing one millisecond of trajectory data requires millions of core days on a modern desktop computer. Exacycle can do these computations in a few days.
_program.html). To support this, Exacycle consumes approximately 2.7 million CPU hours per day, and often much more. As of early February, visiting faculty had completed 58 million tasks. Visiting faculty are addressing various scientific problems that can benefit from large-scale computation:
The enzyme science project seeks to discover
how bacteria develop resistance to antibiotics, a growing problem for public health. The molecular docking project seeks to advance drug discovery by using massive computation to identify small molecules that bind to one or more of the
4
huge set of proteins that catalyze reactions in cells. The potential here is to greatly accelerate the design of drugs that interfere with disease pathways. The computational astronomy project plays an integral role in the design of the 3200 Megapixel Large Synoptic Survey Telescope. As one example, the project is doing large scale simulations to determine how to correct for atmospheric distortions of light. The molecular modeling project is expanding the understanding of computational methods for simulating macromolecular processes. The first application is to determine how molecules enter and leave the
Exacycle simulates the trajectories of approximately 58,000 atomsthe number of atoms in a typical GPCR system, including the cell membrane and water molecules. It does so at femtosecond precision over trillions of time steps by computing trajectories using embarrassingly parallel jobs. The GPCR data analysis pipeline uses trajectories in two ways. The first is to construct models of GPCR behavior. For example, researchers can use trajectories to create a Markov model with states in which protein structures are described according to their 3D structure and kinetic energy. Second, researchers analyze trajectories for changes that are important for activating signaling across the cell membrane. It takes approximately one core day to simulate half a nanosecond of a single trajectory on a modern desktop. So, obtaining scientific insight requires millions of core days to generate a millisecond of trajectory data. Clearly, massive computational resources are required. Exacycle provides these resources to compute trajectories in parallel. However, some thought is required to use Exacycle effectively. For GPCR trajectories, the challenge is that it takes millions of core hours to compute an interesting trajectory, but an Exacycle task typically executes for no more than one core hour. So, Exacycle constructs trajectories by executing a series of tasks. This requires passing partially computed trajectories from one task to the next in a way that maintains high throughputs. The approach for computing trajectories has several parts. A driver script generates tens of thousands of tasks and submits them to Exacycle. The script also monitors task states and registers events such as task completions or failures. To maintain high throughput, this script then propagates partial trajectories that tasks compute to other tasks. Exacycle provides mechanisms for monitoring task executions and supporting the investigation and resolution of task and system failures. Thus far, Exacycle has computed more than 150,000 trajectories with durations totaling more than 4 milliseconds. At peak, Exacycle simulates approximately 80 microseconds of trajectory data per day. This corresponds to roughly 600 teraflops.
Exacycle has produced hundreds of terabytes of trajectory data. Analyzing these data presents a huge challenge. One approach is to use MapReduce to calculate summary statistics of trajectories and then place the results into a relational database of trajectory tables. Scientists have obtained considerable insight by doing SQL queries against the trajectory tables. However, this requires the database to have the scalability of technologies such as Dremel,4 which provides interactive response times for ad hoc queries on tables with billions of rows.
planetary-scale collaborations that power scientific discovery in the 21st century.
References
1. The Fourth Paradigm: Data-Intensive Scientific Discovery, T. Hey, S. Tansley, and K. Tolle, eds., Microsoft Research, 2009. 2. M. Schatz, B. Langmead, and S. Salzberg, Cloud Computing and the DNA Data Race, Nature Biotechnology, vol. 28, no. 7, 2010, pp. 691693. 3. M. Shirts and V. Pande, Screen Savers of the World Unite! Science, vol. 290, no. 5498, 2000, p. 1903. 4. S. Melni k et al ., Dremel : Interactive Analysis of Web-Scale Datasets, Proc. Conf. Very Large Databases, VLDB Endowment, vol. 3, 2010, pp. 330339.
mazon, Microsoft, Google, and others offer capabilities for running science applications in the cloud. The appeal of these services is that scientists dont need to buy expensive, dedicated clusters. Instead, they pay a modest rent for ondemand access to large quantities of cloud computing resources. Although doing science in the cloud has appeal, it could have hidden costs. For example, scientists might have to recode applications to exploit cloud functionality or add new code if some features arent present in the cloud. Science in the cloud offers much more than a compute infrastructure. A recent trend is that scientific contributions require that researchers make large datasets publicly available. Some examples are the Allen Institutes Brain Atlas and the US National Center for Biotechnology Information (NCBI) genome database. Both are repositories that researchers widely use to do computation-intensive analysis of data that others have collected. Hosting these datasets in public clouds is much easier than requiring individual scientists (or even universities) to build their own data-hosting systems. Much more is on the way in this arena. Using the cloud for computation and data storage will facilitate scientists sharing both data and computational tools. Indeed, substantial efforts are already under way, such as Sage Bionetworks idea of a data commons (http://sagebase.org/research/ Synapse1.php). Sharing data and code will let scientists more rapidly build on their peers results. Longer term, the big appeal of science in the cloud is promoting
Joseph L. Hellerstein is at Google, where he manages the Big Science Project, which addresses cloud computing for scientific discovery. He has a PhD in computer science from the University of California, Los Angeles. Hellerstein is a fellow of IEEE. Contact him at jlh@google.com. Kai J. Kohlhoff is a research scientist at Google, where he works on cloud computing and eScience. He has a PhD in structural bioinformatics from the University of Cambridge, UK. Contact him at kohlhoff@google.com. David E. Konerding is a software engineer at Google, where he works on cloud infrastructure and scientific computing. He has a PhD in biophysics from the University of California, Berkeley. Contact him at dek@ google.com.
This article will appear in IEEE Internet Computing, July/August 2012.

which users access the infrastructure, computing power, applications, and services on demand and independent of location. Cloud computing usually involves the transfer, storage, and processing of information on the providers infrastructure, which is outside the customers control. The National Institute of Standards and Security (NIST) defines it as a model for enabling ubiquitous, convenient, ondemand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction (http://csrc.nist. gov/publications/PubsSPs.html#800-145/ SP800-145.pdf). As Figure 1 shows, the NIST-defined model highlights five essential characteristics that reflect a services flexibility and the control that users have over it. NIST also distinguishes among three delivery models (software as a service [SaaS], platform as a service [PaaS], and infrastructure as a service [IaaS]) and four deployment models (public, private, hybrid, and community clouds).
Cloud Computing
A Records and Information Management Perspective
Kirsten Ferguson-Boucher, Aberystwyth University, Wales Ultimately, how to make decisions about which cloud service/ deployment model to select and what sort of things to take into consideration when making that initial decision, require the organization to consider whether loss of control will significantly affect the security of mission-critical information.
Delivery Models
As a general rule, the customer doesnt control the underlying cloud infrastructure in any delivery model. SaaS is software offered by a third-party provider, usually on demand via the Internet and configurable remotely. PaaS also allows customers to develop new applications using APIs deployed and configurable remotely. In this case, the customer does have control over the deployed applications and operating systems. In the IaaS provision, virtual machines and other abstracted hardware and operating systems are made available. The customer, therefore, has control over operating systems, storage, and deployed applications.
or many records and information management (RIM) professionals, cloud computing resembles a traditional hosting service: information storage or applications are outsourced to a thirdparty provider and accessed by the organization through a network connection. However, the information, applications, and processing power in a cloud infrastructure are distributed across many servers and stored along with other customers information, separated only by logical isolation mechanisms. This presents both new RIM challenges and benefits. RIM professionals are specifically concerned with information as a core business asset. Records are a subset of organizational information that is often required to provide evidence of organizational activities and transactions. They require protection in
6
the same way as every other asset. Decisionmaking processes take into consideration the wider context of organizational strategy and form part of a complex structure of assessments regarding information value, alignment, and assurance. All of these operate within an overarching performance and risk framework.
Cloud Computing: A Brief Introduction

Cloud computing is the ability to access a pool of computing resources owned and maintained by a third party via the Internet. It isnt a new technology but a new way of delivering computing resources based on long existing technologies such as server virtualization. The cloud is composed of hardware, storage, networks, interfaces, and services that provide the means through
Deployment Models
There are, essentially, three deployment models: private, community, and public, with a fourth combined option. Private clouds are operated solely for an organization; community clouds are shared by several organizations and are designed to support a specific community. In public clouds, the infrastructure is made publicly available but is owned by an organization selling cloud
2012 IEEE
services. Resources are offsite and shared among all customers in a multitenancy model. Hybrid clouds are a composition of two or more clouds that remain unique entities but are bound together by standardized or proprietary technology to enable data and application portability.
loss of governance, integration, and

management. The sidebar Ten Questions to Ask When Outsourcing to the Cloud offers some guidance about what service might be best for a particular organizations context.
Is the Cloud Right for You?

Making the decision to move to the cloud is a complex one and depends very much on your organizational context. Lets examine some generic benefits and challenges. An obvious benefit is a reduction in capital expenditureheavy investment in new hardware and software is no longer required for often underutilized functions, such as storage and processing. Organizations can tap into readily available computing resources on demand, with large datacenters often using virtualization technologies (the abstraction of computing resources from the underlying hardware) to enable scalable and flexible service provision. Applications, storage, servers, and networks are allocated flexibly in a multitenancy environment to achieve maximum computing and storage capacities. From a provider perspective, utilization of shared resources results in higher efficiency and the ability to offer cloud computing services at low costs; customers likewise benefit from cheaper access. But make no mistake the cloud still involves costs to an organization as it tries to integrate new services with existing legacy processes. Table 1 summarizes these and some of the other general pros and cons of cloud provision. There are, however, very specific considerations that relate to the ability of the organization to manage its information and ensure that records are available for current and future organizational use. In particular, the cloud offers specific benefits for RIM: improved business processes, facilitation of locationindependent collaboration, and access to resources and information at any time. However, some aspects of cloud computing can have a negative impact on RIM as well:
Managing Information Assets in the Cloud

Organizations are still responsible for their information even if its stored elsewhere (in this case, in the cloud). ISO 15489 (the international standard for records management) defines records as being authentic, reliable, and usable and possessing integrity. How does the move to the cloud affect these characteristics? Information governance and assurance require policies and procedures for maintaining the above and will need amending to incorporate the changing environment. There must be a clear understanding of whos responsible for what and how policies and procedures will be implemented. Issues such as metadata application, encryption strategies, and shorter-term preservation requirements as well as permanent retention or destruction strategies must also be considered. Particular reference to data protection, privacy legislation, freedom of information, and environmental regulations requires organizations to know where their information is stored (in what jurisdictions) and how it can be accessed within given time frames. Will the move to the cloud restrict the organizations ability to comply? Litigation also requires consideration: being able to identify relevant information, retrieve it, and supply it to courts in a timely manner can be difficult if the organization hasnt thought about how this would be achieved prior to an incident. Contracts need to be negotiated with these considerations in mind, with clauses built in about data destruction or how information can be returned to the organization, as well as how the provider manages it.
happens automatically and how the encryption keys are created, held, and used across single and multiple sites to be able to confirm that information is authentic. Business continuity can be affected by system failure, so information about continuity, monitoring, priority, and recovery procedures would give organizations a better picture of the risk of system failure to their activities.
ltimately, making decisions about which cloud service/deployment model to select, and what sort of things to take into consideration when making that initial decision, requires the organization to consider whether loss of control will significantly affect the security of mission-critical information. In particular, identifying risk and assessing the organizations risk appetite is a critical factor in making decisions about moving to the cloud. The business must be clear about the type of information its willing to store, how sensitive that information is, and whether its loss or compromise would affect the compliance environment in which the organization operates.
Acknowledgments
More information about the research undertaken by Aberystwyth University in conjunction with the Archives and Records Association of UK and Ireland, which underpins this article, can be found at www. archives.org.uk/ara-in-action/best-practice -guidelines.html. Kirsten Ferguson-Boucher lectures in records management; information governance; law, compliance, and ethics; and information assurance at Aberystwyth University, Wales. Her research interests include the convergence between related disciplines and how organizations in all sectors can reach acceptable levels of information governance and assurance across the spectrum of technologies. Contact her at knb@aber.ac.uk. This article originally appeared in IEEE Security & Privacy, November/ December 2011; http://doi. ieeecomputersociety.org/10.1109/ MSP.2011.159.
Operating in the Cloud

Use of information in the cloud typically precludes the use of encryption because it would adversely affect data processing, indexing, and searching. If the service uses encryption, the customer would need to know if this
compliance and e-discovery; integrity and confidentiality; service availability and reliability; service portability and interoperability; information retrieval and destruction; and

Google App Engine
GAE hosts Web applications on Googles large-scale server infrastructure. It has three main components: scalable services, a runtime environment, and a data store. GAEs front-end service handles HTTP requests and maps them to the appropriate application servers. Application servers start, initialize, and reuse application instances for incoming requests. During traffic peaks, GAE automatically allocates additional resources to start new instances. The number of new instances for an application and the distribution of requests depend on traffic and resource use patterns. So, GAE performs load balancing and cache management automatically. Each application instance executes in a sandbox (a runtime environment abstracted from the underlying operating system). This prevents applications from performing malicious operations and enables GAE to optimize CPU and memory utilization for multiple applications on the same physical machine. Sandboxing also imposes various programmer restrictions:
Evaluating High-Performance Computing on Google App Engine

Radu Prodan, Michael Sperk, and Simon Ostermann, University of Innsbruck Google App Engine offers relatively low resource-provisioning overhead and an inexpensive pricing model for jobs shorter than one hour.
Applications have no access to the under-
lying hardware and only limited access to network facilities. Java applications can use only a subset of the standard library functionality. Applications cant use threads. A request has a maximum of 30 seconds to respond to the client. on infrastructure as a service (IaaS)infrastructures on which you can easily deploy legacy applications and benchmarks encapsulated in virtual machines. We present an approach to evaluate a cloud platform for HPC thats based on platform as a service (PaaS): Google App Engine (GAE).1 GAE is a simple parallel computing framework that supports development of computationally intensive HPC algorithms and applications. The underlying Google infrastructure transparently schedules and executes the applications and produces detailed profiling information for performance and cost analysis. GAE supports development of scalable Web applications for smaller companies those that cant afford to overprovision a large infrastructure that can handle large traffic peaks at all times. GAE applications use resources such as CPU time, I/O bandwidth, and the number of requests within certain quotas associated with each resource type. The CPU time is, in fuzzy terms, equivalent to the number of CPU cycles that a 1.2-GHz Intel x86 processor can perform in the same amount of time. Information on the resource usage can be obtained through the GAE application administration Web interface. Finally, the data store lets developers enable data to persist beyond requests. The data store cant be shared across different slave applications.
unding agencies and institutions must purchase and provision expensive parallel computing hardware to support high-performance computing (HPC) simulations. In many cases, the physical hosting costs, as well as the operation, maintenance, and depreciation costs, exceed the acquisition price, making the overall investment nontransparent and unprofitable. Through a new business model of renting resources only in exact amounts for precise durations, cloud computing promises to be a cheaper alternative to parallel computers and more reliable than grids. Nevertheless, it remains dominated by commercial and industrial applications; its suitability for parallel computing remains largely unexplored. Until now, research on scientific cloud computing concentrated almost exclusively
A Parallel Computing Framework

To support the development of parallel applications with GAE, we designed a
2012 IEEE
Java-based generic framework (see Figure 1). Implementing a new application in our framework requires specialization for three abstract interfaces (classes): JobFactory, WorkJob, and Result (see Figure 2). The master application is a Java program that implements JobFactory on the users local machine. JobFactory manages the algorithms logic and parallelization in several WorkJobs. WorkJob is an abstract class implemented as part of each slave applicationin particular, the run() method, which executes the actual computational job. Each slave application deploys as a separate GAE application and, therefore, has a distinct URI. The slave applications provide a simple HTTP interface and accept either data requests or computational job requests.
WorkJob Master application Request JM Result Work pool Request JM Result I JobFactory Result Slave application I I I I Slave application I DS
DSS Data store
Requests
The HTTP message header stores the type of request. A job request contains one WorkJob thats submitted to a slave application and extended. If multiple requests are submitted to the same slave application, GAE automatically starts and manages multiple instances to handle the current load; the programmer doesnt have control over the instances. (One slave application is, in theory, sufficient; however, our framework can distribute jobs among multiple slave applications to solve larger problems.) A data request transfers data shared by all jobs to the persistent data store (indicated by the useSharedData method). It uses multiple parallel HTTP requests to fulfill the GAEs maximum HTTP payload size of 1 Mbyte and improve bandwidth utilization. The fetchSharedData method retrieves shared data from the data store as needed. In a clear request, the slave application deletes the entire data store contents. Clear requests typically occur after a run, whether its successful or failed. A ping request returns instantly and determines whether a slave application is still online. If the slave is offline, the master reclaims the job and submits it to another instance.
Figure 1. Our parallel computing framework architecture. The boxes labeled I denote multiple slave instances. The master application is responsible for generating and distributing the work among parallel slaves implemented as GAE Web applications and responsible for the actual computation.
WorkJob Execution
Mapping WorkJobs to resources follows a dynamic work pool approach thats suitable for slaves running as black boxes on
sandboxed resources with unpredictable execution times. Each slave application has an associated job manager in the context of the master application. It requests WorkJobs from the global pool, submits them to its slave instances for computation (GAE automatically decides which instance is used), and sends back partial results. We associate a queue size with every slave to indicate the number of parallel jobs it can simultaneously handle. The size should correspond to the number of processing cores available underneath. Finding the optimal size at a certain time is difficult for two reasons. First, GAE doesnt publish its hardware information; second, an application might share the hardware with other competing applications. So, we approximate the queue size at a certain time by
public interface JobFactory { public WorkJob getWorkJob(); public int remainingJobs(); public void submitResult(Result); public Result getEndResult(); public boolean useSharedData(); public Serializable getSharedData(); } public abstract class WorkJob extends Serializable { private int id; public int getId(); public void setId(int); public Result run(); public void fetchSharedData(); } public abstract class Result implements Serializable { private int id; private long cpuTime; public long getCPUTime(); public void setCPUTime(long); public int getId(); public void setId(int); } Figure 2. The Java code for our parallel computing framework interface. JobFactory instantiates the master application, WorkJob instantiates the slave, and Result represents the final outcome of a slave computation. 9
5,000 4,000 Latency (ms) 3,000 2,000 1,000 0 0 030 600 900 1,200 1,500 1,800 Payload size (Kbytes) 2,100 2,400 2,700
Figure 3. Resource-provisioning overhead didnt increase linearly with the payload because TCP achieved higher bandwidth for larger payloads.
balancing to assign a request to an application server, which includes the initialization of an instance if none exists). To measure the overhead, we sent HTTP ping requests with payloads between 0 and 2.7 Mbytes in 300-Kbyte steps, repeated 50 times for each size, and took the average. The overhead didnt increase linearly with the payload (see Figure 3) because TCP achieved higher bandwidth for larger payloads. We measured overhead in seconds; IaaS-based infrastructures, such as Amazon Elastic Compute Cloud (EC2), exhibit latencies measured in minutes.2
Just-in-Time Compilation
5,000 Computation time (ms) 4,000 3,000 2,000 1,000 0 0 5 10 15 20 25 30 Request number 35 40 45 50
Figure 4. Computation time and the mapping of requests to instances. The first two requests in each instance took considerably longer than the rest. After just-in-time compilation, the code executed almost four times faster.
conducting a warm-up training phase before each experiment. The slave application serializes the WorkJobs results and wraps them in an HTTP response, which the master collects and assembles. A Result has the samsideae unique identifier as the WorkJob. The calculationTime field stores the effective computation time spent in run() for performance evaluation.
Benchmarks
We began our evaluation of GAE with a set of benchmarks to provide important information for scheduling parallel applications onto its resources. To help users understand the price of moving from a local parallel computer to a remote cloud with sandboxed resources, we deployed a GAE development server on Karwendel, a local machine with 16 Gbytes of memory and four 2.2-GHz dual-core Opteron processorsta Instead of spawning additional sandboxed instances, the development server managed parallel requests in separate threads.
A Java virtual machines just-in-time (JIT) compilation converts frequently used parts of byte code to native machine code, notably improving performance. To observe JIT compilation effects, we implemented a simple Fibonacci number generator. We submitted it to GAE 50 times in sequence with a delay of one second, always using the same problem size. We set up the slave application with no instances running and measured the effective computation time in the run() of each WorkJob. As we described earlier, GAE spawns instances of an application depending on its recent load (the more requests, the more instances). To mark and track instances, we used a Singleton class that contained a randomly initialized static identifier field. Figure 4 shows that seven instances handled the 50 requests. Moreover, the first two requests in each instance took considerably longer than the rest. After JIT compilation, the code executed over three times faster.
Monte Carlo Simulations

One way to approximate is through a simple Monte Carlo simulation that inscribes a circle into a square, generates p uniformly distributed random points in the square, and counts m points that lie in the circle. So, we can approximate = 4 m/p. We ran this algorithm on GAE. Obtaining consistent measurements from GAE is difficult for two reasons. First, the programmer has no control over the slave instances. Second, two identical consecutive requests to the same Web application could execute on completely different hardware in different locations. To minimize the
May/June 2012
Failures
A GAE environment can have three types of failure: an exceeded quota, offline slave applications, or loss of connectivity. To cope with such failures, the master implements a simple fault-tolerance mechanism to resubmit the failed WorkJobs to the corresponding slaves using a corresponding exponential back-off time-out, depending on the failure type.
10
Resource Provisioning
Resource-provisioning overhead is the time between issuing an HTTP request and receiving the HTTP response. Various factors beyond the underlying TCP network influence the overhead (for example, load
bias, we repeated all experiments 10 times, eliminated outliers, and averaged all runs.
Time (seconds)
30 25 20 15 10 0
Execution time Computation time Time (seconds) Overhead
30 25 20 15 10 0
Execution time Computation time Overhead
Running the simulations. We conducted
Time (seconds)
30 20 10 0 0
6 4 2
Results. Figure 5 shows that serial execu-
tion on GAE was about two times slower than on Karwendel, owing to a slower random-number-generation routine in GAEs standard math library.3 On Karwendel, transferring jobs and results incurred almost no overhead, owing to the fast local network between the master and the slaves. So, the average computation time and total execution time were almost identical until eight parallel jobs (Karwendel has eight cores). Until that point, almost linear speedup occurred. Using more than eight parallel jobs generated a load imbalance that deteriorated speedup because two jobs had to share one physical core. GAE exhibited a constant data transfer and total overhead of approximately 700 milliseconds in both cases, which explains its lower speedup. The random background load on GAE servers or on the Internet network caused the slight irregularities in execution time for different machine sizes. This classic scalability analysis method didnt favor GAE because the 30-second limit let us execute only relatively small problems (in which Amdahls law limits scalability). To eliminate this barrier and evaluate GAEs potential for computing larger problems, we used Gustafsons law4 to increase the problem size proportionally to the machine size.
10 15 Number of parallel jobs
20
0 25
Figure 6. Scalability results for GAE and Karwendel for proportionally increasing machine and problem sizes. Karwendel had a constant execution time until eight parallel jobs, demonstrating our frameworks good scalability.
We observed the impact on the execution time (which should stay constant for an ideal speedup). We distributed the jobs to 10 GAE slave applications instead of one to gain sufficient quotas (in minutes). In this case, we started with an initial problem of 180 million random points to avoid exceeding the 30second limit. (For a larger number of jobs, GAE cant provide more resources and starts denying connections.) Again, Karwendel had a constant execution time until eight parallel jobs (see Figure 6), demonstrating our frameworks good scalability. Starting with nine parallel jobs, the execution time steadily increased proportionally to the problem size. GAE showed similarly good scalability until 10 parallel jobs. Starting additional parallel jobs slightly increased the execution time. The overhead of aborted requests
(owing to quotas being reached) caused most irregularities. For more than 17 parallel jobs, GAE had a lower execution time than Karwendel owing to Googles larger hardware infrastructure.
Cost Analysis
Although we conducted all our experiments within the free daily quotas that Google offered, it was still important to estimate cost to understand the price of executing our applications in real life. So, alongside the approximation, we implemented three algorithms with different computation and communication complexity (see Table 1):
matrix multiplication, based on row-wise distribution of the first matrix and full broadcast of the second;
11
Number of aborted requests
a warm-up phase for each application to determine the queue size and eliminate JIT compilations effects. We executed the calculation algorithm first sequentially and then with an increasing number of parallel jobs by generating a corresponding number of WorkJobs in the JobFactory work pool. We chose a problem of 220 million random points, which produced a sequential execution time slightly below the 30-second limit. For each experiment, we measured and analyzed two metrics. The first was computation time, which represented the average execution time of run(). The second was the average overhead, which represented the difference between the total execution time and the computation time (especially due to request latencies).
(a)
15
(b)
15
Figure 5. Results for calculating p on (a) Google App Engine (GAE) and (b) Karwendel, the local machine. Serial execution on GAE was about two times slower than on Karwendel, owing to a slower random-number-generation routine in GAEs standard math library.3
40
App engine Karwendel Aborted requests
Related Work in Cloud Performance

References
1. A. Iosup et al., Performance Analysis of Cloud Computing Services for Many-Tasks Scientific Computing, IEEE Trans. Parallel and Distributed Systems, vol. 22, no. 6, 2011, pp. 931945. 2. A. Iosup, N. Yigitbasi, and D. Epema, On the Performance Variability of Production Cloud Services, Proc. 11th IEEE/ACM Intl Symp. Cluster, Cloud, and Grid Computing (CCGrid 11), IEEE CS, pp. 104113. 3. C. Vecchiola, S. Pandey, and R. Buyya, High-Performance Cloud Computing: A View of Scientific Applications, Proc. 10th Intl Symp. Pervasive Systems, Algorithms, and Networks (ISPAN 09), IEEE CS, 2009, pp. 416. 4. J. Li et al., eScience in the Cloud: A Modis Satellite Data Reprojection and Reduction Pipeline in the Windows Azure Platform, Proc. 2010 Intl Symp. Parallel & Distributed Processing (IPDPS 10), IEEE CS, 2010, pp. 110. 5. C. Bunch, B. Drawert, and M. Norman, MapScale: A Cloud Environment for Scientific Computing, tech. report, Computer Science Dept., Univ. of California, Santa Barbara, 2009; www.cs.ucsb. edu/~cgb/papers/mapscale.pdf. 6. J. Qiu et al., Hybrid Cloud and Cluster Computing Paradigms for Life Science Applications, BMC Bioinformatics, vol. 11, supplement 12, 2010, S3; www.biomedcentral.com/content/pdf/1471-2105-11 -s12-s3.pdf. 7. J. Dean and S. Ghemawat, MapReduce: Simplified Data Processing on Large Clusters, Comm. ACM, vol. 51, no. 1, 2008, pp. 107113. 8. J. Ekanayake and G. Fox, High Performance Parallel Computing with Clouds and Cloud Technologies, Cloud Computing and Software Services: Theory and Techniques, S.A. Ahson and M. Ilyas, eds., CRC Press, 2010.
nalysis of four commercial infrastructure-as-a-servicebased clouds for scientific computing showed that cloud performance is lower than that of traditional scientific computing.1 However, the analysis indicated that cloud computing might be a viable alternative for scientists who need resources instantly and temporarily. Alexandru Iosup and his colleagues examined the longterm performance variability of Google App Engine (GAE) and Amazon Elastic Compute Cloud (EC2).2 The results showed yearly and daily patterns, as well as periods of stable performance. The researchers concluded that GAEs and EC2s performance varied among different large-scale applications. Christian Vecchiola and his colleagues analyzed different cloud providers from the perspective of high-performance computing applications, emphasizing the Aneka platformas-a-service (PaaS) framework.3 Aneka requires a third-party deployment cloud platform and doesnt support GAE. Windows Azure is a PaaS provider comparable to GAE but better suited for scientific problems. Jie Li and colleagues compared its performance to that of a desktop computer but performed no cost analysis.4 MapReduce frameworks offer a different approach to cloud computation.5,6 MapReduce is an orthogonal application class5 that targets large-data processing.7 Its less suited for computationally intensive parallel algorithms8 for example, those operating on small datasets. Furthermore, it doesnt support the implementation of more complex applications, such as recursive and nonlinear problems or scientific workflows.
Mandelbrot set generation, based on the

escape time algorithm; and rank sort, based on each array elements separate rank computation. This could potentially outperform other faster sequential algorithms.
We ran the experiments 100 times in sequence for each problem size and analyzed the cost of the three most limiting resources: CPU time, incoming data, and outgoing data, which we obtained through the Google application administration interface. We used the Google prices as of 10 January 2011: US$0.12 per outgoing Gbyte, $0.10 per incoming Gbyte, and $0.10 per CPU hour. We didnt analyze the data store quota because the overall CPU hours includes its usage.
12
As we expected, approximation was the most computationally intensive and had almost no data-to-transfer cost. Surprisingly, rank sort consumed little bandwidth compared to CPU time, even though the full unsorted array had to transfer to the slaves and the rank of each element had to transfer back to the master. The Mandelbrot set generator was clearly dominated by the amount of image data that must transfer to the master. For approximation, we generally could sample approximately 129 109 random points for US$1 because the algorithm has linear computational effort. For the other algorithms, a precise estimation is more difficult because resource consumption doesnt increase linearly with the problem size. Nevertheless, we can use the resource complexity listed in Table
1 to roughly approximate the cost to execute new problem sizes. Finally, we estimated the cost to run the same experiments on the Amazon EC2 infrastructure using EC2s m1.small instances, which have a computational performance of one EC2 compute unit. This is equivalent to a 1.2-GHz Xeon or Opteron processor, which is similar to GAE and enables a direct comparison. We packaged the implemented algorithms into Xen-based virtual machines deployed and booted on m1.small instances. Table 1 shows that the computation costs were lower for GAE, owing mostly to the cycle-based payments as opposed to EC2s hourly billing intervals. Google recently announced a change in its pricing model that will replace CPU
May/June 2012
Table 1. Resource consumption and the estimated cost for four algorithms.
Outgoing data Algorithm Problem size (points) Gbytes Complexity 0 0.85 0.95 0.02 O(1) O(n2) O(n2) O(n2) Incoming data Gbytes Complexity 0 0.75 0 0.01 O(1) O(n2) O(1) O(n) CPU time Hrs. 1.7 1.15 0.15 1.16 Complexity O(n) O(n2) O(n2) O(n2) Google App Engine (GAE) 0.170 0.292 0.129 0.119 Cost (US$) Amazon Elastic New GAE Compute Cloud 0.078 0.203 0.066 0.120 0.190 0.440 0.440 0.245
220,000,000 approximation Matrix multiplication Mandelbrot set Rank sort 1,500 1,500 3,200 3,200 70,000
cycles with a new instance-hours unit. The unit is equivalent to one application instance running for one hour and will cost $0.08. In addition, Google will charge $9 a month for every application. The new model will primarily hurt Web applications that trigger additional instances upon sparse request peaks and afterward remain idle. Table 1 gives a rough cost estimation assuming 15 parallel tasks and an instance utilization of 80 percent for useful computation. The results demonstrate that the new pricing model favors CPU-intensive applications that try to fully utilize all available instances. In addition, we can expect free resources to last longer with the new pricing model.
Scientific Computing, IEEE Trans. Parallel and Distributed Systems, vol. 22, no. 6, 2011, pp. 931945. 3. M. Sperk, Scientific Computing in the Cloud with Google App Engine, masters thesis, Faculty of Mathematics, Computer Science, and Physics, Univ. of Innsbruck, 2011; http://dps.uibk.ac.at/~radu/sperk.pdf. 4. J.L. Gustafson, Reevaluating Amdahls Law, Comm. ACM, vol. 31, no. 5, 1988, pp. 532533. Radu Prodan is an associate professor at the University of Innsbrucks Institute of Computer Science. His research interests include programming methods, compiler technology, performance analysis, and scheduling for parallel and distributed systems. Prodan has a PhD in technical services from the Vienna University of Technology. Contact him at radu@dps.uibk.ac.at.
Michael Sperk is a PhD student at the University of Innsbruck. His research interests include distributed and parallel computing. Sperk has an MSc in computer science from the University of Innsbruck. Contact him at sperk.michael@gmail.com. Simon Ostermann is a PhD student at the University of Innsbrucks Institute of Computer Science. His research interests include resource management and scheduling for grid and cloud computing. Ostermann has an MSc in computer science from the University of Innsbruck. Contact him at simon@dps. uibk.ac.at. This article originally appeared in IEEE Software, March/April 2012; http:// doi.ieeecomputersociety.org/10.1109/ MS.2011.131.
e plan to investigate the suitability of new application classes such as scientific workflow applications to be implemented on top of our generic framework and run on GAE with improved performance. For a look at other research on cloud computing performance, see the Related Work in Cloud Performance sidebar.
Acknowledgments
Austrian Science Fund project TRP 72-N23 and the Standortagentur Tirol project RainCloud funded this research.
LISTEN TO GRADY BOOCH LISTEN TO GRADY BOOCH LISTEN TO GRADY BOOC

On Architecture Podcast
www.computer.org/onarchitecture
References
1. D. Sanderson, Programming Google App Engine, OReilly Media, 2009. 2. A. Iosup et al., Performance Analysis of Cloud Computing Services for Many-Tasks
Listen to Grady Booch

on architecture Podcast www.computer.org/onarchitecture
13

opengroup.org/onlinepubs/9699919899/ toc.pdf) offers a useful overview of risk factors (see Figure 1). The Open Groups taxonomy uses the same two top-level risk factors as ISO 27005: the likelihood of a harmful event (here, loss event frequency) and its consequence (here, probable loss magnitude).1 The probable loss magnitudes subfactors (on the right in Figure 1) influence a harmful events ultimate cost. The loss event frequency subfactors (on the left) are a bit more complicated. A loss event occurs when a threat agent (such as a hacker) successfully exploits a vulnerability. The frequency with which this happens depends on two factors:
Understanding Cloud Computing Vulnerabilities

Bernd Grobauer, Tobias Walloschek, and Elmar Stcker, Siemens
Discussions about cloud computing security often fail to distinguish general issues from cloud-specific issues. To clarify the discussions regarding vulnerabilities, the authors define indicators based on sound definitions of risk factors and cloud computing.
The frequency with which threat agents try
to exploit a vulnerability. This frequency is determined by both the agents motivation (What can they gain with an attack? How much effort does it take? What is the risk for the attackers?) and how much access (contact) the agents have to the attack targets. The difference between the threat agents attack capabilities and the systems strength to resist the attack. This second factor brings us toward a useful definition of vulnerability.
Defining Vulnerability
According to the Open Groups risk taxonomy, respect to security issues, we must analyze how cloud computing influences established security issues. A key factor here is security vulnerabilities: cloud computing makes certain well-understood vulnerabilities more significant as well as adds new ones to the mix. Before we take a closer look at cloudspecific vulnerabilities, however, we must first establish what a vulnerability really is.
Vulnerability is the probability that an asset will be unable to resist the actions of a threat agent. Vulnerability exists when there is a difference between the force being applied by the threat agent, and an objects ability to resist that force.
ach day, a fresh news item, blog entry, or other publication warns us about cloud computings security risks and threats; in most cases, security is cited as the most substantial roadblock for cloud computing uptake. But this discourse about cloud computing security issues makes it difficult to formulate a wellfounded assessment of the actual security impact for two key reasons. First, in many of these discussions about risk, basic vocabulary termsincluding risk, threat, and vulnerabilityare often used interchangeably, without regard to their respective definitions. Second, not every issue raised is specific to cloud computing. To achieve a well-founded understanding of the delta that cloud computing adds with
14
Vulnerability: An Overview
Vulnerability is a prominent factor of risk. ISO 27005 defines risk as the potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization, measuring it in terms of both the likelihood of an event and its consequence.1 The Open Groups risk taxonomy (www.
So, vulnerability must always be described in terms of resistance to a certain type of attack. To provide a real-world example, a cars inability to protect its driver against injury when hit frontally by a truck driving 60 mph is a vulnerability; the resistance of the cars crumple zone is simply too weak compared to the trucks force. Against the attack of a biker, or even a small car driving at a more moderate speed, the cars resistance strength is perfectly adequate.
2012 IEEE
Productivity Control strength Vulnerability Threat capacity Random Regular International Asset value Level of effort Risk Secondary loss factors Action Organizational Contact Threat event frequency Loss event frequency Probable loss magnitude Risk Primary loss factors Threat loss Asset loss Value Volume Competence Action Internal vs. external Timing Due diligence Response Detection Detection External Legal & regulatory Competitors Media Stakeholders Containment Remediation Recovery Sensitivity Cost Access Misuse Disclose Modify Deny access
Embarrassment Competitive advantage Legal/regulatory General
Figure 1. Factors contributing to risk according to the Open Groups risk taxonomy. Risk corresponds to the product of loss event frequency (left) and probable loss magnitude (right). Vulnerabilities influence the loss event frequency.
We can also describe computer vulnerabilitythat is, security-related bugs that you close with vendor-provided patchesas a weakening or removal of a certain resistance strength. A buffer-overflow vulnerability, for example, weakens the systems resistance to arbitrary code execution. Whether attackers can exploit this vulnerability depends on their capabilities.
Vulnerabilities and Cloud Risk

Well now examine how cloud computing influences the risk factors in Figure 1, starting with the right-hand side of the risk factor tree. From a cloud customer perspective, the right-hand side dealing with probable magnitude of future loss isnt changed at all by cloud computing: the consequences and ultimate cost of, say, a confidentiality breach, is exactly the same regardless of whether the data breach occurred within a cloud or a conventional IT infrastructure. For a cloud service provider, things look somewhat different: because cloud computing systems were previously separated on the same infrastructure, a loss event could entail a considerably larger impact. But this fact is easily grasped and incorporated into a risk assessment: no conceptual work for adapting impact analysis to cloud computing seems necessary. So, we must search for changes on Figure
1s left-hand sidethe loss event frequency. Cloud computing could change the probability of a harmful events occurrence. As we show later, cloud computing causes significant changes in the vulnerability factor. Of course, moving to a cloud infrastructure might change the attackers access level and motivation, as well as the effort and riska fact that must be considered as future work. But, for supporting a cloud-specific risk assessment, it seems most profitable to start by examining the exact nature of cloud-specific vulnerabilities.
Web applications and services. Software
Cloud Computing
Is there such a thing as a cloud-specific vulnerability? If so, certain factors in cloud computings nature must make a vulnerability cloud-specific. Essentially, cloud computing combines known technologies (such as virtualization) in ingenious ways to provide IT services from the conveyor belt using economies of scale. Well now look closer at what the core technologies are and which characteristics of their use in cloud computing are essential.
Core Cloud Computing Technologies

Cloud computing builds heavily on capabilities available through several core technologies:
as a service (SaaS) and platform as a service (PaaS) are unthinkable without Web application and Web services technologies: SaaS offerings are typically implemented as Web applications, while PaaS offerings provide development and runtime environments for Web applications and services. For infrastructure as a service (IaaS) offerings, administrators typically implement associated services and APIs, such as the management access for customers, using Web application/service technologies. Virtualization IaaS offerings. These technologies have virtualization techniques at their very heart; because PaaS and SaaS services are usually built on top of a supporting IaaS infrastructure, the importance of virtualization also extends to these service models. In the future, we expect virtualization to develop from virtualized servers toward computational resources that can be used more readily for executing SaaS services. Cryptography. Many cloud computing security requirements are solvable only by using cryptographic techniques. As cloud computing develops, the list of core technologies is likely to expand.
15
Essential Characteristics
In its description of essential cloud characteristics,2 the US National Institute of Standards and Technology (NIST) captures well what it means to provide IT services from the conveyor belt using economies of scale:
Core-Technology Vulnerabilities
Cloud computings core technologiesWeb applications and services, virtualization, and cryptographyhave vulnerabilities that are either intrinsic to the technology or prevalent in the technologys state-of-the-art implementations. Three examples of such vulnerabilities are virtual machine escape, session riding and hijacking, and insecure or obsolete cryptography. First, the possibility that an attacker might successfully escape from a virtualized environment lies in virtualizations very nature. Hence, we must consider this vulnerability as intrinsic to virtualization and highly relevant to cloud computing. Second, Web application technologies must overcome the problem that, by design, the HTTP protocol is a stateless protocol, whereas Web applications require some notion of session state. Many techniques implement session handling andas any security professional knowledgeable in Web application security will testifymany session handling implementations are vulnerable to session riding and session hijacking. Whether session riding/hijacking vulnerabilities are intrinsic to Web application technologies or are only prevalent in many current implementations is arguable; in any case, such vulnerabilities are certainly relevant for cloud computing. Finally, cryptoanalysis advances can render any cryptographic mechanism or algorithm insecure as novel methods of breaking them are discovered. Its even more common to find crucial flaws in cryptographic algorithm implementations, which can turn strong encryption into weak encryption (or sometimes no encryption at all). Because broad uptake of cloud computing is unthinkable without the use of cryptography to protect data confidentiality and integrity in the cloud, insecure or obsolete cryptography vulnerabilities are highly relevant for cloud computing.
vulnerabilities with root causes in one or more of these characteristics:
Unauthorized access to management inter-
On-demand self-service. Users can order
and manage services without human interaction with the service provider, using, for example, a Web portal and management interface. Provisioning and de-provisioning of services and associated resources occur automatically at the provider. Ubiquitous network access. Cloud services are accessed via the network (usually the Internet), using standard mechanisms and protocols. Resource pooling. Computing resources used to provide the cloud service are realized using a homogeneous infrastructure thats shared between all service users. Rapid elasticity. Resources can be scaled up and down rapidly and elastically. Measured service. Resource/service usage is constantly metered, supporting optimization of resource usage, usage reporting to the customer, and pay-as-you-go business models.
NISTs definition framework for cloud computing with its list of essential characteristics has by now evolved into the de facto standard for defining cloud computing.
Cloud-Specific Vulnerabilities
Based on the abstract view of cloud computing we presented earlier, we can now move toward a definition of what constitutes a cloud-specific vulnerability. A vulnerability is cloud specific if it
face. The cloud characteristic on-demand self-service requires a management interface thats accessible to cloud service users. Unauthorized access to the management interface is therefore an especially relevant vulnerability for cloud systems: the probability that unauthorized access could occur is much higher than for traditional systems where the management functionality is accessible only to a few administrators. Internet protocol vulnerabilities. The cloud characteristic ubiquitous network access means that cloud services are accessed via network using standard protocols. In most cases, this network is the Internet, which must be considered untrusted. Internet protocol vulnerabilitiessuch as vulnerabilities that allow man-in-the-middle attacksare therefore relevant for cloud computing. Data recovery vulnerability. The cloud characteristics of pooling and elasticity entail that resources allocated to one user will be reallocated to a different user at a later time. For memory or storage resources, it might therefore be possible to recover data written by a previous user. Metering and billing evasion. The cloud characteristic of measured service means that any cloud service has a metering capability at an abstraction level appropriate to the service type (such as storage, processing, and active user accounts). Metering data is used to optimize service delivery as well as billing. Relevant vulnerabilities include metering and billing data manipulation and billing evasion. Thus, we can leverage NISTs wellfounded definition of cloud computing in reasoning about cloud computing issues.
is intrinsic to or prevalent in a core cloud has its root cause in one of NISTs essential is caused when cloud innovations make
cloud characteristics, tried-and-tested security controls difficult or impossible to implement, or is prevalent in established state-of-the-art cloud offerings. We now examine each of these four indicators.
16
computing technology,
Essential Cloud Characteristic Vulnerabilities

As we noted earlier, NIST describes five essential cloud characteristics: on-demand self-service, ubiquitous network access, resource pooling, rapid elasticity, and measured service. Following are examples of
Defects in Known Security Controls

Vulnerabilities in standard security controls must be considered cloud specific if cloud innovations directly cause the difficulties in implementing the controls. Such vulnerabilities are also known as control challenges. Here, we treat three examples of such control challenges. First, virtualized networks offer
May/June 2012
insufficient network-based controls. Given the nature of cloud services, the administrative access to IaaS network infrastructure and the ability to tailor network infrastructure are typically limited; hence, standard controls such as IP-based network zoning cant be applied. Also, standard techniques such as network-based vulnerability scanning are usually forbidden by IaaS providers because, for example, friendly scans cant be distinguished from attacker activity. Finally, technologies such as virtualization mean that network traffic occurs on both real and virtual networks, such as when two virtual machine environments (VMEs) hosted on the same server communicate. Such issues constitute a control challenge because tried and tested network-level security controls might not work in a given cloud environment. The second challenge is in poor key management procedures. As noted in a recent European Network and Information Security Agency study,3 cloud computing infrastructures require management and storage of many different kinds of keys. Because virtual machines dont have a fixed hardware infrastructure and cloud-based content is often geographically distributed, its more difficult to apply standard controlssuch as hardware security module (HSM) storage to keys on cloud infrastructures. Finally, security metrics arent adapted to cloud infrastructures. Currently, there are no standardized cloud-specific security metrics that cloud customers can use to monitor the security status of their cloud resources. Until such standard security metrics are developed and implemented, controls for security assessment, audit, and accountability are more difficult and costly, and might even be impossible to employ.
manipulating service or application inputs to interpret and execute parts of them against the programmers intentions. Examples of injection vulnerabilities include
SQL injection, in which the input contains
SQL code thats erroneously executed in the database back end; command injection, in which the input contains commands that are erroneously executed via the OS; and cross-site scripting, in which the input contains JavaScript code thats erroneously executed by a victims browser. In addition, many widely used authentication mechanisms are weak. For example, usernames and passwords for authentication are weak due to
insecure user behavior (choosing weak

passwords, reusing passwords, and so on), and inherent limitations of one-factor authentication mechanisms. Also, the authentication mechanisms implementation might have weaknesses and allow, for example, credential interception and replay. The majority of Web applications in current state-of-the-art cloud services employ usernames and passwords as authentication mechanism.
immaterial (such as a runtime environment). For two layers, the cloud software environment and the cloud software infrastructure, the model makes the layers three main service componentscomputation, storage, and communicationexplicit. Top layer services also can be implemented on layers further down the stack, in effect skipping intermediate layers. For example, a cloud Web application can be implemented and operated in the traditional waythat is, running on top of a standard OS without using dedicated cloud software infrastructure and environment components. Layering and compositionality imply that the transition from providing some service or function inhouse to sourcing the service or function can take place between any of the models layers. In addition to the original model, weve identified supporting functions relevant to services in several layers and added them to the model as vertical spans over several horizontal layers. Our cloud reference architecture has three main parts:
Supporting (IT) infrastructure. These are
Architectural Components and Vulnerabilities

Cloud service models are commonly divided into SaaS, PaaS, and IaaS, and each model influences the vulnerabilities exhibited by a given cloud infrastructure. Its helpful to add more structure to the service model stacks: Figure 2 shows a cloud reference architecture that makes the most important security-relevant cloud components explicit and provides an abstract overview of cloud computing for security issue analysis. The reference architecture is based on work carried out at the University of California, Los Angeles, and IBM.4 It inherits the layered approach in that layers can encompass one or more service components. Here, we use service in the broad sense of providing something that might be both material (such as shelter, power, and hardware) and
Prevalent Vulnerabilities in State-of-the-Art Cloud Offerings

Although cloud computing is relatively young, there are already myriad cloud offerings on the market. Hence, we can complement the three cloud-specific vulnerability indicators presented earlier with a forth, empirical indicator: if a vulnerability is prevalent in state-of-the-art cloud offerings, it must be regarded as cloud-specific. Examples of such vulnerabilities include injection vulnerabilities and weak authentication schemes. Injection vulnerabilities are exploited by
facilities and services common to any IT service, cloud or otherwise. We include them in the architecture because we want to provide the complete picture; a full treatment of IT security must account for a cloud services non-cloud-specific components. Cloud-specific infrastructure. These components constitute the heart of a cloud service; cloud-specific vulnerabilities and corresponding controls are typically mapped to these components. Cloud service consumer. Again, we include the cloud service customer in the reference architecture because its relevant to an all-encompassing security treatment. Also, we make explicit the network that separates the cloud service consumer from the cloud infrastructure; the fact that access to cloud resources is carried out via a (usually untrusted) network is one of cloud computings main characteristics. Using the cloud reference architectures structure, we can now run through the architectures components and give examples of each components cloud-specific vulnerabilities.
17
User Front end Network SaaS Cloud (Web) applications Management access Cloud software environment Computational resources IaaS Cloud software infrastructure Kernel (OS/apps) Hardware Facilities Service customer Cloud-speci c infrastructure Supporting (IT) infrastructure Storage Communication IAAA mechanisms Services & APIs
PaaS
Figure 2. The cloud reference architecture. We map cloud-specific vulnerabilities to components of this reference architecture, which gives us an overview of which vulnerabilities might be relevant for a given cloud service.
Cloud Software Infrastructure and Environment

The cloud software infrastructure layer provides an abstraction level for basic IT resources that are offered as services to higher layers: computational resources (usually VMEs), storage, and (network) communication. These services can be used individually, as is typically the case with storage services, but theyre often bundled such that servers are delivered with certain network connectivity and (often) access to storage. This bundle, with or without storage, is usually referred to as IaaS. The cloud software environment layer provides services at the application platform level:
a development and runtime environment

for services and applications written in one or more supported languages; storage services (a database interface rather than file share); and communication infrastructure, such as Microsofts Azure service bus.
by these two layers. However, cross-tenant access vulnerabilities are relevant for all three resource types. The virtual machine escape vulnerability we described earlier is a prime example. We used it to demonstrate a vulnerability thats intrinsic to the core virtualization technology, but it can also be seen as having its root cause in the essential characteristic of resource pooling: whenever resources are pooled, unauthorized access across resources becomes an issue. Hence, for PaaS, where the technology to separate different tenants (and tenant services) isnt necessarily based on virtualization (although that will be increasingly true), cross-tenant access vulnerabilities play an important role as well. Similarly, cloud storage is prone to cross-tenant storage access, and cloud communicationin the form of virtual networkingis prone to cross-tenant network access.
Computational Resources
A highly relevant set of computational resource vulnerabilities concerns how virtual machine images are handled: the only feasible way of providing nearly identical server imagesthus providing on-demand
service for virtual serversis by cloning template images. Vulnerable virtual machine template images cause OS or application vulnerabilities to spread over many systems. An attacker might be able to analyze configuration, patch level, and code in detail using administrative rights by renting a virtual server as a service customer and thereby gaining knowledge helpful in attacking other customers images. A related problem is that an image can be taken from an untrustworthy source, a new phenomenon brought on especially by the emerging marketplace of virtual images for IaaS services. In this case, an image might, for example, have been manipulated so as to provide back-door access for an attacker. Data leakage by virtual machine replication is a vulnerability thats also rooted in the use of cloning for providing on-demand service. Cloning leads to data leakage problems regarding machine secrets: certain elements of an OSsuch as host keys and cryptographic salt valuesare meant to be private to a single host. Cloning can violate this privacy assumption. Again, the emerging marketplace for virtual machine images, as in Amazon EC2, leads to a related problem: users can provide template images for other users by turning a running image into a template. Depending on how the image was used before creating a template from it, it could contain data that the user doesnt wish to make public. There are also control challenges here, including those related to cryptography use. Cryptographic vulnerabilities due to weak random number generation might exist if the abstraction layer between the hardware and OS kernel introduced by virtualization is problematic for generating random numbers within a VME. Such generation requires an entropy source on the hardware level. Virtualization might have flawed mechanisms for tapping that entropy source, or having several VMEs on the same host might exhaust the available entropy, leading to weak random number generation. As we noted earlier, this abstraction layer also complicates the use of advanced security controls, such as hardware security modules, possibly leading to poor key management procedures.
Vulnerabilities in both the infrastructure and environment layers are usually specific to one of the three resource types provided
18
Provider
Storage
In addition to data recovery vulnerability
May/June 2012
due to resource pooling and elasticity, theres a related control challenge in media sanitization, which is often hard or impossible to implement in a cloud context. For example, data destruction policies applicable at the end of a life cycle that require physical disk destruction cant be carried out if a disk is still being used by another tenant. Because cryptography is frequently used to overcome storage-related vulnerabilities, this core technologys vulnerabilities insecure or obsolete cryptography and poor key managementplay a special role for cloud storage.
an application component operated somewhere in the cloud, and a browser component running within the users browser.
Communication
The most prominent example of a cloud communications service is the networking provided for VMEs in an IaaS environment. Because of resource pooling, several customers are wikely to share certain network infrastructure components: vulnerabilities of shared network infrastructure components, such as vulnerabilities in a DNS server, Dynamic Host Configuration Protocol, and IP protocol vulnerabilities, might enable network-based cross-tenant attacks in an IaaS infrastructure. Virtualized networking also presents a control challenge: again, in cloud services, the administrative access to IaaS network infrastructure and the possibility for tailoring network infrastructure are usually limited. Also, using technologies such as virtualization leads to a situation where network traffic occurs not only on real networks but also within virtualized networks (such as for communication between two VMEs hosted on the same server); most implementations of virtual networking offer limited possibilities for integrating networkbased security. All in all, this constitutes a control challenge of insufficient networkbased controls because tried-and-tested network-level security controls might not work in a given cloud environment.
In the future, developers will increasingly use technologies such as Google Gears to permit offline usage of a Web applications browser component for use cases that dont require constant access to remote data. Weve already described two typical vulnerabilities for Web application technologies: session riding and hijacking vulnerabilities and injection vulnerabilities. Other Web-application-specific vulnerabilities concern the browsers front-end component. Among them are client-side data manipulation vulnerabilities, in which users attack Web applications by manipulating data sent from their application component to the servers application component. In other words, the input received by the server component isnt the expected input sent by the client-side component, but altered or completely user-generated input. Furthermore, Web applications also rely on browser mechanisms for isolating third-party content embedded in the application (such as advertisements, mashup components, and so on). Browser isolation vulnerabilities might thus allow third-party content to manipulate the Web application.
effort or service provider interaction. Consequently, a common element of each cloud service is a management interfacewhich leads directly to the vulnerability concerning unauthorized access to the management interface. Furthermore, because management access is often realized using a Web application or service, it often shares the vulnerabilities of the Web application layer and services/API component.
Identity, Authentication, Authorization, and Auditing Mechanisms

All cloud services (and each cloud services management interface) require mechanisms for identity management, authentication, authorization, and auditing (IAAA). To a certain extent, parts of these mechanisms might be factored out as a stand-alone IAAA service to be used by other services. Two IAAA elements that must be part of each service implementation are execution of adequate authorization checks (which, of course, use authentication and/or authorization information received from an IAA service) and cloud infrastructure auditing. Most vulnerabilities associated with the IAAA component must be regarded as cloud-specific because theyre prevalent in state-of-the-art cloud offerings. Earlier, we gave the example of weak user authentication mechanisms; other examples include
Services and APIs

It might seem obvious that all layers of the cloud infrastructure offer services, but for examining cloud infrastructure security, its worthwhile to explicitly think about all of the infrastructures service and application programming interfaces. Most services are likely Web services, which share many vulnerabilities with Web applications. Indeed, the Web application layer might be realized completely by one or more Web services such that the application URL would only give the user a browser component. Thus the supporting services and API functions share many vulnerabilities with the Web applications layer.
Denial of service by account lockout. One
Cloud Web Applications

A Web application uses browser technology as the front end for user interaction. With the increased uptake of browser-based computing technologies such as JavaScript, Java, Flash, and Silverlight, a Web cloud application falls into two parts:
Management Access
NISTs definition of cloud computing states that one of cloud services central characteristics is that they can be rapidly provisioned and released with minimal management
often-used security controlespecially for authentication with username and passwordis to lock out accounts that have received several unsuccessful authentication attempts in quick succession. Attackers can use such attempts to launch DoS attacks against a user. Weak credential-reset mechanisms. When cloud computing providers manage user credentials themselves rather than using federated authentication, they must provide a mechanism for resetting credentials in the case of forgotten or lost credentials. In the past, password-recovery mechanisms have proven particularly weak. Insufficient or faulty authorization checks. State-of-the-art Web application and service cloud offerings are often vulnerable to insufficient or faulty authorization
19
checks that can make unauthorized information or actions available to users. Missing authorization checks, for example, are the root cause of URL-guessing attacks. In such attacks, users modify URLs to display information of other user accounts. Coarse authorization control. Cloud services management interfaces are particularly prone to offering authorization control models that are too coarse. Thus, standard security measures, such as duty separation, cant be implemented because its impossible to provide users with only those privileges they strictly require to carry out their work. Insufficient logging and monitoring possibilities. Currently, no standards or mechanisms exist to give cloud customers logging and monitoring facilities within cloud resources. This gives rise to an acute problem: log files record all tenant events and cant easily be pruned for a single tenant. Also, the providers security monitoring is often hampered by insufficient monitoring capabilities. Until we develop and implement usable logging and monitoring standards and facilities, its difficultif not impossibleto implement security controls that require logging and monitoring. Of all these IAAA vulnerabilities, in the experience of cloud service providers, currently, authentication issues are the primary vulnerability that puts user data in cloud services at risk. 5
will emerge, while others will become less of an issue. Using a precise definition of what constitutes a vulnerability from the Open Groups risk taxonomy and the four indicators of cloud-specific vulnerabilities we identify here offers a precision and clarity level often lacking in current discourse about cloud computing security. Control challenges typically highlight situations in which otherwise successful security controls are ineffective in a cloud setting. Thus, these challenges are of special interest for further cloud computing security research. Indeed, many current efforts such as the development of security metrics and certification schemes, and the move toward full-featured virtualized network componentsdirectly address control challenges by enabling the use of such tried-andtested controls for cloud computing.
(CERTs) research activities in incident detection and handling, malware defense, and cloud computing security. Grobauer has a PhD in computer science from Aarhus University, Denmark. Hes on the membership advisory committee of the International Information Integrity Institute. Contact him at bernd.grobauer@siemens.com. Tobias Walloschek is a senior management consultant at Siemens IT Solutions and Services GmbH. His research interests are cloud computing security and business adoption strategies. Walloschek has a bachelors degree in business administration from the University of Applied Sciences in Ingolstadt, Germany. He is a Certified Information Systems Security Professional. Contact him at tobias. walloschek@siemens.com. Elmar Stcker is a manager at Siemens IT Solutions and Services GmbH, where hes responsible for the portfolio strategy and governance of the professional services portfolio; he also leads the cloud computing security and PaaS activities. Stcker has a masters degree in computer science from RWTH Aachen, Germany. Contact him at elmar.stoecker@siemens.com.
References
1. ISO/IEC 27005:2007 Information TechnologySecurity TechniquesInformation Security Risk Management, Intl Org. Standardization, 2007. 2. P. Mell and T. Grance, Effectively and Securely Using the Cloud Computing Paradigm (v0.25), presentation, US Natl Inst. Standards and Technology, 2009; http://csrc.nist.gov/groups/SNS/ cloud-computing. 3. European Network and Information Security Agency (ENISA), Cloud Computing: Benefits, Risks and Recommendations for Information Security, Nov. 2009; www.enisa. europa.eu/act/rm/files/deliverables/ cloud-computing-risk-assessment/at _download/fullReport. 4. L. Youseff, M. Butrico, and D. Da Silva, Towards a Unified Ontology of Cloud Computing, Proc. Grid Computing Environments Workshop (GCE), IEEE Press, 2008; doi: 10.1109/GCE.2008.4738443. 5. E. Grosse, Security at Scale, invited talk, ACM Cloud Security Workshop (CCSW), 2010; http:// w n .c o m / 2 0 1 0 _ G o o g l e _ Fa c u l t y _Summit_Security_at_Scale. Bernd Grobauer is a senior consultant in information security and leads the Siemens Computer Emergency Response Teams
This article originally appeared in IEEE Security & Privacy, March/April 2011; http://doi.ieeecomputersociety. org/10.1109/MSP.2010.115.
Provider
Vulnerabilities that are relevant for all cloud computing components typically concern the provideror rather users inability to control cloud infrastructure as they do their own infrastructure. Among the control challenges are insufficient security audit possibilities, and the fact that certification schemes and security metrics arent adopted to cloud computing. Further, standard security controls regarding audit, certification, and continuous security monitoring cant be implemented effectively.
SANDBOXIN
TING DETEC ALIZATION G & VIRTU
CHEATERS
INSIDER ATTACKS MOBILE TWO-FACTOR AUTHENTICATION
TRUTH IN CROWDSOURC ING
Success ful Sec urity Dec isions Comput er Securit
y since
9/11
YEA RS
SEPTEMBER/OCTO
BER 2011
MARCH
/APRIL 2011
Building
Depend
ability,
Reliabil
ity, and
Trust
DIGITAL EDITION
Janua ry/Februar y Vol. 10, 2012 No. 1
SUBSCRIBE FOR $19 95
C
20
loud computing is in constant development; as the field matures, additional cloud-specific vulnerabilities certainly
www.qmags.com/SNP
May/June 2012
IEEE CloudCom 2012

4th IEEE International Conference on Cloud Computing Technology and Science
3-6 December 2012

Taipei, Taiwan
The Cloud is a natural evolution of distributed computing and the widespread adaption of virtualization and Service Oriented Architecture. In Cloud Computing, IT-related capabilities and resources are provided as services, via the Internet and ondemand, accessible without requiring detailed knowledge of the underlying technology. IEEE CloudCom 2012, steered by the Cloud Computing Association, brings together cloud computing researchers and related technologies.
Register today!
http://2012.cloudcom.org/
SEPTEMBER 2011
http://www.computer.org
MB
ER
E OV
CYBERBULLYING, P. 93 SOFT BIOMETRICS, P. 106 HAS EVERTHING BEEN INVENTED?, P. 112
FEBRUARY 2012
htt
p://w
79 , P. 112 ION , P. 90 NIT TS , P. OG AN PS EC IST MA RR SS EA LA ING A C N ON UR MA RS SO HU E D DP OW TE CR MA TO AU
ww.comp ute
r.org
r.org
CS PR ESIDE NTS ME SSAGE, MUSE UMS AT P. 8 YOUR FINGE THE PR RTIPS , P. 87 DIGITA OFESSION AN L TECH NOLO D GY, P. 116
mp
ute
http://www.comp http: http://www.computer.org .comp
INTERACTIVE TABLETOPS, PP. 78 PP SMARTPHONE SECURITY, PP. 82 HONE SE TY, TY, PP GAME MAKING, PP. 85 PP.
Now Available in Advanced Digital Format
More value, more content, more resources

The new multi-faceted Computer offers exclusive video and web extras that you can access only through this advanced digital version. Dive deeper into the latest technical developments with a magazine that is: SearchableQuickly find the latest information in your fields of interest. Access the digital archives, and save whats most relevant to you. LinkedClick on table of contents links and instantly go to the articles you want to read first. Article links go to additional references to deepen your new discoveries. EngagingAbsorb concepts as they come to life through related audio, video, animation, and more. Email authors directly. Even apply for jobs through convenient ad links. MobileRead the issue anytime, anywhere, at your convenienceon your laptop, iPad, or other mobile device.
Switch from print at computer.org/digitalcomputer
htt p://w
.co ww
DECEM
20
11
BER 2 011

I Eee Cloud Computing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

I Eee Cloud Computing

Uploaded by

Copyright:

Available Formats

cloud computing

Google App Engine

The Essentials Issue

Guest Editors Introduction

Joseph L. Hellerstein, Kai J. Kohlho , and David E. Konerding

Evaluating High-Performance Computing on Google App Engine

Radu Prodan, Michael Sperk, and Simon Ostermann

14 Understanding Cloud Computing Vulnerabilities

IEEE Computer Society Sta Angela Burgess

Monette Velasco and Jennie Zhu

Guest Editors Introduction

The Essentials Issue

Science in the Cloud

Harvesting Cycles for Science

Published by the IEEE Computer Society

Daimyo (global manager) Submit Monitor User

Peasant discovery service Peasant joins

The Essentials Issue

GPCR Extracellular side

Ligand binding site

Simulating Molecular Dynamics

Intracellular side G protein binding site

Salt bridge formation nanoseconds 101 102 103

Ligand binding microseconds 104 105 106

The enzyme science project seeks to discover

planetary-scale collaborations that power scientific discovery in the 21st century.

This article will appear in IEEE Internet Computing, July/August 2012.

The Essentials Issue

Cloud Computing: A Brief Introduction

Published by the IEEE Computer Society

loss of governance, integration, and

Is the Cloud Right for You?

Managing Information Assets in the Cloud

Operating in the Cloud

The Essentials Issue

Evaluating High-Performance Computing on Google App Engine

Applications have no access to the under-

A Parallel Computing Framework

Published by the IEEE Computer Society

DSS Data store

The Essentials Issue

Monte Carlo Simulations

Execution time Computation time Time (seconds) Overhead

Execution time Computation time Overhead

Running the simulations. We conducted

Results. Figure 5 shows that serial execu-

10 15 Number of parallel jobs

Number of aborted requests

5 10 Number of parallel jobs

5 10 Number of parallel jobs

App engine Karwendel Aborted requests

The Essentials Issue

Related Work in Cloud Performance

Mandelbrot set generation, based on the

LISTEN TO GRADY BOOCH LISTEN TO GRADY BOOCH LISTEN TO GRADY BOOC

Listen to Grady Booch

The Essentials Issue

Understanding Cloud Computing Vulnerabilities

The frequency with which threat agents try

Published by the IEEE Computer Society

Embarrassment Competitive advantage Legal/regulatory General

Vulnerabilities and Cloud Risk

Web applications and services. Software