Cloud Computing Use Cases Whitepaper


Published on

Cloud Computing Use Cases
A white paper produced by the Cloud Computing Use Case Discussion Group
31 July 2009
Contributors: Dustin Amrhein, Joe Armstrong, Ezhil Arasan B, Richard Bruklis, Reuven Cohen, Rodrigo Flores, Gaston Fourcade, Thomas Freund, William Jay Huie, Sam Johnston, Ravi Kulkarni, Anil Kunjunny, Gary Mazzaferro, Andres Monroy-Hernandez, Dirk Nicol, Lisa Noon, Santosh Padhy, Balu Ramachandran, Jason Reed, German Retana, Dave Russell, Krishna Sankar, Patrick Stingley, Robert Syputa, Doug Tidwell, Kris Walker, Kurt Williams, John M Willis, Yutaka Sasaki, and Fred Zappert.
Public comments on this document are welcomed and encouraged at

Published in: Technology
  • Cloud Computing Magazine
    Are you sure you want to  Yes  No
    Your message goes here
  • City Real Estate Europe -

    عقار -

    حكايات نواعم -
    Are you sure you want to  Yes  No
    Your message goes here
  • thanks for sharing , its different from other articles about cloud computing thanks again
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cloud Computing Use Cases Whitepaper

  1. 1. 1 Cloud Computing Use Cases 2 A white paper produced by the 3 Cloud Computing Use Case Discussion Group 4 31 July 2009 5 Contributors: Dustin Amrhein, Joe Armstrong, Ezhil Arasan B, Richard Bruklis, 6 Reuven Cohen, Rodrigo Flores, Gaston Fourcade, Thomas Freund, William Jay 7 Huie, Sam Johnston, Ravi Kulkarni, Anil Kunjunny, Gary Mazzaferro, Andres 8 Monroy-Hernandez, Dirk Nicol, Lisa Noon, Santosh Padhy, Balu Ramachandran, 9 Jason Reed, German Retana, Dave Russell, Krishna Sankar, Patrick Stingley, 10 Robert Syputa, Doug Tidwell, Kris Walker, Kurt Williams, John M Willis, Yutaka 11 Sasaki, and Fred Zappert. 12 Public comments on this document are welcomed and encouraged at 13 This work is licensed under a Creative Commons Attribution Share Alike 3.0 Unported License.
  2. 2. Cloud Computing Use Cases White Paper 14 Table of Contents 15 1 Introduction......................................................................................................3 16 2 Definitions and Taxonomy ...............................................................................5 17 2.1 Definitions of Cloud Computing Concepts ..............................................5 18 2.2 Taxonomy ...............................................................................................9 19 2.3 Relationships Between Standards and Taxonomies.............................12 20 3 Use Case Scenarios......................................................................................14 21 3.1 End User to Cloud.................................................................................16 22 3.2 Enterprise to Cloud to End User ...........................................................17 23 3.3 Enterprise to Cloud ...............................................................................19 24 3.4 Enterprise to Cloud to Enterprise ..........................................................20 25 3.5 Private Cloud ........................................................................................22 26 3.6 Changing Cloud Vendors ......................................................................23 27 3.7 Hybrid Cloud .........................................................................................25 28 4 Customer Scenarios ......................................................................................29 29 4.1 Customer Scenario: Payroll Processing in the Cloud............................29 30 4.2 Customer Scenario: Logistics and Project Management in the Cloud ..31 31 4.3 Customer Scenario: Central Government Services in the Cloud ..........32 32 4.4 Customer Scenario: Local Government Services in a Hybrid Cloud .....33 33 4.5 Customer Scenario: Astronomic Data Processing ................................34 34 5 Conclusions and Recommendations .............................................................36 35 31 July 2009 2
  3. 3. Cloud Computing Use Cases White Paper 36 1 Introduction 37 The Cloud Computing Use Case group brought together cloud consumers and 38 cloud vendors to define common use case scenarios for cloud computing. The 39 use case scenarios demonstrate the performance and economic benefits of 40 cloud computing and are based on the needs of the widest possible range of 41 consumers. 42 The goal of this white paper is to highlight the capabilities and requirements that 43 need to be standardized in a cloud environment to ensure interoperability, ease 44 of integration and portability. It must be possible to implement all of the use 45 cases described in this paper without using closed, proprietary technologies. 46 Cloud computing must evolve as an open environment, minimizing vendor lock-in 47 and increasing customer choice. 48 The use cases: 49 • Provide a practical, customer-experience-based context for discussions on 50 interoperability and standards. 51 • Make it clear where existing standards should be used. 52 • Focus the industry's attention on the importance of Open Cloud Computing. 53 • Make it clear where there is standards work to be done. If a particular use 54 case can't be built today, or if it can only be built with proprietary APIs and 55 products, the industry needs to define standards to make that use case 56 possible. 57 A use case that clearly describes a common task and outlines the difficulties in 58 accomplishing it is the best possible justification for any standards effort. 59 The Open Cloud Manifesto ( is a statement of the 60 principles for maintaining openness in cloud computing. Within two months of its 61 announcement, 250 organizations signed on as supporters. This group's activity 62 is done in light of the six principles of the Open Cloud Manifesto: 63 • Cloud providers must work together to ensure that the challenges to cloud 64 adoption are addressed through open collaboration and the appropriate use 65 of standards. 66 • Cloud providers must use and adopt existing standards wherever 67 appropriate. The IT industry has invested heavily in existing standards and 68 standards organizations; there is no need to duplicate or reinvent them. 31 July 2009 3
  4. 4. Cloud Computing Use Cases White Paper 69 • When new standards (or adjustments to existing standards) are needed, 70 we must be judicious and pragmatic to avoid creating too many standards. 71 We must ensure that standards promote innovation and do not inhibit it. 72 • Any community effort around the open cloud should be driven by customer 73 needs, not merely the technical needs of cloud providers, and should be 74 tested or verified against real customer requirements. 75 • Cloud computing standards organizations, advocacy groups, and 76 communities should work together and stay coordinated, making sure that 77 efforts do not conflict or overlap. 78 • Cloud providers must not use their market position to lock customers into 79 their particular platforms and limiting their choice of providers. 80 This paper is part of the ongoing effort to make these principles a reality. 31 July 2009 4
  5. 5. Cloud Computing Use Cases White Paper 81 2 Definitions and Taxonomy 82 The following definitions and taxonomy are included to provide an overview of 83 cloud computing concepts. However, the focus of this white paper is defining 84 cloud scenarios and use cases based on real-world applications and 85 requirements, not defining cloud computing itself. Our goal is to provide use case 86 scenarios that are clear, interesting and useful, regardless of how those 87 scenarios might be defined or placed into a taxonomy. 88 2.1 Definitions of Cloud Computing Concepts 89 Cloud Computing: Cloud computing is a model for enabling convenient, on- 90 demand network access to a shared pool of configurable computing resources 91 (e.g., networks, servers, storage, applications, and services) that can be rapidly 92 provisioned and released with minimal management effort or service provider 93 interaction. (This definition is from the latest draft of the NIST Working Definition 94 of Cloud Computing published by the U.S. Government's National Institute of 95 Standards and Technology 1 .) 96 2.1.1 Delivery Models 97 The NIST definition of cloud computing defines three delivery models: 98 • Software as a Service (SaaS): The consumer uses an application, but 99 does not control the operating system, hardware or network infrastructure 100 on which it's running. 101 • Platform as a Service (PaaS): The consumer uses a hosting environment 102 for their applications. The consumer controls the applications that run in the 103 environment (and possibly has some control over the hosting environment), 104 but does not control the operating system, hardware or network 105 infrastructure on which they are running. The platform is typically a virtual 106 machine, but it can also be an application framework. 107 • Infrastructure as a Service (IaaS): The consumer uses "fundamental 108 computing resources" such as processing power, storage, networking 109 components or middleware. The consumer can control the operating 110 system, storage, deployed applications and possibly networking 1 You can find the full document on the NIST Cloud Computing page at The document states, "This material is public domain although attribution to NIST is requested. It may be freely duplicated and translated." The essential characteristics, delivery models and deployment models discussed in this paper are based on Version 14 of the document, dated 6-1-09. 31 July 2009 5
  6. 6. Cloud Computing Use Cases White Paper 111 components such as firewalls and load balancers, but not the cloud 112 infrastructure beneath them. 113 2.1.2 Deployment Models 114 The NIST definition defines four deployment models: 115 • Public Cloud: In simple terms, public cloud services are characterized as 116 being available to clients from a third party service provider via the 117 Internet. The term “public” does not always mean free, even though it can 118 be free or fairly inexpensive to use. A public cloud does not mean that a 119 user’s data is publically visible; public cloud vendors typically provide an 120 access control mechanism for their users. Public clouds provide an elastic, 121 cost effective means to deploy solutions. 122 • Private Cloud: A private cloud offers many of the benefits of a public 123 cloud computing environment, such as being elastic and service based. 124 The difference between a private cloud and a public cloud is that in a 125 private cloud-based service, data and processes are managed within the 126 organization without the restrictions of network bandwidth, security 127 exposures and legal requirements that using public cloud services might 128 entail. In addition, private cloud services offer the provider and the user 129 greater control of the cloud infrastructure, improving security and 130 resiliency because user access and the networks used are restricted and 131 designated. 2 132 • Community Cloud: A community cloud is controlled and used by a group 133 of organizations that have shared interests, such as specific security 134 requirements or a common mission The members of the community share 135 access to the data and applications in the cloud. 136 • Hybrid Cloud: A hybrid cloud is a combination of a public and private 137 cloud that interoperates. In this model users typically outsource non- 138 business-critical information and processing to the public cloud, while 139 keeping business-critical services and data in their control. 3 140 2.1.3 Essential Characteristics 141 The NIST definition describes five essential characteristics of cloud computing. 2 A private cloud can be managed by a third party and can be physically located off premises. It is not necessarily managed and hosted by the organization that uses it. 3 A Hybrid Cloud is a superset of the technology used in a Community Cloud. For that reason, the requirements for the two deployment models are discussed together under the heading "Hybrid Cloud" in Section 3. 31 July 2009 6
  7. 7. Cloud Computing Use Cases White Paper 142 • Rapid Elasticity: Elasticity is defined as the ability to scale resources 143 both up and down as needed. To the consumer, the cloud appears to be 144 infinite, and the consumer can purchase as much or as little computing 145 power as they need. This is one of the essential characteristics of cloud 146 computing in the NIST definition. 147 • Measured Service: In a measured service, aspects of the cloud service 148 are controlled and monitored by the cloud provider. This is crucial for 149 billing, access control, resource optimization, capacity planning and other 150 tasks. 151 • On-Demand Self-Service: The on-demand and self-service aspects of 152 cloud computing mean that a consumer can use cloud services as needed 153 without any human interaction with the cloud provider. 154 • Ubiquitous Network Access: Ubiquitous network access means that the 155 cloud provider’s capabilities are available over the network and can be 156 accessed through standard mechanisms by both thick and thin clients. 4 157 • Location-Independent Resource Pooling: Resource pooling allows a 158 cloud provider to serve its consumers via a multi-tenant model. Physical 159 and virtual resources are assigned and reassigned according to consumer 160 demand. The location of the physical resources underneath the cloud 161 infrastructure is not known to the consumer, and can change 162 dynamically. 5 163 2.1.4 Other Terms 164 Interoperability: Interoperability is concerned with the ability of systems to 165 communicate. It requires that the communicated information is understood by the 166 receiving system. Interoperability is not concerned with whether the 167 communicating systems do anything sensible as a whole. 6 168 Integration: Integration is the process of combining components or systems into 169 an overall system. Integration among cloud-based components and systems can 4 This does not necessarily mean Internet access. By definition, a private cloud is accessible only behind a firewall. Regardless of the type of network, access to the cloud is typically not limited to a particular type of client. 5 In many cases privacy laws and other regulations require the cloud provider's resources to be in a particular location. The cloud provider and cloud consumer must work together to adhere to those regulations. 6 The definitions of interoperability, integration and portability are based on the work at 31 July 2009 7
  8. 8. Cloud Computing Use Cases White Paper 170 be complicated by issues such as multi-tenancy, federation and government 171 regulations. 172 Portability: Portability is the ability of moving components or systems between 173 environments. In the world of cloud computing, this includes software and 174 hardware environments (both physical and virtual). 175 Service Level Agreement (SLA): An SLA is contract between a provider and a 176 consumer that specifies consumer requirements and the provider’s commitment 177 to them. Typically an SLA includes items such as uptime, privacy, security and 178 backup procedures. 179 Federation: Federation is the act of combining data or identities across multiple 180 systems. Federation can be done by a cloud provider or by a cloud broker. 181 Broker: A broker has no cloud resources of its own, but matches consumers and 182 providers based on the SLA required by the consumer. The consumer has no 183 knowledge that the broker does not control the resources. 184 Multi-Tenancy: Multi-tenancy is the property of multiple systems, applications or 185 data from different enterprises hosted on the same physical hardware. Multi- 186 tenancy is common to most cloud-based systems. 187 Cloud bursting: Cloud bursting is a technique used by hybrid clouds to provide 188 additional resources to private clouds on an as-needed basis. If the private cloud 189 has the processing power to handle its workloads, the hybrid cloud is not used. 190 When workloads exceed the private cloud’s capacity, the hybrid cloud 191 automatically allocates additional resources to the private cloud. 192 Policy: A policy is a general term for an operating procedure. For example, a 193 security policy might specify that all requests to a particular cloud service must 194 be encrypted. 195 Governance: Governance refers to the controls and processes that make sure 196 policies are enforced. 197 Virtual Machine (VM): A file (typically called an image) that, when executed, 198 looks to the user like an actual machine. Platform as a Service is often provided 199 as a VM image that can be started or stopped as needed. Changes made to the 200 VM while it is running can be stored to disk to make them persistent. 31 July 2009 8
  9. 9. Cloud Computing Use Cases White Paper 201 2.2 Taxonomy 202 This diagram defines a taxonomy for cloud computing: 203 204 In this diagram, Service Consumers use the services provided through the cloud, 205 Service Providers manage the cloud infrastructure and Service Developers 206 create the services themselves. (Notice that open standards are needed for the 207 interactions between these roles.) Each role is discussed in more detail in the 208 following sections. 209 2.2.1 Service Consumer 211 The service consumer is the end user or enterprise that actually 213 uses the service, whether it is Software, Platform or Infrastructure as 215 a Service. 217 Depending on the type of service and their role, the consumer works 219 with different user interfaces and programming interfaces. Some 221 user interfaces look like any other application; the consumer does 223 not need to know about cloud computing as they use the application. 225 Other user interfaces provide administrative functions such as 227 starting and stopping virtual machines or managing cloud storage. 229 Consumers writing application code use different programming 231 interfaces depending on the application they are writing. 233 Consumers work with SLAs and contracts as well. Typically these 235 are negotiated via human intervention between the consumer and 237 the provider. The expectations of the consumer and the reputation of 31 July 2009 9
  10. 10. Cloud Computing Use Cases White Paper 238 the provider are a key part of those negotiations. 239 2.2.2 Service Provider 240 241 The service provider delivers the service to the consumer. The actual task of the 242 provider varies depending on the type of service: 243 • For Software as a Service, the provider installs, manages and maintains 244 the software. The provider does not necessarily own the physical 245 infrastructure in which the software is running. Regardless, the consumer 246 does not have access to the infrastructure; they can access only the 247 application. 248 • For Platform as a Service, the provider manages the cloud infrastructure for 249 the platform. In some cases that infrastructure is an environment for 250 running virtual machines; in others it is a framework for a particular type of 251 application. The consumer’s application cannot access the infrastructure 252 underneath the platform. 31 July 2009 10
  11. 11. Cloud Computing Use Cases White Paper 253 • For Infrastructure as a Service, the provider maintains the storage, 254 database, message queue or other middleware. The consumer uses that 255 service as if it were an ordinary disk drive, database or message queue, but 256 they cannot access the infrastructure that hosts it. 257 In the service provider diagram, the lowest layer of the stack is the firmware and 258 hardware on which everything else is based. Above that is the software kernel, 259 either the operating system or virtual machine manager that hosts the 260 infrastructure beneath the cloud. The virtualized resources and images include 261 the basic cloud computing services such as processing power, storage and 262 middleware. The virtual images controlled by the VM manager include both the 263 images themselves and the metadata required to manage them. 264 Crucial to the service provider’s operations is the management layer. At a low 265 level, management requires metering to determine who uses the services and to 266 what extent, provisioning to determine how resources are allocated to 267 consumers, and monitoring to track the status of the system and its resources. 268 At a higher level, management involves billing to recover costs, capacity planning 269 to ensure that consumer demands will be met, SLA management to ensure that 270 the terms of service agreed to by the provider and consumer are adhered to, and 271 reporting for administrators. 272 Security applies to all aspects of the service provider’s operations. (The many 273 levels of security requirements are beyond the scope of this paper.) Open 274 standards apply to the provider’s operations as well. A well-rounded set of 275 standards simplify operations within the provider and interoperability with other 276 providers. 277 2.2.3 Service Developer 279 The service developer creates, publishes and monitors the cloud 281 service. In most cases this is an application delivered via SaaS, 283 although a small number of developers create cloud middleware 285 (IaaS) and cloud platforms (PaaS). 287 Development environments for service creation vary. If 289 developers are creating a SaaS application, they are most likely 291 writing code for an environment hosted by a cloud provider. In 293 this case, publishing the service is deploying it to the cloud 295 provider’s infrastructure. 297 During service creation, analytics involve remote debugging to 299 test the service before it is published to consumers. Once the 301 service is published, analytics allow developers to monitor the 303 performance of their service and make changes as necessary. 31 July 2009 11
  12. 12. Cloud Computing Use Cases White Paper 304 2.3 Relationships Between Standards and Taxonomies 305 There are four different ways standards will affect cloud use case scenarios. 306 Standards will have an impact within each type of cloud service, across the 307 different types of cloud services, between the enterprise and the cloud, and 308 within the private cloud of an enterprise. 309 310 2.3.1 Standards Across Cloud Service Types 311 As cloud computing becomes more common, applications will likely use different 312 types of cloud services. An application might use a cloud storage service, a cloud 313 message queue, and manage (start/stop/monitor) virtual machines running in the 314 cloud. Standards to define how these different services work together could 315 provide value, although it's likely they will build on the work to define standards 316 within cloud service types. 317 2.3.2 Standards Within Cloud Service Types 318 Within each type of cloud service (IaaS, PaaS or SaaS), open standards make it 319 possible to avoid vendor lock-in. 31 July 2009 12
  13. 13. Cloud Computing Use Cases White Paper 320 For Infrastructure as a Service, a standard set of APIs to work with cloud 321 databases would allow applications to work with data from multiple vendors. That 322 common API would give users the freedom to move to another cloud database 323 provider without major changes, and it would make it much easier to integrate 324 new data sources with existing applications. Common APIs for other cloud 325 infrastructure services such as storage, message queues or Map Reduce would 326 provide similar benefits, as would common formats for data and data 327 interchange. 328 For Platform as a Service, many of the platforms provided in the cloud will be 329 virtual machines running instances of common operating systems. In those 330 cases, a common virtual machine format is crucial. Users should be able to take 331 a VM built and deployed with one cloud provider and deploy it to another cloud 332 provider without changes. 333 For Software as a Service, open standards apply at the application level. Very 334 little of the standards work here is cloud-specific, so those standards are beyond 335 the scope of this paper. For example, a cloud-based word processing application 336 should support standards for document portability; the requirement for standards 337 support in a word processing application has nothing to do with whether the 338 application is running in the cloud. 339 2.3.3 Standards Between the Cloud and the Enterprise 340 Even as cloud computing emerges, enterprise architectures such as Java EE are 341 not going away. Standards that define how an enterprise application 342 communicates with resources such as a cloud database or a cloud message 343 queue would enable those applications to use cloud services with little or no 344 changes. Figuring out how to integrate cloud computing with existing 345 architectures and development paradigms will be a major challenge for this 346 group. 347 2.3.4 Standards Within an Enterprise 348 Standards within an enterprise will be determined by requirements such as 349 auditability, security and management, and will build upon the standards that 350 apply between enterprises and the cloud. The enterprise will interact with some 351 combination of private, public and hybrid clouds. 31 July 2009 13
  14. 14. Cloud Computing Use Cases White Paper 352 3 Use Case Scenarios 353 The Enterprise Cloud Usage scenarios are intended to illustrate the most typical 354 cloud use cases and are not meant to be an exhaustive list of realizations within 355 a cloud environment. 356 End User to Applications running on the cloud Cloud and accessed by end users Enterprise to Applications running in the public Cloud to End cloud and accessed by employees User and customers Enterprise to Cloud applications integrated with Cloud internal IT capabilities 31 July 2009 14
  15. 15. Cloud Computing Use Cases White Paper Enterprise to Cloud applications running in the Cloud to public cloud and interoperating with Enterprise partner applications (supply chain) A cloud hosted by an organization Private Cloud inside that organization’s firewall. An organization using cloud services Changing decides to switch cloud providers or Cloud Vendors work with additional providers. Multiple clouds work together, coordinated by a cloud broker that Hybrid Cloud federates data, applications, user identity, security and other details. 357 Notice that the graphics in this section have common elements throughout. If a 358 given element does not apply to a particular use case, it is grayed out or drawn 359 with a dashed line. As an example, the Private Cloud use case does not involve 360 the End User or the Public Cloud, so only the Enterprise appears in color. 31 July 2009 15
  16. 16. Cloud Computing Use Cases White Paper 361 3.1 End User to Cloud 362 In this scenario, an end user is accessing data or applications in the cloud. 363 Common applications of this type include email hosting and social networking 364 sites. A user of Gmail, Facebook or LinkedIn accesses the application and their 365 data through any browser on any device. The user doesn’t want to keep up with 366 anything more than a password; their data is stored and managed in the cloud. 367 Most importantly, the user has no idea how the underlying architecture works. If 368 they can get to the Internet, they can get to their data. 369 370 3.1.1 Requirements 371 • Identity: The cloud service must authenticate the end user. 372 • An open client: Access to the cloud service should not require a particular 373 platform or technology. 374 • Security: Security is a common requirement to all use cases, although the 375 details of those requirements will vary widely from one use case to the next. 376 A full discussion of security in cloud computing is beyond the scope of this 377 paper. 31 July 2009 16
  17. 17. Cloud Computing Use Cases White Paper 378 • SLAs: Although service level agreements for end users will usually be 379 much simpler than those for enterprises, cloud vendors must be clear about 380 what guarantees of service they provide. 381 3.2 Enterprise to Cloud to End User 382 In this scenario, an enterprise is using the cloud to deliver data and services to 383 the end user. When the end user interacts with the enterprise, the enterprise 384 accesses the cloud to retrieve data and /or manipulate it, sending the results to 385 the end user. The end user can be someone within the enterprise or an external 386 customer. 387 388 3.2.1 Requirements 389 • Identity: The cloud service must authenticate the end user. 390 • An open client: Access to the cloud service should not require a particular 391 platform or technology. 392 • Federated identity: In addition to basic the identity needed by an end user, 393 an enterprise user is likely to have an identity with the enterprise. The ideal 394 is that the enterprise user manages a single ID, with an infrastructure 395 federating other identities that might be required by cloud services. 31 July 2009 17
  18. 18. Cloud Computing Use Cases White Paper 396 • Location awareness: Depending on the kind of data the enterprise is 397 managing on the user's behalf, there might be legal restrictions on the 398 location of the physical server where the data is stored. Although this 399 violates the cloud computing ideal that the user should not have to know 400 details of the physical infrastructure, this requirement is essential. Many 401 applications cannot be moved to the cloud until cloud vendors provide an 402 API for determining the location of the physical hardware that delivers the 403 cloud service. 404 • Metering and monitoring: All cloud services must be metered and 405 monitored for cost control, chargebacks and provisioning. 406 • Management and Governance: Public cloud providers make it very easy 407 to open an account and begin using cloud services; that ease of use 408 creates the risk that individuals in an enterprise will use cloud services on 409 their own initiative. For IaaS, management of VMs is the most important 410 requirement. Management of different PaaS cloud services (such as 411 storage, databases and message queues) is needed to track what services 412 are used. 413 414 Governance is crucial to ensure that policies and government regulations 415 are followed wherever cloud computing is used. Other governance 416 requirements will be industry- and geography-specific. 417 • Security: Any use case involving an enterprise will have more 418 sophisticated security requirements than one involving a single end user. 419 Similarly, the more advanced enterprise use cases to follow will have 420 equally more advanced security requirements. 421 • A Common File Format for VMs: A VM created for one cloud vendor’s 422 platform should be portable to another vendor’s platform. 423 • Common APIs for Cloud Storage and Middleware: The enterprise use 424 cases require common APIs for access to cloud storage services, cloud 425 databases, and other cloud middleware services such as message queues. 426 427 Writing custom code that works only for a particular vendor’s cloud service 428 locks the enterprise into that vendor’s system and eliminates some of the 429 financial benefits and flexibility that cloud computing provides. 430 • Data and Application Federation: Enterprise applications need to 431 combine data from multiple cloud-based sources, and they need to 432 coordinate the activities of applications running in different clouds. 433 • SLAs and Benchmarks: In addition to the basic SLAs required by end 434 users, enterprises who sign contracts based on SLAs will need a standard 435 way of benchmarking performance. There must be an unambiguous way of 31 July 2009 18
  19. 19. Cloud Computing Use Cases White Paper 436 defining what a cloud provider will deliver, and there must be an 437 unambiguous way of measuring what was actually delivered. 438 • Lifecycle Management: Enterprises must be able to manage the lifecycle 439 of applications and documents. This requirement includes versioning of 440 applications and the retention and destruction of data. Discovery is a major 441 issue for many organizations. There are substantial legal liabilities if certain 442 data is no longer available. In addition to data retention, in some cases an 443 enterprise will want to make sure data is destroyed at some point. 444 3.3 Enterprise to Cloud 445 This use case involves an enterprise using cloud services for its internal 446 processes. This might be the most common use case in the early stages of cloud 447 computing because it gives the enterprise the most control. 448 449 In this scenario, the enterprise uses cloud services to supplement the resources 450 it needs: 451 • Using cloud storage for backups or storage of seldom-used data 31 July 2009 19
  20. 20. Cloud Computing Use Cases White Paper 452 • Using virtual machines in the cloud to bring additional processors online to 453 handle peak loads (and, of course, shutting down those VMs when they're 454 not needed anymore) 455 • Using applications in the cloud (SaaS) for certain enterprise functions 456 (email, calendaring, CRM, etc.). 457 • Using cloud databases as part of an application's processing. This could be 458 extremely useful for sharing that database with partners, government 459 agencies, etc. 460 3.3.1 Requirements 461 The basic requirements of the Enterprise to Cloud use case are much the same 462 as those for the Enterprise to Cloud to End User use case. An open client, 463 federated identity, location awareness, metering and monitoring, 464 management and governance, security, a common file format for VMs, 465 common APIs for cloud storage and middleware, data and application 466 federation, SLAs and lifecycle management all apply. 467 Other requirements for this use case are: 468 • Deployment: It should be simple to build a VM image and deploy it to the 469 cloud as necessary. When that VM image is built, it should be possible to 470 move that image from one cloud provider to another. Deployment of 471 applications to the cloud should be straightforward as well. 472 • Industry-specific standards and protocols: Many cloud computing 473 solutions between enterprises will use existing standards such as 474 RosettaNet or OAGIS. The applicable standards will vary from one 475 application to the next and from one industry to the next. 476 3.4 Enterprise to Cloud to Enterprise 477 This use case involves two enterprises using the same cloud. The focus here is 478 hosting resources in the cloud so that applications from the enterprises can 479 interoperate. A supply chain is the most obvious example for this use case. 31 July 2009 20
  21. 21. Cloud Computing Use Cases White Paper 480 481 3.4.1 Requirements 482 The basic requirements of the Enterprise to Cloud to Enterprise use case are 483 much the same as those for the Enterprise to Cloud use case. Identity, an open 484 client, federated identity, location awareness, metering and monitoring, 485 management and governance, security, industry-specific standards, 486 common APIs for storage and middleware, data and application federation, 487 SLAs and lifecycle management all apply. 488 Other requirements for this use case are: 489 • Transactions and concurrency: For applications and data shared by 490 different enterprises, transactions and concurrency are vital. If two 491 enterprises are using the same cloud-hosted application, VM, middleware 31 July 2009 21
  22. 22. Cloud Computing Use Cases White Paper 492 or storage, it's important that any changes made by either enterprise are 493 done reliably. 494 • Interoperability: Because more than one enterprise is involved, 495 interoperability between the enterprises is essential. 496 3.5 Private Cloud 497 The Private Cloud use case is different from the others in that the cloud is 498 contained within the enterprise. This is useful for larger enterprises. For example, 499 if the payroll department has a surge in workload on the 15th and 30th of each 500 month, they need to buy enough computing power to handle the maximum 501 workload, even though their everyday workload for the rest of the month is much 502 lower. With a private cloud, computing power is spread across the enterprise. 503 The payroll department gets extra cycles when they need it and other 504 departments get extra cycles when they need it. This can deliver significant 505 savings across the enterprise. 506 507 3.5.1 Requirements 508 The basic requirements of the Private Cloud use case are an open client, 509 metering and monitoring, management and governance, security, 510 deployment, interoperability, a common VM format, and SLAs. 31 July 2009 22
  23. 23. Cloud Computing Use Cases White Paper 511 Note that a private cloud does not require identity, federated identity, location 512 awareness, transactions, industry standards, common APIs for cloud middleware 513 and lifecycle management. In many cases, consumers have to use a private 514 cloud so that location awareness will no longer be an issue. Keeping the cloud 515 inside the enterprise removes many of the requirements for identity 516 management, standards and common APIs. 517 3.6 Changing Cloud Vendors 518 This use case involves working with a different cloud vendor, either adding an 519 additional vendor or replacing an existing one. It applies to all of the other use 520 cases discussed in this paper. Being able to work with other vendors without 521 major changes is one of the main benefits of openness and standardization. 522 523 There are four different scenarios here, each of which has slightly different 524 requirements. In general, changing cloud vendors requires an open client, 525 location awareness, security, SLAs, a common file format for VMs and 526 common APIs for cloud storage and middleware. The details of those 527 requirements are discussed in each of the following subsections. 31 July 2009 23
  24. 24. Cloud Computing Use Cases White Paper 528 3.6.1 Scenario 1: Changing SaaS vendors 529 In this scenario a cloud customer changes SaaS vendors. Both SaaS vendors 530 provide the same application (CRM, accounting, word processing, etc.). 531 Documents and data created with one vendor's software should be importable by 532 the second vendor's software. In some cases, the customer might need to use 533 the two vendors interchangeably. 534 Requirements 535 • Industry-specific standards: Moving documents and data from one 536 vendor’s application to another requires both applications to support 537 common formats. The formats involved will depend on the type of 538 application. 539 540 In some cases, standard APIs for different application types will also be 541 required. 542 It is important to note that there is nothing cloud-specific to these requirements. 543 The standards for moving a document from Zoho to Google Docs, are the same 544 standards for moving a document from Microsoft Office to OpenOffice. 545 3.6.2 Scenario 2: Changing middleware vendors 546 In this scenario a cloud customer changes cloud middleware vendors. Existing 547 data, queries, message queues and applications must be exportable from one 548 vendor and importable by the other. 7 549 Requirements 550 • Industry-specific standards: Moving documents and data from one 551 vendor’s middleware to another requires both applications to support 552 common formats. The formats involved will depend on the type of 553 application. 554 • Common APIs for Cloud Middleware: This includes all of the operations 555 supported by today’s cloud services, including cloud databases, cloud 556 message queues and other middleware. APIs for connecting to, creating 557 and dropping databases and tables. 558 559 Cloud database vendors have enforced certain restrictions to make their 560 products more scalable and to limit the possibility of queries against large 7 Because of the popularity of cloud storage, cloud middleware (databases, message queues, Map Reduce) and cloud storage are considered separate scenarios, even though both are classified as PaaS. 31 July 2009 24
  25. 25. Cloud Computing Use Cases White Paper 561 data sets taking significant resources to process. For example, some cloud 562 databases don't allow joins across tables, and some don't support a true 563 database schema. Those restrictions are a major challenge to moving 564 between cloud database vendors, especially for applications built on a true 565 relational model. 566 567 Other middleware services such as message queues are more similar, so 568 finding common ground among them should be simpler. 569 3.6.3 Scenario 3: Changing cloud storage vendors 570 In this scenario a cloud customer changes cloud storage vendors. 571 Requirements 572 • A Common API for Cloud Storage: Code that reads or writes data in one 573 cloud storage system should work with a different system with as few 574 changes as possible; those changes should be confined to configuration 575 code. In a JDBC application, as an example, the format of the URL and the 576 driver name are different for different database vendors, but the code to 577 interact with the database is identical. 578 3.6.4 Scenario 4: Changing VM hosts 579 In this scenario a cloud customer wants to take virtual machines built on one 580 cloud vendor's system and run it on another cloud vendor's system. 581 Requirements 582 • A common format for virtual machines. The VM format should work with 583 any operating system. 584 585 The assumption here is that the virtual machines themselves are running 586 an operating system such as Windows or Linux. This means that the user 587 of the virtual machine has chosen a platform prior to building a VM for the 588 cloud, so there are no cloud-specific requirements for the software running 589 inside the VM. 590 3.7 Hybrid Cloud 591 This use case involves multiple clouds working together, including both public 592 and private clouds. A hybrid cloud can be delivered by a federated cloud provider 593 that combines its own resources with those of other providers. A broker can also 594 deliver a hybrid cloud; the difference is that a broker does not have any cloud 595 resources of its own. The provider of the hybrid cloud must manage cloud 596 resources based on the consumer’s terms. 31 July 2009 25
  26. 26. Cloud Computing Use Cases White Paper 597 598 It is important to note that to the consumer of a hybrid cloud, this use case is no 599 different from the End User to Cloud use case discussed earlier. The user has no 600 knowledge of what the hybrid cloud provider actually does. 601 3.7.1 Requirements 602 • All of the requirements of the previous use cases (except Transactions 603 and concurrency) apply here, particularly Security, Data and Application 604 Federation and Interoperability. 605 • SLAs: A machine readable, standard format for expressing an SLA. This 606 allows the hybrid cloud provider to select resources according to the 607 consumer’s terms without human intervention. 608 As mentioned in Section 2, the requirements for a community cloud are a subset 609 of the requirements for the hybrid cloud. A community cloud has an infrastructure 610 shared among enterprises with a common purpose. Here is the diagram for a 611 community cloud: 31 July 2009 26
  27. 27. Cloud Computing Use Cases White Paper 612 613 Notice that the communication between the community and the community cloud 614 is done across an intranet. This could be a VPN, but access is not via the public 615 Internet. 616 The following table summarizes the requirements for all of the use cases: 617 End User to to Cloud to to Cloud to Enterprise Enterprise Enterprise Enterprise Changing End User to Cloud Vendors Private Hybrid Cloud Cloud Cloud Cloud Requirement Identity Open Client Federated Identity Location Awareness Metering and Monitoring Management and Governance 31 July 2009 27
  28. 28. Cloud Computing Use Cases White Paper End User to to Cloud to to Cloud to Enterprise Enterprise Enterprise Enterprise Changing End User to Cloud Vendors Private Hybrid Cloud Cloud Cloud Cloud Requirement Security Deployment Transactions and Concurrency Interoperability Industry- Specific Standards VM Image Format Cloud Storage API Cloud Database API Cloud Middleware API Data and Application Federation SLAs Lifecycle Management 31 July 2009 28
  29. 29. Cloud Computing Use Cases White Paper 618 4 Customer Scenarios 619 This section describes customer experiences with the use cases. Here is a 620 summary of those customer scenarios: 621 Customer Requirements Applicable Customer Problem Solved Scenario & Capabilities Use Case Payroll • Processing time reduced PaaS (VMs), Enterprise to Processing • Hardware requirements cloud storage Cloud reduced • Scalability enabled for future expansion Logistics & • Processing time reduced PaaS (app Enterprise to Project • Manual tasks eliminated framework), Cloud to End Management • Development environment cloud storage User updated and streamlined Central • IT expertise consolidated IaaS, PaaS Private Government • Hardware requirements Cloud reduced Local • IT expertise consolidated IaaS, PaaS Hybrid Cloud Government • Hardware requirements reduced Astronomic • Hardware expense greatly PaaS (VMs), Enterprise to Data reduced (processing cloud storage Cloud to End Processing power and storage) User • Energy costs greatly reduced • Administration simplified 622 4.1 Customer Scenario: Payroll Processing in the Cloud 623 4.1.1 Applicable Use Case Scenario from Section 3: 624 Enterprise to Cloud 31 July 2009 29
  30. 30. Cloud Computing Use Cases White Paper 625 4.1.2 Customer scenario: 626 In this scenario, two servers were dedicated to payroll processing, a complex and 627 time-consuming process. The organization decided to see how practical it would 628 be to run the payroll process in the cloud. The existing payroll system was 629 architected as a distributed application, so moving it to the cloud was relatively 630 straightforward. 631 The payroll application used an SQL database for processing employee data. 632 Instead of rewriting the application to use a cloud database service, a VM with a 633 database server was deployed. The database server retrieved data from a cloud 634 storage system and constructed relational tables from it. Because of the size of 635 the original (in-house) database, extraction tools were used to select only the 636 information necessary for payroll processing. That extracted information was 637 transferred to a cloud storage service and then used by the database server. 638 The payroll application was deployed to four VMs that run simultaneously; those 639 four VMs work with the VM hosting the database server. The configuration of the 640 payroll application was changed to use the VM hosting the database server; 641 otherwise the application was not changed. 642 4.1.3 Customer problem solved: 643 In the cloud-based version of the application, processing time for the payroll task 644 was reduced by 80%. As an added benefit, two servers formerly dedicated to 645 processing payroll were freed up for other tasks. Finally, the cloud-based version 646 is much more scalable; that will be a significant advantage as the organization 647 expands. 648 4.1.4 Requirements and Capabilities: 649 The cloud services used were virtual machines (PaaS) and cloud storage (IaaS). 650 The payroll application did not have to be modified, it was simply deployed to the 651 virtual machine. The original application used a relational database. To avoid 652 changing data structures and applications to use a cloud database, a relational 653 database server was deployed into the cloud. 654 The only API used was the S3 cloud storage API. 655 4.1.5 Portability Concerns: 656 The payroll application runs on Fedora and Java 1.5, so it will run without 657 changes on any cloud provider's platform that supports Fedora. Modifying the 658 application to use a different cloud storage provider could be a problem if the 659 other vendor doesn't support the specific S3 APIs used in the payroll process. 660 Finally, changing the application to use a cloud database could be extremely 31 July 2009 30
  31. 31. Cloud Computing Use Cases White Paper 661 difficult, particularly if it involved moving to a cloud database that does not 662 support the relational model. 663 4.2 Customer Scenario: Logistics and Project Management in 664 the Cloud 665 4.2.1 Applicable Use Case Scenario from Section 3: 666 Enterprise to Cloud to End User 667 4.2.2 Customer scenario: 668 A small construction company with approximately 20 administrative employees 669 needed a way to manage their resources, optimize project scheduling and track 670 job costs. The company had very specific requirements that no commonly 671 available system addressed, so they used a combination of Quickbooks and 672 spreadsheets. This system was not scalable and was a huge waste of human 673 resources. 674 The solution to the problem was to build a custom client-side application. All of 675 the business logic resides on the client. Data for the application is served from a 676 Google App Engine (GAE) datastore. The datastore does not enforce any sort of 677 schema other than an RDF graph, although it does host an RDF-OWL ontology. 678 The client uses that ontology to validate data before displaying it to the user or 679 sending it back to the GAE. 680 Data operations are communicated with the datastore using an application- 681 specific RESTful protocol over HTTP. The datastore maintains RDF graphs 682 specific to the applications it is serving within silos managed on the server. 683 Security is implemented separately for each silo depending on the requirements 684 of the application using a particular silo of data. Using this system, any number of 685 applications can use the datastore without building a new code base for each 686 one. 687 Data was moved into the datastore on GAE from the locally hosted Quickbooks 688 SQL server and the custom spreadsheets using a one-time data migration script 689 that reconciled the data before uploading it to the GAE datastore. The data set 690 was small and easily processed using local resources. 691 The client application maintains a local datastore that contains a subset of the 692 most recent changes to the data. The REST architecture of the application allows 693 HTTP’s built-in caching support to automatically propagate changes to the 694 master datastore down to the client. In addition to the performance benefits of 695 using a subset of the data, this design simplifies security. If a client application 696 does not need to access to certain fields or records, that portion of the datastore 697 never leaves the server. 31 July 2009 31
  32. 32. Cloud Computing Use Cases White Paper 698 4.2.3 Customer problem solved: 699 Data was moved from an inefficient system of software and spreadsheet macros 700 into a cloud-based system. The resulting datastore can be used by a wide range 701 of applications, making future development and maintenance much simpler. 702 Although the original application infrastructure is still in use, the applications built 703 on that infrastructure no longer rely on spreadsheets to analyze and manipulate 704 the data. Significant savings will come from the fact that maintaining the 705 spreadsheets will no longer be necessary. In addition, cutting and pasting data 706 by hand is no longer part of the process, removing a tedious task and eliminating 707 a source of errors. 708 4.2.4 Requirements and Capabilities: 709 The cloud service used the Google App Engine, a PaaS implementation that 710 provides database support. The combination of a RESTful API and the cloud 711 datastore made the application more scalable than an application built around a 712 traditional relational database. 713 4.2.5 Portability Concerns: 714 The application runs on the Google App Engine and its Big Table database. Big 715 Table is a sparse, distributed, persistent, multi-dimensional sorted map that 716 achieves scalability by prioritizing denormalization over normalization. This is a 717 significant difference from most datastores, and requires a fundamental 718 rethinking of application development. Porting the application to run on top of a 719 more traditional datastore would require major changes to the application’s 720 architecture. 721 4.3 Customer Scenario: Central Government Services in the 722 Cloud 723 4.3.1 Applicable Use Case Scenario from Section 3: 724 Private Cloud 725 4.3.2 Customer scenario: 726 The ministries of the Japanese Government have thousands of servers across 727 their infrastructures. The central government has announced a private 728 “Kasumigaseki” cloud environment to provide a secure, centralized infrastructure 729 for hosting government applications. 730 Existing back office systems, such as payroll, accounting and personnel 731 management, will be virtualized and hosted in the private cloud. (Some front 732 office systems, such as electronic procurement, will be virtualized to a public 31 July 2009 32
  33. 33. Cloud Computing Use Cases White Paper 733 cloud, but that is outside the scope of this project.) The ultimate goal of the 734 project is to reduce the total cost of ownership by eliminating redundant systems 735 and the need for administrators in each ministry. 736 4.3.3 Customer problem solved: 737 The three problems solved by the Kasumigaseki cloud are reduced costs, 738 reduced energy consumption and reduced IT staff. 739 4.3.4 Requirements and Capabilities: 740 The cloud infrastructure will be built on a private network built by Japanese 741 telecommunications companies. Because privacy and security are major 742 concerns, a private cloud is required. It is illegal for many types of personal data 743 to be stored on a server outside of Japan. 744 4.3.5 Portability Concerns: 745 Because the government is building its own private cloud to host its own 746 applications, portability is not a concern. The government has no intention of 747 moving its centralized applications and data from the private cloud to a public 748 one. 749 4.4 Customer Scenario: Local Government Services in a Hybrid 750 Cloud 751 4.4.1 Applicable Use Case Scenario from Section 3: 752 Hybrid Cloud 753 4.4.2 Customer scenario: 754 There are more than 1800 local governments across Japan, each of which has 755 its own servers and IT staff. A secondary goal of the Kasumigaseki cloud is to 756 provide a hybrid cloud environment. Some local data will be stored in the 757 government’s private cloud, while other data will be stored locally. Wherever 758 possible, existing systems will be virtualized and hosted in the private cloud. 759 4.4.3 Customer problem solved: 760 The three problems solved by the hybrid cloud are reduced costs, reduced 761 energy consumption and reduced IT staff. 762 4.4.4 Requirements and Capabilities: 763 Privacy and security are crucial in this scenario. Japanese law prevents some 764 types of data from being stored outside the local government’s servers, so 31 July 2009 33
  34. 34. Cloud Computing Use Cases White Paper 765 moving applications and data into the Kasumigaseki cloud is not an option. 766 Because some processing will be on the local government’s infrastructure, 767 federation of applications and data inside the hybrid cloud is crucial 768 4.4.5 Portability Concerns: 769 As with the previous customer scenario, portability is not a concern because the 770 government is building its own private cloud. The government has no intention of 771 moving its centralized applications and data from the private cloud to a public 772 one. 773 4.5 Customer Scenario: Astronomic Data Processing 774 4.5.1 Applicable Use Case Scenario from Section 3: 775 End User to Cloud 776 4.5.2 Customer Scenario: 777 Gaia 8 is a mission of the European Space Agency that will conduct a survey of 778 one billion stars in our galaxy. It will monitor each of its target stars about 70 779 times over a five-year period, precisely charting their positions, distances, 780 movements, and changes in brightness. It is expected to discover hundreds of 781 thousands of new celestial objects, such as extra-solar planets and failed stars 782 called brown dwarfs. 783 This mission will collect a large amount of data that must be analyzed. The ESA 784 decided to prototype a cloud-based system to analyze the data. The goals were 785 to determine the technical and financial aspects of using cloud computing to 786 process massive datasets. 787 The prototype system contains the scientific data and a whiteboard used to 788 publish compute jobs. A framework for distributed computing (developed in 789 house) is used for job execution and data processing. The framework is 790 configured to run AGIS (Astrometric Global Iterative Solution). The process runs 791 a number of iterations over the data until it converges. 792 For processing, each working node gets a job description from the database, 793 retrieves the data, processes it and sends the results to intermediate servers. 794 The intermediate servers update the data for the following iteration. 795 The prototype evaluated 5 years of data for 2 million stars, a small fraction of the 796 total data that must be processed in the actual project. The prototype went 8 See for an overview of the project. 31 July 2009 34
  35. 35. Cloud Computing Use Cases White Paper 797 through 24 iterations of 100 minutes each, equivalent to running a grid of 20 VMs 798 for 40 hours. For the full billion-star project, 100 million primary stars will be 799 analyzed along with 6 years of data, which will require running the 20 VM cluster 800 for 16,200 hours. 801 To evaluate the scalability of a cloud-based solution, the prototype ran a second 802 test with 120 high CPU extra large VMs. With VM running 12 threads, there were 803 1440 processes working in parallel. 804 4.5.3 Customer Problem Solved: 805 The estimated cost for the cloud-based solution is less than half the cost of an in- 806 house solution. That cost estimate does not include the additional electricity or 807 system administration costs of an in-house solution, so the actual savings will be 808 even greater. Storage of the datasets will be cloud-based as well. 809 In the second test, a couple of performance problems with SQL queries and lock 810 contention at the database were detected and solved. These problems could not 811 have been detected with the current in-house system. The prototype allowed the 812 organization to find and solve performance and scalability problems before going 813 to production. 814 4.5.4 Requirements and Capabilities: 815 The prototype used VMs for the AGIS software and the database. The database 816 is a traditional database running inside a VM; it is a full relational database, not a 817 cloud database service. For storage, five cloud-based storage volumes (100GB 818 each) were attached to the database VM. 819 4.5.5 Portability Concerns: 820 All of the VMs are running standard operating systems and none of the software 821 used in the project is cloud-specific. The portability concern for this application 822 would be the ability to migrate those VM images to another provider without 823 having to rebuild or reconfigure the images. 31 July 2009 35
  36. 36. Cloud Computing Use Cases White Paper 824 5 Conclusions and Recommendations 825 Cloud computing builds on and complements many trends in the industry, 826 including virtualization, SOA and Web 2.0. As a result, standards already exist for 827 many of the requirements outlined in this paper. As we go forward, we will work 828 together as a community to specify the existing standards that meet customer 829 needs, leverage standards work already in progress, and identify what is needed 830 to fill in the gaps not addressed by existing standards. 831 This paper was created by an open Web community of more than 750 832 participants. The initial group consisted of supporters from the Open Cloud 833 Manifesto, but it quickly grew to include many other individuals around the world. 834 The community included representatives from large and small companies, 835 government agencies, consultants and vendors. 836 As the paper was developed, three principles from the manifesto were crucial: 837 1) users should work together, 2) activities to keep the cloud open should be 838 customer driven and 3) existing standards should be used wherever possible. 839 This paper is validation that those principles work, and they will be central to any 840 follow-on work. 841 The use cases described here demonstrate the following general requirements: 842 • Common VM Formats, Data Formats and APIs: Virtual machines, data 843 and applications created for one cloud provider should run on another cloud 844 provider without changes. 845 • Cloud Management: Cloud computing is not feasible without service 846 management, governance, metering, monitoring, federated identity, SLAs 847 and benchmarks, data and application federation, deployment, and lifecycle 848 management. These requirements are defined in Section 3. 849 • Security: Security in cloud computing is vital, although the requirements for 850 security will vary widely depending on the application and data types. 851 • Location awareness: A way of identifying the location of the physical 852 machine hosting the cloud infrastructure is an absolute requirement for 853 many government regulations. 854 It must be possible for consumers to implement any of the use cases outlined 855 here without resorting to closed, proprietary solutions that lead to vendor lock-in. 856 Where existing standards meet requirements, we must ensure those standards 857 are implemented pervasively and correctly. Where existing standards do not 858 meet requirements, we must define and implement the standards needed to 859 meet them. This community-written paper is meant to be the reference for 860 establishing a truly open cloud computing environment. 31 July 2009 36