The Enterprise Cloud Usage scenarios are intended to illustrate the most typical cloud use cases and are not meant to be an exhaustive list of realizations within a cloud environment.
The graphics in this section have common elements throughout. If a given element does not apply to a particular use case, it is grayed out or drawn with a dashed line. As an example, the Private Cloud use case does not involve the End User or the Public Cloud, so only the Enterprise appears in color.
| End User to | Applications running on the cloud and accessed by end users |  |
| Enterprise to | Applications running in the public cloud and accessed by employees and customers |  |
| Enterprise to | Cloud applications integrated with internal IT capabilities |  |
| Enterprise to | Cloud applications running in the public cloud and interoperating with partner applications (supply chain) |  |
| Private Cloud | A cloud hosted by an organization Inside that organization’s firewall. |  |
| Changing | An organization using cloud services decides to switch cloud providers or work with additional providers. |  |
| Hybrid Cloud | Multiple clouds work together, coordinated by a cloud broker that federates data, applications, user identity, security and other details. |  |
1. End User to Cloud:
In this scenario, an end user is accessing data or applications in the cloud. Common applications of this type include email hosting and social networking sites. A user of Gmail, Facebook or LinkedIn accesses the application and their data through any browser on any device. The user doesn’t want to keep up with anything more than a password; their data is stored and managed in the cloud. Most importantly, the user has no idea how the underlying architecture works. If they can get to the Internet, they can get to their data.
1.1 Requirements
• Identity: The cloud service must authenticate the end user.
• An open client: Access to the cloud service should not require a particular platform or technology.
• Security: Security (including privacy) is a common requirement to all use cases, although the details of those requirements will vary widely from one use case to the next. A full discussion of security in cloud computing is
beyond the scope of this paper.
• SLAs: Although service level agreements for end users will usually be much simpler than those for enterprises, cloud vendors must be clear about what guarantees of service they provide.
2. Enterprise to Cloud to End User:
In this scenario, an enterprise is using the cloud to deliver data and services to the end user. When the end user interacts with the enterprise, the enterprise accesses the cloud to retrieve data and / or manipulate it, sending the results to the end user. The end user can be someone within the enterprise or an external customer.
2.1 Requirements
• Identity: The cloud service must authenticate the end user.
• An open client: Access to the cloud service should not require a particular platform or technology.
• Federated identity: In addition to basic the identity needed by an end user, an enterprise user is likely to have an identity with the enterprise. The ideal is that the enterprise user manages a single ID, with an infrastructure federating other identities that might be required by cloud services.
• Location awareness: Depending on the kind of data the enterprise is managing on the user's behalf, there might be legal restrictions on the location of the physical server where the data is stored. Although this violates the cloud computing ideal that the user should not have to know details of the physical infrastructure, this requirement is essential. Many applications cannot be moved to the cloud until cloud vendors provide an API for determining the location of the physical hardware that delivers the cloud service.
•Metering and monitoring: All cloud services must be metered andmonitored for cost control, chargebacks and provisioning.
• Management and Governance: Public cloud providers make it very easy to open an account and begin using cloud services; that ease of use creates the risk that individuals in an enterprise will use cloud services on their own initiative. Management of VMs and of cloud services such as storage, databases and message queues is needed to track what services are used. Governance is crucial to ensure that policies and government regulations are followed wherever cloud computing is used. Other governance requirements will be industry- and geography-specific.
• Security: Any use case involving an enterprise will have more sophisticated security requirements than one involving a single end user. Similarly, the more advanced enterprise use cases to follow will have equally more advanced security requirements.
• A Common File Format for VMs: A VM created for one cloud vendor’s platform should be portable to another vendor’s platform. Any solution to this requirement must account for differences in the ways cloud vendors attach storage to virtual machines.
• Common APIs for Cloud Storage and Middleware: The enterprise use cases require common APIs for access to cloud storage services, cloud databases, and other cloud middleware services such as message queues. Writing custom code that works only for a particular vendor’s cloud service locks the enterprise into that vendor’s system and eliminates some of the financial benefits and flexibility that cloud computing provides.
• Data and Application Federation: Enterprise applications need to combine data from multiple cloud-based sources, and they need to coordinate the activities of applications running in different clouds.
• SLAs and Benchmarks: In addition to the basic SLAs required by end users, enterprises who sign contracts based on SLAs will need a standard way of benchmarking performance. There must be an unambiguous way of defining what a cloud provider will deliver, and there must be an unambiguous way of measuring what was actually delivered. (SLAs have additional implications for cloud security; see the discussions of SLAs, auditing and monitoring in Section 6 for more information.)
• Lifecycle Management: Enterprises must be able to manage the lifecycle of applications and documents. This requirement includes versioning of applications and the retention and destruction of data. Discovery is a major issue for many organizations. There are substantial legal liabilities if certain data is no longer available. In addition to data retention, in some cases an enterprise will want to make sure data is destroyed at some point.
3 Enterprise to Cloud
This use case involves an enterprise using cloud services for its internal processes. This might be the most common use case in the early stages of cloud computing because it gives the enterprise the most control. This use case involves an enterprise using cloud services for its internal processes. This might be the most common use case in the early stages of cloud computing because it gives the enterprise the most control.
In this scenario, the enterprise uses cloud services to supplement the resources it needs:
• Using cloud storage for backups or storage of seldom-used data
• Using virtual machines in the cloud to bring additional processors online to handle peak loads (and, of course, shutting down those VMs when they're not needed anymore)
• Using applications in the cloud (SaaS) for certain enterprise functions (email, calendaring, CRM, etc.).
• Using cloud databases as part of an application's processing. This could be extremely useful for sharing that database with partners, government agencies, etc.
3.1 Requirements
The basic requirements of the Enterprise to Cloud use case are much the same as those for the Enterprise to Cloud to End User use case. An open client, federated identity, location awareness, metering and monitoring, management and governance, security, a common file format for VMs,
common APIs for cloud storage and middleware, data and application federation, SLAs and lifecycle management all apply.
Other requirements for this use case are:
• Deployment: It should be simple to build a VM image and deploy it to the cloud as necessary. When that VM image is built, it should be possible to move that image from one cloud provider to another, compensating for the different mechanisms vendors have for attaching storage to VMs. Deployment of applications to the cloud should be straightforward as well.
• Industry-specific standards and protocols: Many cloud computing solutions between enterprises will use existing standards such as RosettaNet or OAGIS. The applicable standards will vary from one application to the next and from one industry to the next.
4 Enterprise to Cloud to Enterprise
This use case involves two enterprises using the same cloud. The focus here is hosting resources in the cloud so that applications from the enterprises can interoperate. A supply chain is the most obvious example for this use case.
4.1 Requirements
The basic requirements of the Enterprise to Cloud to Enterprise use case are much the same as those for the Enterprise to Cloud use case. Identity, an open client, federated identity, location awareness, metering and monitoring, management and governance, security, industry-specific standards, common APIs for storage and middleware, data and application federation, SLAs and lifecycle management all apply.
Other requirements for this use case are:
• Transactions and concurrency: For applications and data shared by different enterprises, transactions and concurrency are vital. If two enterprises are using the same cloud-hosted application, VM, middleware or storage, it's important that any changes made by either enterprise are done reliably.
• Interoperability: Because more than one enterprise is involved, interoperability between the enterprises is essential.
5 Private Cloud
The Private Cloud use case is different from the others in that the cloud is contained within the enterprise. This is useful for larger enterprises. For example, if the payroll department has a surge in workload on the 15th and 30th of each month, they need enough computing power to handle the maximum workload, even though their everyday workload for the rest of the month is much lower. With a private cloud, computing power is spread across the enterprise. The payroll department gets extra cycles when they need it and other departments get extra cycles when they need it. This can deliver significant savings across the enterprise.
5.1 Requirements
The basic requirements of the Private Cloud use case are an open client, metering and monitoring, management and governance, security, deployment, interoperability, a common VM format, and SLAs.
Note that a private cloud does not require identity, federated identity, location awareness, transactions, industry standards, common APIs for cloud middleware and lifecycle management. In many cases, consumers have to use a private cloud so that location awareness will no longer be an issue. Keeping the cloud inside the enterprise removes many of the requirements for identity management, standards and common APIs.
6 Changing Cloud Vendors
This use case involves working with a different cloud vendor, either adding an additional vendor or replacing an existing one. It applies to all of the other use cases discussed in this paper. Being able to work with other vendors without major changes is one of the main benefits of openness and standardization. There are four different scenarios here, each of which has slightly different
requirements. In general, changing cloud vendors requires an open client, location awareness, security, SLAs, a common file format for VMs and common APIs for cloud storage and middleware. The details of those requirements are discussed in each of the following subsections.
6.1 Scenario 1: Changing SaaS vendors
In this scenario a cloud customer changes SaaS vendors. Both SaaS vendors provide the same application (CRM, accounting, word processing, etc.). Documents and data created with one vendor's software should be importable by the second vendor's software. In some cases, the customer might need to use the two vendors interchangeably.
6.1.1 Requirements
• Industry-specific standards: Moving documents and data from one vendor’s application to another requires both applications to support common formats. The formats involved will depend on the type of application.
In some cases, standard APIs for different application types will also be required. It is important to note that there is nothing cloud-specific to these requirements. The standards for moving a document from Zoho to Google Docs are the same standards for moving a document from Microsoft Office to OpenOffice.
6.2 Scenario 2: Changing middleware vendors
In this scenario a cloud customer changes cloud middleware vendors. Existing data, queries, message queues and applications must be exportable from one vendor and importable by the other.
6.2.1 Requirements
• Industry-specific standards: Moving documents and data from one vendor’s middleware to another requires both applications to support common formats. The formats involved will depend on the type of application.
• Common APIs for Cloud Middleware: This includes all of the operations supported by today’s cloud services, including cloud databases, cloud message queues and other middleware. APIs for connecting to, creating and dropping databases and tables. Cloud database vendors have enforced certain restrictions to make their products more elastic and to limit the possibility of queries against large data sets taking significant resources to process. For example, some cloud databases don't allow joins across tables, and some don't support a true database schema. Those restrictions are a major challenge to moving between cloud database vendors, especially for applications built on a true relational model.
Other middleware services such as message queues are more similar, so finding common ground among them should be simpler.
6.3 Scenario 3: Changing cloud storage vendors
In this scenario a cloud customer changes cloud storage vendors.
6.3.1 Requirements
• A Common API for Cloud Storage: Code that reads or writes data in one cloud storage system should work with a different system with as few changes as possible; those changes should be confined to configuration code. In a JDBC application, as an example, the format of the URL and the driver name are different for different database vendors, but the code to interact with the database is identical.
6.4 Scenario 4: Changing VM hosts
In this scenario a cloud customer wants to take virtual machines built on one cloud vendor's system and run it on another cloud vendor's system.
6.4.1 Requirements
• A common format for virtual machines: The VM format should work with any operating system. The assumption here is that the virtual machines themselves are running an operating system such as Windows or Linux. This means that the user of the virtual machine has chosen a platform prior to building a VM for the cloud, so there are no cloud-specific requirements for the software running inside the VM.
7 Hybrid Cloud
This use case involves multiple clouds working together, including both public and private clouds. A hybrid cloud can be delivered by a federated cloud provider that combines its own resources with those of other providers. A broker can also deliver a hybrid cloud; the difference is that a broker does not have any cloud resources of its own. The provider of the hybrid cloud must manage cloud resources based on the consumer’s terms.
It is important to note that to the consumer of a hybrid cloud, this use case is no different from the End User to Cloud use case discussed earlier. The user has no knowledge of what the hybrid cloud provider actually does.
7.1 Requirements
• All of the requirements of the previous use cases (except Transactions and concurrency) apply here, particularly Security, Data and Application Federation and Interoperability.
• SLAs: A machine readable, standard format for expressing an SLA. This allows the hybrid cloud provider to select resources according to the consumer’s terms without human intervention.
As mentioned in Section 2, the requirements for a community cloud are a subset of the requirements for the hybrid cloud. A community cloud has an infrastructure shared among enterprises with a common purpose. Here is the diagram for a community cloud:
Notice that the communication between the community and the community cloud is done across an intranet. This could be a VPN, but access is not via the public Internet.
• An open client: Access to the cloud service should not require a particular platform or technology.
• Security: Security (including privacy) is a common requirement to all use cases, although the details of those requirements will vary widely from one use case to the next. A full discussion of security in cloud computing is
beyond the scope of this paper.
• SLAs: Although service level agreements for end users will usually be much simpler than those for enterprises, cloud vendors must be clear about what guarantees of service they provide.
2. Enterprise to Cloud to End User:
In this scenario, an enterprise is using the cloud to deliver data and services to the end user. When the end user interacts with the enterprise, the enterprise accesses the cloud to retrieve data and / or manipulate it, sending the results to the end user. The end user can be someone within the enterprise or an external customer.
2.1 Requirements
• Identity: The cloud service must authenticate the end user.
• An open client: Access to the cloud service should not require a particular platform or technology.
• Federated identity: In addition to basic the identity needed by an end user, an enterprise user is likely to have an identity with the enterprise. The ideal is that the enterprise user manages a single ID, with an infrastructure federating other identities that might be required by cloud services.
• Location awareness: Depending on the kind of data the enterprise is managing on the user's behalf, there might be legal restrictions on the location of the physical server where the data is stored. Although this violates the cloud computing ideal that the user should not have to know details of the physical infrastructure, this requirement is essential. Many applications cannot be moved to the cloud until cloud vendors provide an API for determining the location of the physical hardware that delivers the cloud service.
•Metering and monitoring: All cloud services must be metered andmonitored for cost control, chargebacks and provisioning.
• Management and Governance: Public cloud providers make it very easy to open an account and begin using cloud services; that ease of use creates the risk that individuals in an enterprise will use cloud services on their own initiative. Management of VMs and of cloud services such as storage, databases and message queues is needed to track what services are used. Governance is crucial to ensure that policies and government regulations are followed wherever cloud computing is used. Other governance requirements will be industry- and geography-specific.
• Security: Any use case involving an enterprise will have more sophisticated security requirements than one involving a single end user. Similarly, the more advanced enterprise use cases to follow will have equally more advanced security requirements.
• A Common File Format for VMs: A VM created for one cloud vendor’s platform should be portable to another vendor’s platform. Any solution to this requirement must account for differences in the ways cloud vendors attach storage to virtual machines.
• Common APIs for Cloud Storage and Middleware: The enterprise use cases require common APIs for access to cloud storage services, cloud databases, and other cloud middleware services such as message queues. Writing custom code that works only for a particular vendor’s cloud service locks the enterprise into that vendor’s system and eliminates some of the financial benefits and flexibility that cloud computing provides.
• Data and Application Federation: Enterprise applications need to combine data from multiple cloud-based sources, and they need to coordinate the activities of applications running in different clouds.
• SLAs and Benchmarks: In addition to the basic SLAs required by end users, enterprises who sign contracts based on SLAs will need a standard way of benchmarking performance. There must be an unambiguous way of defining what a cloud provider will deliver, and there must be an unambiguous way of measuring what was actually delivered. (SLAs have additional implications for cloud security; see the discussions of SLAs, auditing and monitoring in Section 6 for more information.)
• Lifecycle Management: Enterprises must be able to manage the lifecycle of applications and documents. This requirement includes versioning of applications and the retention and destruction of data. Discovery is a major issue for many organizations. There are substantial legal liabilities if certain data is no longer available. In addition to data retention, in some cases an enterprise will want to make sure data is destroyed at some point.
3 Enterprise to Cloud
This use case involves an enterprise using cloud services for its internal processes. This might be the most common use case in the early stages of cloud computing because it gives the enterprise the most control. This use case involves an enterprise using cloud services for its internal processes. This might be the most common use case in the early stages of cloud computing because it gives the enterprise the most control.
In this scenario, the enterprise uses cloud services to supplement the resources it needs:
• Using cloud storage for backups or storage of seldom-used data
• Using virtual machines in the cloud to bring additional processors online to handle peak loads (and, of course, shutting down those VMs when they're not needed anymore)
• Using applications in the cloud (SaaS) for certain enterprise functions (email, calendaring, CRM, etc.).
• Using cloud databases as part of an application's processing. This could be extremely useful for sharing that database with partners, government agencies, etc.
3.1 Requirements
The basic requirements of the Enterprise to Cloud use case are much the same as those for the Enterprise to Cloud to End User use case. An open client, federated identity, location awareness, metering and monitoring, management and governance, security, a common file format for VMs,
common APIs for cloud storage and middleware, data and application federation, SLAs and lifecycle management all apply.
Other requirements for this use case are:
• Deployment: It should be simple to build a VM image and deploy it to the cloud as necessary. When that VM image is built, it should be possible to move that image from one cloud provider to another, compensating for the different mechanisms vendors have for attaching storage to VMs. Deployment of applications to the cloud should be straightforward as well.
• Industry-specific standards and protocols: Many cloud computing solutions between enterprises will use existing standards such as RosettaNet or OAGIS. The applicable standards will vary from one application to the next and from one industry to the next.
4 Enterprise to Cloud to Enterprise
This use case involves two enterprises using the same cloud. The focus here is hosting resources in the cloud so that applications from the enterprises can interoperate. A supply chain is the most obvious example for this use case.
4.1 Requirements
The basic requirements of the Enterprise to Cloud to Enterprise use case are much the same as those for the Enterprise to Cloud use case. Identity, an open client, federated identity, location awareness, metering and monitoring, management and governance, security, industry-specific standards, common APIs for storage and middleware, data and application federation, SLAs and lifecycle management all apply.
Other requirements for this use case are:
• Transactions and concurrency: For applications and data shared by different enterprises, transactions and concurrency are vital. If two enterprises are using the same cloud-hosted application, VM, middleware or storage, it's important that any changes made by either enterprise are done reliably.
• Interoperability: Because more than one enterprise is involved, interoperability between the enterprises is essential.
5 Private Cloud
The Private Cloud use case is different from the others in that the cloud is contained within the enterprise. This is useful for larger enterprises. For example, if the payroll department has a surge in workload on the 15th and 30th of each month, they need enough computing power to handle the maximum workload, even though their everyday workload for the rest of the month is much lower. With a private cloud, computing power is spread across the enterprise. The payroll department gets extra cycles when they need it and other departments get extra cycles when they need it. This can deliver significant savings across the enterprise.
5.1 Requirements
The basic requirements of the Private Cloud use case are an open client, metering and monitoring, management and governance, security, deployment, interoperability, a common VM format, and SLAs.
Note that a private cloud does not require identity, federated identity, location awareness, transactions, industry standards, common APIs for cloud middleware and lifecycle management. In many cases, consumers have to use a private cloud so that location awareness will no longer be an issue. Keeping the cloud inside the enterprise removes many of the requirements for identity management, standards and common APIs.
6 Changing Cloud Vendors
This use case involves working with a different cloud vendor, either adding an additional vendor or replacing an existing one. It applies to all of the other use cases discussed in this paper. Being able to work with other vendors without major changes is one of the main benefits of openness and standardization. There are four different scenarios here, each of which has slightly different
requirements. In general, changing cloud vendors requires an open client, location awareness, security, SLAs, a common file format for VMs and common APIs for cloud storage and middleware. The details of those requirements are discussed in each of the following subsections.
6.1 Scenario 1: Changing SaaS vendors
In this scenario a cloud customer changes SaaS vendors. Both SaaS vendors provide the same application (CRM, accounting, word processing, etc.). Documents and data created with one vendor's software should be importable by the second vendor's software. In some cases, the customer might need to use the two vendors interchangeably.
6.1.1 Requirements
• Industry-specific standards: Moving documents and data from one vendor’s application to another requires both applications to support common formats. The formats involved will depend on the type of application.
In some cases, standard APIs for different application types will also be required. It is important to note that there is nothing cloud-specific to these requirements. The standards for moving a document from Zoho to Google Docs are the same standards for moving a document from Microsoft Office to OpenOffice.
6.2 Scenario 2: Changing middleware vendors
In this scenario a cloud customer changes cloud middleware vendors. Existing data, queries, message queues and applications must be exportable from one vendor and importable by the other.
6.2.1 Requirements
• Industry-specific standards: Moving documents and data from one vendor’s middleware to another requires both applications to support common formats. The formats involved will depend on the type of application.
• Common APIs for Cloud Middleware: This includes all of the operations supported by today’s cloud services, including cloud databases, cloud message queues and other middleware. APIs for connecting to, creating and dropping databases and tables. Cloud database vendors have enforced certain restrictions to make their products more elastic and to limit the possibility of queries against large data sets taking significant resources to process. For example, some cloud databases don't allow joins across tables, and some don't support a true database schema. Those restrictions are a major challenge to moving between cloud database vendors, especially for applications built on a true relational model.
Other middleware services such as message queues are more similar, so finding common ground among them should be simpler.
6.3 Scenario 3: Changing cloud storage vendors
In this scenario a cloud customer changes cloud storage vendors.
6.3.1 Requirements
• A Common API for Cloud Storage: Code that reads or writes data in one cloud storage system should work with a different system with as few changes as possible; those changes should be confined to configuration code. In a JDBC application, as an example, the format of the URL and the driver name are different for different database vendors, but the code to interact with the database is identical.
6.4 Scenario 4: Changing VM hosts
In this scenario a cloud customer wants to take virtual machines built on one cloud vendor's system and run it on another cloud vendor's system.
6.4.1 Requirements
• A common format for virtual machines: The VM format should work with any operating system. The assumption here is that the virtual machines themselves are running an operating system such as Windows or Linux. This means that the user of the virtual machine has chosen a platform prior to building a VM for the cloud, so there are no cloud-specific requirements for the software running inside the VM.
7 Hybrid Cloud
This use case involves multiple clouds working together, including both public and private clouds. A hybrid cloud can be delivered by a federated cloud provider that combines its own resources with those of other providers. A broker can also deliver a hybrid cloud; the difference is that a broker does not have any cloud resources of its own. The provider of the hybrid cloud must manage cloud resources based on the consumer’s terms.
It is important to note that to the consumer of a hybrid cloud, this use case is no different from the End User to Cloud use case discussed earlier. The user has no knowledge of what the hybrid cloud provider actually does.
7.1 Requirements
• All of the requirements of the previous use cases (except Transactions and concurrency) apply here, particularly Security, Data and Application Federation and Interoperability.
• SLAs: A machine readable, standard format for expressing an SLA. This allows the hybrid cloud provider to select resources according to the consumer’s terms without human intervention.
As mentioned in Section 2, the requirements for a community cloud are a subset of the requirements for the hybrid cloud. A community cloud has an infrastructure shared among enterprises with a common purpose. Here is the diagram for a community cloud:
Notice that the communication between the community and the community cloud is done across an intranet. This could be a VPN, but access is not via the public Internet.
No comments:
Post a Comment