There have been some excellent comments to-date on what we need to consider in "Moving to the Cloud" for the Cloud Computing Use Cases White Paper. Rather than trying to put explanations in place for each of the suggested considerations, it is worth stepping back and looking at establishing a process on how cloud services could be identified.
Please note: The cloud consumer (CIO/CTO/CFO) will want to see an ROI from moving a service to the cloud; and the cloud provider needs to make money from hosting the service. Both those thoughts are valid. Therefore, it is important to consider the business implications of moving to the cloud first before applying rules to minimize risk.
Bottom line, if moving to the cloud does not have a positive impact on the success of the business, then it's probably not worth doing.
September 22: Proposed repeatable process to identify services for the cloud
The following suggestions are those considerations we think make logical sense to address in the next iteration of the use cases paper on the topic of migrating to the cloud. There are probably some considerations that are missing (and readers can contribute at the discussion group).
Step 1: ID existing or new processes, services, and data as candidates
Not all processes, services or data are candidates for the cloud. If we are going to use business criteria to identify cloud candidates, the following are possible examples:
- Save money?
- Increase flexibility to handle fluctuating volumes?
- Improved customer access/satisfaction?
- Offload work from existing IT environment?
- Consolidate like work with other enterprises within the cloud?
- And other considerations.
If the candidate, either new or existing, meets one or more of these criteria, then that candidate could potentially move to the cloud.
Step 2: Manage risks for candidates
To get through managing the risk and make it easier, you need a starting point. If you consider the data aspect of the candidate, then hopefully all the other considerations become dependent on the characteristics of the data to be considered to be moved.
Examples of data types are:
- Public access (think like parts in a catalog).
- Private access (info that is either confidential or needs to be kept private or both).
- Shared data between enterprises.
- Data that needs to be accessed 24x7.
- Data that needs to have subsecond access time.
- Of course, other types of data.
Once the data step has been considered and applied against the identified candidates from step 1, it is very important to identify if that candidate can be separated from other processes, services, or data which are not identified as candidates. If the identified candidates can be executed independently, then a risk level can be assigned.
As part of assigning a risk level, you have to consider the security policies assigned to the data. Other risk considerations are SLA, single sign-on capability, availability, disaster recovery, etc. (The original paper has a list of these.)
As part of validating the risk assessment, you may also want to be able to test the candidate in a private cloud environment so you can ensure that the security policies established by the enterprise are intact before deploying the service to a cloud provider.
Step 3: Metering
You'll also need to take into consideration the cost of doing business in the cloud based based on data volumes and risk management; this you'll do in parallel to ensuring that the risk issues have been determined and addressed.
For a service in the cloud, a cost factor will be assigned for accessing the data; it is important to understand the cost equation for the data access. The cloud consumer needs to project the average access rates, the peaks and the valleys. By understanding the volume projections and the access patterns, a cost can be estimated.
Remember, the CFO doesn't want surprises at the end the month or quarter, especially those that tell him the cost of running the cloud service exceeds the budgeted amount.
August 25: Cloud migration topics to consider
I want to thank everyone involved for your feedback. (Follow the original thread of this conversation and feedback.) The list has expanded since its introduction from 8 to 17 potential topics and subtopics for consideration.
Topic 1: Sources of workload
For sources of workload, consider:
- Internal applications such as payroll
- Managing customer data like medical records
- Identity and security
- Websites, either static (product catalogs for example) or interactive (like with order entry)
- Batch processing (time-insensitive stuff like genetics DB analysis, workflow-like workloads, Hadoop-like workloads, etc.)
Topic 2: Cloud types
For cloud types, consider:
- Alignment to requirements which drives the level of security needed
- Mapping cloud requirements to security, availability, accessibility, etc.
Topic 3: Regulatory concerns
For regulatory compliance, consider:
- HIPAA, SOX, GLBA, Patriot ACT, (some examples; I am sure that are complementary examples from countries around the world)
- PIV-I, national IDs, etc.
- Industry Standards Organizations standards, etc.
- Industry orgs such as agxml.org to reflect industry-specific requirements
- PCI for financial institutions and the equivalent for the other countries
- Location of data aligns with government requirements
Topic 4: Cloud uses
For the types of ways to use the cloud, consider:
- Development of new applications
- Testing of new applications and existing applications
- Production running of existing applications (consider that migration requires true IaaS; PaaS alone may be insufficient)
Topic 5: Availability, reliability
For cloud environment availability and reliability, consider:
- Ties back to the service level agreements (see the SLA section in V4 of the whitepaper)
Topic 6: Portability
For application portability, consider:
- Portability from the IT environment to the cloud provider
- Portability from cloud provider A to cloud provider B
- Portability from the cloud Provider to the IT environment
- One of our members raised the point that portability may not be important
Topic 7: Performance and workload
For workload volumes and performance issues, consider:
- Understanding the volumes of data to be transferred and accessed
- User traffic
- Vertical scaling versus horizontal scaling (look at legacy apps)
- Workload optimization: How we can dynamically assess and optimize the resourcing and placement of workloads
Topic 8: Disaster recovery
For disaster recovery, consider:
- Is the cloud an alternative for disaster recovery?
- If the cloud provider fails, what are the considerations?
Topic 9: Migration modes
For migration modes, consider:
- Accessibility of data (we must consider issues of data synchronization and cross-site trusts)
Topic 10: Service dev & test
For development and testing of services, consider:
- Using a cloud environment to offload main site workloads
Topic 11: Business cases and models
For making the business cases, consider:
- Where is my market?
- Which aspects are important to my customers?
- Benefits of cloud computing compared with on-premise installations and other alternatives
Topic 12: Authentication, authorization, audit
For common authentication, authorization, and audit processing for an application, consider:
- The question of federated identity: Which is best to follow ... SAML or OpenID?
Topic 13: Privacy
Topic 14: Security
For security, consider:
- All the things in V4 of the Cloud Computing Use Cases White Paper section on security
Topic 15: SLAs
For service level agreements, consider:
- All the things in V4 of the Cloud Computing Use Cases White Paper section on SLAs
Topic 16: Identity
For identity assurance of those authenticating to cloud resources, consider:
- Trusted identify provisions
- Ties back to portability
Topic 17: Data migration
For data migration considerations as a part of governance, consider:
- What is the format in which the data will be stored?
- Will the choice lock the consumer into the provider's format?
- What is the ability to migrate to another provider?
- Is there any migration support available should the consumer choose to move their services from one provider to another?
The next step: Assessment
The next step is to assess the topics — which are an initial set of thoughts for topics which may become part of the Moving to the Cloud version of the Cloud Computing Use Cases White Paper — and determine which ones can be combined, as well as to begin to expand each of the topic. The goal is to develop a paper which provides decision-makers with the content to be able to make better decisions when moving to the cloud.
I think the three steps on identifying candidates,managing risk for them, and metering represent an overly simplified approach to identifying the right candidates (and considerations) to migrate to the cloud, but if these steps make sense, then we can use them to establish a repeatable process for identifying candidate services for the cloud. It is important to have a repeatable process to qualify the value and the risk of moving to the cloud; otherwise the wrong decision can be easily made.
The Cloud Computing Use Cases whitepaper, as well as these discussions that will add the topic of migrating to the cloud in the next version of the paper, is an ongoing process.
- Review and summary of cloud service level agreements from "Cloud Computing Use Cases Whitepaper" Version 4.0.
- Review and summary of cloud security scenarios from "Cloud Computing Use Cases Whitepaper" Version 3.0.
- The original document is from the experts that belong to the Cloud Computing Use Cases group. These versions of the paper are available in PDF:
- The Open Cloud Manifesto is a statement of the principles for maintaining openness in cloud computing.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- Join a cloud computing group on My developerWorks.
- Read all the great cloud blogs on My developerWorks.
- Join the My developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.