cern about the difficulty of extracting data from the cloud is preventing some organizations from adopting cloud computing. Customer lock-in may be attractive to cloud computing providers, but their users are vulnerable to price increases, to reliability problems, or even to providers going out of business.

For example, an online storage service called The Linkup shut down on Aug. 8, 2008 after losing access as much as 45% of customer data. 6 The Linkup, in turn, had relied on the online storage service Nirvanix to store customer data, which led to finger pointing between the two organizations as to why customer data was lost. Meanwhile, The Linkup’s 20,000 users were told the service was no longer available and were urged to try out another storage site.

One solution would be to standardize the APIsd in such a way that a SaaS developer could deploy services and data across multiple cloud computing providers so that the failure of a single company would not take all copies of customer data with it. One might worry that this would lead to a “ race-to-the-bottom” of cloud pricing and flatten the profits of cloud computing providers. We offer two arguments to allay this fear.

First, the quality of a service matters as well as the price, so customers may not jump to the lowest-cost service. Some Internet service providers today cost a factor of 10 more than others because they are more dependable and offer extra services to improve usabil-ity.

Second, in addition to mitigating
data lock-in concerns, standardization
of APIs enables a new usage model in
which the same software infrastruc-
ture can be used in an internal data
center and in a public cloud. Such an
option could enable hybrid cloud com-
puting or surge computing in which
the public cloud is used to capture the
extra tasks that cannot be easily run
in the data center (or private cloud)
due to temporarily heavy workloads.
This option could significantly expand
the cloud computing market. Indeed,
open-source reimplementations of
proprietary cloud APIs, such as Euca-
lyptus and HyperTable, are first steps
in enabling surge computing.

number 3. Data
Confidentiality/Auditability

Despite most companies outsourcing payroll and many companies using external email services to hold sensitive information, security is one of the most often-cited objections to cloud computing; analysts and skeptical companies ask “who would trust their essential data out there somewhere?” There are also requirements for auditability, in the sense of Sarbanes-Oxley and Health and Human Services Health Insurance Portability and Accountability Act (HIPAA) regulations that must be provided for corporate data to be moved to the cloud.

Cloud users face security threats both from outside and inside the cloud. Many of the security issues involved in protecting clouds from outside threats are similar to those already facing large data centers. In the cloud, however, this responsibility is divided among potentially many parties, including the cloud user, the cloud vendor, and any third-party vendors that users rely on for security-sensitive software or configurations.

The cloud user is responsible for
application-level security. The cloud
provider is responsible for physical
security, and likely for enforcing exter-
nal firewall policies. Security for inter-
mediate layers of the software stack is
shared between the user and the oper-
ator; the lower the level of abstraction
exposed to the user, the more respon-
sibility goes with it. Amazon EC2 us-
ers have more technical responsibility
(that is, must implement or procure
more of the necessary functionality
themselves) for their security than do
Azure users, who in turn have more re-
sponsibilities than AppEngine custom-
ers. This user responsibility, in turn,
can be outsourced to third parties who
sell specialty security services. The ho-
mogeneity and standardized interfaces
of platforms like EC2 make it possible
for a company to offer, say, configura-
tion management or firewall rule anal-
ysis as value-added services.

table 3. outages in AWS, AppEngine, and gmail service and outage duration date.

Service and outage Duration S3 outage: authentication service overload leading to unavailability17 2 hours S3 outage: Single bit error leading to gossip protocol blowup18 6–8 hours Appengine partial outage: programming error19 5 hours Gmail: site unavailable due to outage in contacts system11 1. 5 hours

Date 2/15/08 7/20/08 6/17/08 8/11/08