对于迁移到云计算的考虑

将应用程序移动到云计算的技术和商业考虑

IBM® 云计算专家 Dave Russell 与 Google Cloud Computing Use Cases 组就向这个组有关云计算的不断发展的白皮书中添加迁移到云计算的章节时所应做的考虑和处理有过两次对话。

Dave Russell, 项目经理, IBM

Dave Russell 自 2003 年起就一直是 Software Standards and Emerging Technologies 团队的一员。Dave 作为 Marketing and Communications Committee 主席曾多年活跃于 Web Services Interoperability 组织 (WS>I)。Dave 一直都在积极投身于利用社交网络工具倡导人们通过对开放社区的参与来开发一本能够反映客户对云计算需求的白皮书。这种开放社区式的白皮书开发方式很成功,自 2009 年 6 月至今已经开发并出版了四个版本。具有 "Moving to the Cloud" 的主题的第五个版本正在开发当中。



2010 年 12 月 09 日

如今对于为 Cloud Computing Use Cases White Paper 添加 “移动到云计算” 的章节需要考虑哪些问题已经有了很多很棒的评论。我们无意对所建议的这些考虑逐一加以解释,而是会退后一步来探讨建立一种有关如何辨识云计算服务的流程。

背景

关注 9 月 22 日谈话 | 8 月 25 日谈话 的原始话题,您还可以 加入这个组来添加自己的意见

这个新的系列旨在解决如下两个问题:

  • 让云计算专家可以对云计算领域内的事件发表评论以及分享他们在设计、开发和实现云计算方面的经验。
  • 让您可以加入并参与到能够对云计算的未来产生影响的讨论中来。

请注意: 云计算用户(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: 身份

对于向云计算资源进行身份验证的确保,请考虑:

  • 可信的身份供应
  • 返回可移植性

下一步

如果您想就有关云计算技术的特定主题的最佳实践发表意见,您可以 加入本文中的这个组 以便将您的见解也加入到这个不断发展的白皮书中。

要开始跟上有关云计算技术、项目以及趋势的社区潮 ... 加入 My developerWorksCloud Computing Central 组

主题 17: 数据迁移

作为管理的一部分,对于数据迁移,请考虑:

  • 数据将被存储为哪种数据格式?
  • 这种选择是否会将此用户锁定到提供者的格式?
  • 迁移到另一个提供者的能力如何?
  • 用户若要将其服务从一个提供者移动到另一个提供者,有无可用的迁移支持供此用户选择?

下一步: 评估

下一个步骤是评估各主题 — 这些主题是一组最初的想法,它们有可能会成为 Cloud Computing Use Cases White Paper 的 Moving to the Cloud 版本的一部分 — 并决定哪些主题可以综合起来,也可以开始扩展每个主题。我们的目标是开发一本白皮书,帮助决策者做出是否移动到云计算的最佳决定。


结束语

我想这三个步骤 辨识候选者、为它们管理风险以及计量代表了一种极其简化的方式来识别迁移到云计算的正确候选者(以及考虑),但是如果这些步骤的确有意义,那么我们就可以使用它们来建立一种用来为云计算识别候选服务的可重复过程。有这样一个可重复过程来证明移动到云计算的价值和风险非常重要;否则很容易做出错误的决策。

Cloud Computing Use Cases 白皮书以及将会把迁移到云计算的主题添加到白皮书下一版本的这些讨论,都正在进行当中。

参考资料

学习

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=599835
ArticleTitle=对于迁移到云计算的考虑
publish-date=12092010