互联网服务
企业在进行云平台迁移时，你最大的担忧是什么？
两年前，你还觉得云计算只是空中楼阁，不能落地，那还能理解，毕竟两年前确实没有很多云计算应用案例。
如今大家都在谈论云计算，云时代来临，你开始了云应用的脚步吗？这个是不可改变的事实，企业也都在不断培养懂得云计算人才和了解云计算。当今的数据信息是在不断爆炸，总有一天企业的数据中心是不可避免的会出现性能问题，会严重拖累你的发展，所以必须要再建立一个数据中心来帮助减轻压力，但是在巨额成本的制约下，企业不得不考虑会选择把一些应用迁移到云中，以减轻系统的压力。对于企业来说，云计算就好像是一座摩天大楼，企业如何才能够登上这座高楼大厦呢？企业在进行云平台迁移时，最大的担忧会是哪些？
大家可以通过投票，来帮助那些还没有进行迁移云平台的企业或者个人，让他们能很好的了解，阻碍企业迁移到云平台的因素都有哪些？
如今大家都在谈论云计算，云时代来临，你开始了云应用的脚步吗？这个是不可改变的事实，企业也都在不断培养懂得云计算人才和了解云计算。当今的数据信息是在不断爆炸，总有一天企业的数据中心是不可避免的会出现性能问题，会严重拖累你的发展，所以必须要再建立一个数据中心来帮助减轻压力，但是在巨额成本的制约下，企业不得不考虑会选择把一些应用迁移到云中，以减轻系统的压力。对于企业来说，云计算就好像是一座摩天大楼，企业如何才能够登上这座高楼大厦呢？企业在进行云平台迁移时，最大的担忧会是哪些？
大家可以通过投票，来帮助那些还没有进行迁移云平台的企业或者个人，让他们能很好的了解，阻碍企业迁移到云平台的因素都有哪些？
67同行回答
找到一篇关于迁移到云计算的文章
对于迁移到云计算的考虑
如今对于为 Cloud Computing Use Cases White Paper 添加 “移动到云计算” 的章节需要考虑哪些问题已经有了很多很棒的评论。我们无意对所建议的这些考虑逐一加以解释，而是会退后一步来探讨建立一种有关如何辨识云计算服务的流程。
请注意： 云计算用户（CIO/CTO/CFO）希望从服务向云计算的移动中看到投资回报率；而云计算提供者则需要从托管此服务中赢利。这两种想法都是合情合理的。因此，在为了最小化风险而应用规则之前，需要先考虑移动到云计算所带来的业务影响。
底线是，如果移动到云计算对于业务的成功没有任何积极的影响，那么可能就不值得这么做了。
9 月 22 日：用来辨识面向云计算的服务的可重复过程
如下建议是我们认为对于解决有关移动到云计算的主题的用例白皮书的下一轮撰写有实际意义的一些考虑。有一些考虑可能会被遗漏（读者可以通过讨论组贡献自己的高见）。
步骤 1: 辨别现有或新的过程、服务和数据作为候选者
并不是所有的过程、服务或数据都可以成为面向云计算的候选者。如果我们想要使用商业条件来辨识云计算的候选者，那么如下所示的将是一些可能的例子：
能否省钱？
处理波动量的灵活性能否增加？
能够改进客户访问/满意度？
能否能减轻现有 IT 环境的工作？
能否巩固与云计算内的其他企业的协作？
其他的一些考虑。
如果这个候选者，不管是新的还是现有的，满足了上述条件中的一个或多个，那么这个候选者就有移动到云计算的潜力。
步骤 2: 为候选者管理风险
为了管理风险并尽量简化它，需要有一个出发点。如果您关注的是这个候选者的数据方面，那么最好所有其他的关注点都会依赖于要被移动到云计算的数据的特征。
数据类型的例子有：
公开访问（想象一下一个编目内的各部分）。
私有访问（比如保密信息或需要被保持为私有的信息）。
企业间需要共享的数据。
需要 24x7 都可以访问到的数据。
需要具有亚秒（subsecond）存取时间的数据。
当然，还有其他的数据类型。
若考虑了数据步骤并针对按步骤 1 辨别出的候选者进行了应用，那么就需要重点辨识这个候选者能否从未被识别为候选者的其他的过程、服务或数据中分离出来。如果所辨别出的候选者可被独立执行，那么就可分配一种风险等级。
作为分配风险等级的一部分，必须考虑分配给数据的安全性策略。其他的风险考虑还包括 SLA、单个签入（single sign-on）能力、可用性、灾难恢复等。（最初的白皮书中含有这样的一个列表。）
为了验证风险估计，您可能还想要能在一个私有云计算环境内测试这个候选者以便在将此服务部署到云计算提供者之前先确保由该企业建立的安全策略是完好如初的。
步骤 3: 计量
您还需要基于数据量和风险管理考虑在云计算内进行商业活动的成本；您将并行进行以确保风险问题被及时确定并解决。
对于云计算内的某个服务，还会为访问数据分配一个成本系数；很重要的一点是要理解数据访问的成本等式。云计算的用户需要预计出平均访问速度、峰值以及谷值。通过对数据量的预计以及访问模式的理解，就可以估算出成本。
请记住，CFO 可不想在月末或季末出现什么意外，尤其不希望有人会告诉他们说运行云计算服务的成本会超出预算。
8 月 25 日：要考虑的云计算迁移主题
我首先感谢每个参与者的反馈。（追随本次谈话的原始路径和反馈。）此列表已经扩充了，因其引入了 8 到 17 个潜在的主题和子主题供考虑。
主题 1: 工作负载的来源
对于工作负载的来源，请考虑：
数据挖掘
内部的应用程序，比如工资系统
用户数据的管理，比如医疗记录
身份和安全性
网站，或者是静态的（比如产品目录）或交互式的（比如订单输入）
批处理（时间敏感的东西，比如 genetics DB 分析、类似工作流的工作负载、类似 Hadoop 的工作负载等）
主题 2: 云计算类型
对于云计算类型，请考虑：
调整会推高所需安全性等级的需求
将云计算需求映射到安全性、可用性以及可访问性等。
主题 3: 规定遵从性问题
对于规定遵从性，请考虑：
HIPAA、SOX、GLBA、Patriot ACT（只列出了一些例子；我确信在全世界的各个国家都有补充例子）
PIV-I、国家 ID 等。
行业标准组织的标准等。
像 agxml.org 这样的能反映特定于行业的要求的行业组织
金融机构的 PCI 以及其他国际的对等标准
符合政府要求的数据位置
主题 4: 云计算使用
对于使用云计算的方式的类型，请考虑：
新应用程序的开发
新应用程序和现有应用程序的测试
现有应用程序的生产运行（请考虑迁移需要真正的 IaaS；只 PaaS 可能并不充分）
主题 5: 可用性以及可靠性
对于云计算环境的可用性以及可靠性，请考虑：
返回服务等级协议（参见白皮书版本 4 内的 SLA 部分）
主题 6: 可移植性
对于应用程序的可移植性，请考虑：
从 IT 环境到云计算提供者的可移植性
从云计算提供者 A 到云计算提供者 B 的可移植性
从云计算提供者到 IT 环境的可移植性
我们的一名成员提出这样的观点，即可移植性可能并不重要
主题 7: 性能和工作负载
对于工作负载和性能问题，请考虑：
了解要被传送和访问的数据量
用户流量
垂直伸缩还是水平伸缩（着眼于遗留应用程序）
工作负载优化：我们如何能动态地访问并优化工作负载的资源化及放置。
主题 8: 灾难恢复
对于灾难恢复，请考虑：
云计算是不是灾难恢复的一种可选方式？
如果云计算提供者发生故障，该有哪些考虑？
主题 9: 迁移模式
对于迁移模式，请考虑：
数据的可访问性（我们必须考虑数据同步以及跨站信任的问题）
主题 10: 服务开发及测试
对于服务的开发和测试，请考虑：
使用云计算环境来卸载主站的工作负载
主题 11: 商业案例和模型
对于商业案例的打造，请考虑：
我的市场在哪？
哪些方面对我的客户最为重要？
云计算与 on-premise 安装以及其他可选方式相比有何优势？
主题 12: 身份验证、授权和审计
对于应用程序的常规身份验证、授权和审计的处理，请考虑：
对于联合身份的问题：最佳的是遵守哪个...，SAML 还是 OpenID？
主题 13: 私密性
私密性考虑。
主题 14: 安全性
对于安全性，请考虑：
Cloud Computing Use Cases 白皮书版本 4 中有关安全性的所有内容
主题 15: SLA
对于服务等级协议，请考虑：
Cloud Computing Use Cases 白皮书版本 4 中有关 SLA 的所有内容
主题 16: 身份
对于向云计算资源进行身份验证的确保，请考虑：
可信的身份供应
返回可移植性
主题 17: 数据迁移
作为管理的一部分，对于数据迁移，请考虑：
数据将被存储为哪种数据格式？
这种选择是否会将此用户锁定到提供者的格式？
迁移到另一个提供者的能力如何？
用户若要将其服务从一个提供者移动到另一个提供者，有无可用的迁移支持供此用户选择？
下一步: 评估
下一个步骤是评估各主题 — 这些主题是一组最初的想法，它们有可能会成为 Cloud Computing Use Cases White Paper 的 Moving to the Cloud 版本的一部分 — 并决定哪些主题可以综合起来，也可以开始扩展每个主题。我们的目标是开发一本白皮书，帮助决策者做出是否移动到云计算的最佳决定。
结束语
我想这三个步骤 辨识候选者、 为它们管理风险以及计量代表了一种极其简化的方式来识别迁移到云计算的正确候选者（以及考虑），但是如果这些步骤的确有意义，那么我们就可以使用它们来建立一种用来为云计算识别候选服务的可重复过程。有这样一个可重复过程来证明移动到云计算的价值和风险非常重要；否则很容易做出错误的决策。收起
对于迁移到云计算的考虑
如今对于为 Cloud Computing Use Cases White Paper 添加 “移动到云计算” 的章节需要考虑哪些问题已经有了很多很棒的评论。我们无意对所建议的这些考虑逐一加以解释，而是会退后一步来探讨建立一种有关如何辨识云计算服务的流程。
请注意： 云计算用户（CIO/CTO/CFO）希望从服务向云计算的移动中看到投资回报率；而云计算提供者则需要从托管此服务中赢利。这两种想法都是合情合理的。因此，在为了最小化风险而应用规则之前，需要先考虑移动到云计算所带来的业务影响。
底线是，如果移动到云计算对于业务的成功没有任何积极的影响，那么可能就不值得这么做了。
9 月 22 日：用来辨识面向云计算的服务的可重复过程
如下建议是我们认为对于解决有关移动到云计算的主题的用例白皮书的下一轮撰写有实际意义的一些考虑。有一些考虑可能会被遗漏（读者可以通过讨论组贡献自己的高见）。
步骤 1: 辨别现有或新的过程、服务和数据作为候选者
并不是所有的过程、服务或数据都可以成为面向云计算的候选者。如果我们想要使用商业条件来辨识云计算的候选者，那么如下所示的将是一些可能的例子：
能否省钱？
处理波动量的灵活性能否增加？
能够改进客户访问/满意度？
能否能减轻现有 IT 环境的工作？
能否巩固与云计算内的其他企业的协作？
其他的一些考虑。
如果这个候选者，不管是新的还是现有的，满足了上述条件中的一个或多个，那么这个候选者就有移动到云计算的潜力。
步骤 2: 为候选者管理风险
为了管理风险并尽量简化它，需要有一个出发点。如果您关注的是这个候选者的数据方面，那么最好所有其他的关注点都会依赖于要被移动到云计算的数据的特征。
数据类型的例子有：
公开访问（想象一下一个编目内的各部分）。
私有访问（比如保密信息或需要被保持为私有的信息）。
企业间需要共享的数据。
需要 24x7 都可以访问到的数据。
需要具有亚秒（subsecond）存取时间的数据。
当然，还有其他的数据类型。
若考虑了数据步骤并针对按步骤 1 辨别出的候选者进行了应用，那么就需要重点辨识这个候选者能否从未被识别为候选者的其他的过程、服务或数据中分离出来。如果所辨别出的候选者可被独立执行，那么就可分配一种风险等级。
作为分配风险等级的一部分，必须考虑分配给数据的安全性策略。其他的风险考虑还包括 SLA、单个签入（single sign-on）能力、可用性、灾难恢复等。（最初的白皮书中含有这样的一个列表。）
为了验证风险估计，您可能还想要能在一个私有云计算环境内测试这个候选者以便在将此服务部署到云计算提供者之前先确保由该企业建立的安全策略是完好如初的。
步骤 3: 计量
您还需要基于数据量和风险管理考虑在云计算内进行商业活动的成本；您将并行进行以确保风险问题被及时确定并解决。
对于云计算内的某个服务，还会为访问数据分配一个成本系数；很重要的一点是要理解数据访问的成本等式。云计算的用户需要预计出平均访问速度、峰值以及谷值。通过对数据量的预计以及访问模式的理解，就可以估算出成本。
请记住，CFO 可不想在月末或季末出现什么意外，尤其不希望有人会告诉他们说运行云计算服务的成本会超出预算。
8 月 25 日：要考虑的云计算迁移主题
我首先感谢每个参与者的反馈。（追随本次谈话的原始路径和反馈。）此列表已经扩充了，因其引入了 8 到 17 个潜在的主题和子主题供考虑。
主题 1: 工作负载的来源
对于工作负载的来源，请考虑：
数据挖掘
内部的应用程序，比如工资系统
用户数据的管理，比如医疗记录
身份和安全性
网站，或者是静态的（比如产品目录）或交互式的（比如订单输入）
批处理（时间敏感的东西，比如 genetics DB 分析、类似工作流的工作负载、类似 Hadoop 的工作负载等）
主题 2: 云计算类型
对于云计算类型，请考虑：
调整会推高所需安全性等级的需求
将云计算需求映射到安全性、可用性以及可访问性等。
主题 3: 规定遵从性问题
对于规定遵从性，请考虑：
HIPAA、SOX、GLBA、Patriot ACT（只列出了一些例子；我确信在全世界的各个国家都有补充例子）
PIV-I、国家 ID 等。
行业标准组织的标准等。
像 agxml.org 这样的能反映特定于行业的要求的行业组织
金融机构的 PCI 以及其他国际的对等标准
符合政府要求的数据位置
主题 4: 云计算使用
对于使用云计算的方式的类型，请考虑：
新应用程序的开发
新应用程序和现有应用程序的测试
现有应用程序的生产运行（请考虑迁移需要真正的 IaaS；只 PaaS 可能并不充分）
主题 5: 可用性以及可靠性
对于云计算环境的可用性以及可靠性，请考虑：
返回服务等级协议（参见白皮书版本 4 内的 SLA 部分）
主题 6: 可移植性
对于应用程序的可移植性，请考虑：
从 IT 环境到云计算提供者的可移植性
从云计算提供者 A 到云计算提供者 B 的可移植性
从云计算提供者到 IT 环境的可移植性
我们的一名成员提出这样的观点，即可移植性可能并不重要
主题 7: 性能和工作负载
对于工作负载和性能问题，请考虑：
了解要被传送和访问的数据量
用户流量
垂直伸缩还是水平伸缩（着眼于遗留应用程序）
工作负载优化：我们如何能动态地访问并优化工作负载的资源化及放置。
主题 8: 灾难恢复
对于灾难恢复，请考虑：
云计算是不是灾难恢复的一种可选方式？
如果云计算提供者发生故障，该有哪些考虑？
主题 9: 迁移模式
对于迁移模式，请考虑：
数据的可访问性（我们必须考虑数据同步以及跨站信任的问题）
主题 10: 服务开发及测试
对于服务的开发和测试，请考虑：
使用云计算环境来卸载主站的工作负载
主题 11: 商业案例和模型
对于商业案例的打造，请考虑：
我的市场在哪？
哪些方面对我的客户最为重要？
云计算与 on-premise 安装以及其他可选方式相比有何优势？
主题 12: 身份验证、授权和审计
对于应用程序的常规身份验证、授权和审计的处理，请考虑：
对于联合身份的问题：最佳的是遵守哪个...，SAML 还是 OpenID？
主题 13: 私密性
私密性考虑。
主题 14: 安全性
对于安全性，请考虑：
Cloud Computing Use Cases 白皮书版本 4 中有关安全性的所有内容
主题 15: SLA
对于服务等级协议，请考虑：
Cloud Computing Use Cases 白皮书版本 4 中有关 SLA 的所有内容
主题 16: 身份
对于向云计算资源进行身份验证的确保，请考虑：
可信的身份供应
返回可移植性
主题 17: 数据迁移
作为管理的一部分，对于数据迁移，请考虑：
数据将被存储为哪种数据格式？
这种选择是否会将此用户锁定到提供者的格式？
迁移到另一个提供者的能力如何？
用户若要将其服务从一个提供者移动到另一个提供者，有无可用的迁移支持供此用户选择？
下一步: 评估
下一个步骤是评估各主题 — 这些主题是一组最初的想法，它们有可能会成为 Cloud Computing Use Cases White Paper 的 Moving to the Cloud 版本的一部分 — 并决定哪些主题可以综合起来，也可以开始扩展每个主题。我们的目标是开发一本白皮书，帮助决策者做出是否移动到云计算的最佳决定。
结束语
我想这三个步骤 辨识候选者、 为它们管理风险以及计量代表了一种极其简化的方式来识别迁移到云计算的正确候选者（以及考虑），但是如果这些步骤的确有意义，那么我们就可以使用它们来建立一种用来为云计算识别候选服务的可重复过程。有这样一个可重复过程来证明移动到云计算的价值和风险非常重要；否则很容易做出错误的决策。收起
浏览626
管理员维护难度增大，云计算内部拓扑结构复杂，整体宕机风险增加。aix_frank 发表于 2012-5-31 06:39
看样子这位兄弟已经玩过了，分享分享经验啊！浏览600
浏览634
浏览582