为什么你应当将应用迁移到云服务上？

问题导读
1.为什么要进行迁移？
2.你的应用是否能够经受住访问量突然空前增长的考验呢？
3.云服务如何降低成本？

软件组织正在快速地实施云技术，但迁移始终是一个无法回避的挑战。哪些部分是需要你密切留意的？哪些应用程序更适合于进行迁移？如何对应用程序进行重构以适用于云端？经历了这一转变的先行者为我们留下了什么启示？在这一系列文章中，你将从那些在帮助企业成功地迁移至云环境方面富有经验的专家那里获得实用的建议。这一领域应得到高度关注，我们希望你也能够参与这方面的讨论。

本文是InfoQ的“云迁移”系列文章中的一篇，你可以通过RSS订阅获取关于新文章的通知。

你的客户或用户真的在意你的应用程序是运行在Tier 1的数据中心，还是运行在公有云上吗？当然不会，但他们确实会定期关注在使用你的服务时所经历的体验。客户期望的服务是快速并且可靠的，它不会因为访问量的突然上升而降低响应度，而是始终保持优良的表现。他们也期望你能够更新你的服务交付产品，让它与最新的技术发展保持一致。

为了理解这一点，让我们用业务方面的说法来进行一个类比，可以将以上需求解释为：

你现有的应用程序（例如一个医疗应用）的基础设施是否足够敏捷与灵活，能够快速地推出一个新的特性？比如在可穿戴设备（例如智能手表）上用亮灯及语音提醒患者到了服用药品的时间。

在本文中，我们将探索将现有的应用迁移到云端所产生的各种益处的细节，使你在进行决策时做到心中有数。

为什么要进行迁移？

• 在首尔举办的Big Bang团体“2015世界巡演”的在线售票过程中，热情的歌迷不仅很快抢完了门票，还使得服务器一度崩溃。
• Flipkart在举行一次有历以来力度最大的促销活动时，网站发生崩溃。
  

灵活的能力

以上这种情况并不罕见，其结果是媒体反而加大了对这一事件的关注。有趣的是，如果一个初创公司的应用首次遇到这种因为突发性流量而产生崩溃的情形，这种体验并不那么糟糕，反倒是一次宝贵的经验，因为崩溃是难以避免的。

那么，你的应用是否能够经受住访问量突然空前增长的考验呢？

为了回答这个问题，你可能先要询问一下你的基础设施提供商：为了应对这种突发性的增长，他们能够在多少时间内增加硬件能力。你的提供商是否能够做到接近即时地（在几分钟内）设置（或解除）资源？

与传统的服务提供商不同，云服务在设计时就提供了内置的工具，以建立快速的灵活性，它能够确保以下能力：

• 一旦由于突发性流量造成访问量达到峰值，能够设置额外的资源（例如虚拟机VM）以维持对用户的响应能力。
• 一旦突发性流量回复正常，能够立即解除这些额外的资源（将虚拟机释放，返回给云服务）。这能替你节省很多钱！
• 你的应用能够按需立即访问无限量的资源。
  

简单的总结一下。在任何一个时间点上，根据你的负载情况变化，云服务总是能够为你提供适当的设置能力。设置的资源既不会过多也不会过少，并且能够快速、自动地完成。

对于传统的基础设施提供商来说，要对负载的增或减作出反应，通常需要几个小时（实际上很可能要几天）。因为他们需要手工介入这一过程，才能够实现这种可响应性的机制。

注：请不要混淆了灵活性与可伸缩性。只要在云环境中的基础设施上部署应用，就能够隐式地获得这种灵活性，而应用程序的可伸缩性是由它的架构所决定的。如果某个应用程序能够通过往物理机器中加入（纵向扩展 / 垂直伸缩）额外的能力（例如RAM或CPU），或是为资源池中加入更多的物理机器（横向扩展 / 水平伸缩），而因此能够承受更多的负载，我们就说这个应用是可伸缩的。

很显然，仅仅将应用迁移到云服务并不总是能够确保它的可伸缩性。如果某个应用程序的数据库是基于Oracle或SQL Server的标准版本，它不支持分区（实现可伸缩架构的前提条件之一），在这种情况下要实现大规模化，可能要对整体功能进行大规模的重新设计。而NoSQL数据库就实现了高度的可伸缩性。与之类似，你的应用程序或许托管在一个多核的服务器上，但如果你的应用没有实现多线程应用，那么这点优势也没有什么实际用处。这也是Google为什么要推出Go这门新语言的原因，就是为了让并发（多线程）编程更简单。

不过，你必须理解一点，并非所有的应用都需要这种灵活性能力。举例来说，如果你的业务规模很小，只是在一个内部的HR（人力资源）管理应用中为50人左右的员工提供服务，并且员工数目不太可能会有爆发式的增长，那么为了灵活性而将整个应用迁移至云端就没什么必要了。

降低成本

成本的降低包括两个方面：

1. 无资本支出

• 由于你不需要购买IT方面的基础设施，因此也没有资本支出方面的成本了。云提供商不需要你做出任何长期的承诺。
  

2. 现用现付

• 云服务的基本特征之一就是按使用量付费。服务计划是根据预配置的VM的运行小时数，以及带宽、数据传输及存储量的大小而决定的。请确保你进行了适当的配置与设置，只为你所需的能力付费。
  

这种特征与传统的数据中心完全相反，后者在大多数情况下，你都需要额外设置超过正常范围的机器，虽然你只在一些极端的情况下才会用到这些能力，但仍然要为它们买单！

敏捷性 —— 更快地进入市场

作为一名企业家，你必须具备长远的眼光，看准时机快速地决定开发应用程序的某个新特性、提交代码、将其发布到市场，让你的客户为此感到震撼（也包括你的竞争对手！）。云服务提供商能够为你带来自动化的基础设施以及快速的转变能力，与之相比，传统服务提供商在基础设施的申请、订单处理、获取以及安装上显得非常官僚。

你是否注意到一点，在进入2015之后，电子商务应用逐渐从移动优先转变为应用优先策略？假设这种策略正适合你的目标，那么你是否能够做到足够敏捷，以快速地响应这种技术上的转变呢？

专注于你的业务

与IT相关的诸多琐事都能够在云服务中实现自动化，以传统的方式管理这些琐事无疑是对你的宝贵时间与精力的一种浪费，它对于你的核心业务没有产生任何直接贡献。

请保持你远离那些使你的注意力分散的东西，将你的劳动力保持在更高价值的活动上并取得一致。别忘记 —— 时间就是金钱。

更高的可用性、可靠性和性能

除了云服务的服务水平协议（SLA），还有什么服务能够实现三个9甚至四个9（99.99%）的可用性呢？虽然传统的数据中心或许会声称他们也能够达到相同的能力，但其中的大多数并不具备某种良好的评估与监控服务，而这是对他们的SLA能力进行审计所不可或缺的。

为了提高可用性与可靠性，云服务能够实现跨多个可用性区域（AWS、Rackspace），还有公有云提供商实现的联合网络（federated network），以及多虚拟机（multi-hypervisor）技术，这些都是为了实现100%的可用性而设计的特性。

对许多现有的应用程序来说，他们的用户往往来自于某个特定的区域。在迁移到云端之后，由于选择了合适的地理区域的云提供商，应用的网络延迟也降低了。

容灾性（DR）

正如他们所说：

如果某件事有可能会变得更糟，那么它就一定会变糟。

-- 墨菲定律的某种变体

你的应用程序是否能够经受住灾难的考验呢？例如网络与电源故障、火灾、地震、暴雨、洪水，或是保存你的服务器资源的大厦遭受了严重的物理破坏呢？

容灾计划（DRP）需要细致的计划以及架构设计，它能够意识到故障的发生并进行快速响应，以缓解对业务造成的损失。DR是一个复杂的命题，因为大多数企业都没有准备好DRP，或者说他们所准备的DRP会由于整个计划中的某些小缺陷而注定会失败，而这些缺陷是由于缺乏这方面的演练而产生的。只有这些罕见的灾难发生之后，他们才会意识到这些缺陷。

对于业务的连续性来说，成熟的DRP是十分关键的。云环境在设计上是十分灵活的，你需要选择正确的工具集与配置，让灾难对你的业务产生的影响降至最低。

云环境是安全的

100%的安全性只能是一种幻觉。如果你必须在现有的选择中进行决策，那么云服务的安全性不会低于任何一种现有的系统。云服务的提供商以他们的创新性而闻名，在任何一方面，他们所实现的物理及逻辑安全实践都要胜于单一的本地数据中心的运维。许多云提供商如今都已经获得ISO、PCI DSS、欧盟模式条款（EU Model Clauses）及其它安全组织的认证。

此外，并非所有应用程序都需要银行级别的安全性，对吧？如果你的应用中真的包含了高度机密的数据，或是必须符合某种特定的安全与隐私条规（例如HIPPAA或HITECH），那么你可以选择混合式的云服务（推荐医疗应用使用这种方式）。

这些不时出现的关于云服务安全性的问题，更多的是一种FUD（恐惧、不确定性和怀疑），而并非事实。

其它一些你无法忽视的益处

以上所提到的这些益处是当你迁移到云环境中可以立即获得的好处，除此之外还有一些无形的益处存在。公有云服务是无污染的，因为云资源池也是云环境的根本特征之一。

云服务提高了协作能力，并实现高效的文档控制，使你能够在任何地方开展高效的办公。虽然在迁移过程中需要你对应用程序的各方面进行或多或少的重新设计，但这也为你带来了一个良机，可以实现某些尖端的技术，例如使用Docker（一种基于虚拟化技术的容器，它已得到了空前的应用）实现更简便的部署。此外，随着物联网在2015走向舞台的中央，你可能需要在现在的应用中整合微服务架构，以应对在不久的将来客户可能会产生的请求。

怎样的应用程序适合迁移至云服务？

根据经验来看，在过去七年间所开发的多数应用程序，包括n层或流行的3层结构web应用、批处理应用和后端服务或许比较适合进行迁移，而更早的应用程序或许需要投入更多的精力进行改造。这一点完全取决于现有应用程序的架构。

有多种因素可能会导致你现有的应用程序与云迁移过程不兼容（或者可能需要投入巨大的精力进行改造）：

• 紧耦合的架构，硬编码的配置。
• 依赖于某种云服务所不支持的数据库。
• 需要某些特殊的硬件功能，例如基于硬件的加密、大型主机等等。
• 依赖于多种第三方应用。
• 许可问题。
  

以下这份表格可以作为一份参考，或许能够帮助你进行快速地决策：

封装式应用 Email、协作及生产力应用	医疗应用	遗留应用
周期性应用 工资单处理、纳税申报、学校招生、某些博彩应用、会议管理等等。	严守合规性; 包括HIPAA - HITECH, 美欧安全港, 欧洲通用数据保护条例（GDPR）等等。	数据库支持 —— Microsoft SQL Server 2008 R2之前的版本、MySQL 5.1之前的版本，及Oracle 11g之前版本的数据不适合进行云迁移，因为需要投入额外的精力将它们首先升级到所支持的版本。 有限的，或是无技术支持的 —— 拿MS Azure举个例子，微软对于SQL Server 2205之前的版本的技术支持非常有限，或是完全不提供支持。Azure VM镜像（模板）只包括SQL Server 2008 R2之后的版本。
可预见发生访问量激增的应用 黑色星期五或购物季时的电子商务应用、皇室的婚礼、世界杯网站、订票应用。	银行应用 符合PCI DSS 规范， 安全方面的顾虑， 对于大型主机的依赖。	许可问题 —— 如果你现有的许可符合许可证移动性的条款，例如BYOL（自有许可），就能够将它转到云服务中。对于大多数遗留应用来说，这一选择并不适用。
无法预见访问量激增的应用 由于被权威性的网站所提及导致访问量突然上升。 （另有某些国内网站，请参考英文原文）	具有地理位置限制的应用——大多数云数据中心位于北美或西欧。在设计上，云环境中的数据没有边界限制，除非有某些限制的存在。如果你的国家对于你的应用中的数据合规性有某些特殊的需求，在迁移之前要仔细考虑这一点。	ERP系统 存在架构瓶颈，例如紧耦合、硬编码的配置、对第三方应用的依赖，在某些情况下会用到特殊的基于硬件的加密功能
初创应用 / 在线游戏 访问量的增减取决于你的业务是成功还是失败
大数据（分析）应用
需要超级计算能力 超高带宽、增强型网络、以及非常高的计算能力 —— 如HPC （高性能计算）
微服务
概念型原型、开发及QA环境
备份、归档及存储

行动胜于语言

这下这份表格中的组织已经将现有的应用迁移到云环境中，表格中也提及了他们在迁移完成后所获的益处。

序号#	组织	挑战	迁移至	益处
1.	Animoto 一个在美国的视频制作以及图片幻灯片制作公司。	现有的应用是在自有的服务器上运行的。 在2008年4月，通过Facebook上的应用达到了用户高峰，在三天之年的注册人数达到了75万。	AWS	1. 在峰值时，一小时内约有2万5千人会使用Animoto！为了在三天之内达到这种能力，他们的应用从50个EC2实例扩展到最多3500个EC2的实例。 注：EC2实例即虚拟服务器。
2.	redBus 一个在印度的在线巴士订票服务。	在一个传统的数据中心运行它的处理工作，它的基础设施无法有效地应对处理量的起伏，这影响了他们的生产力。 并且服务器的采购及配置非常耗时。	AWS	1. 总体成本降低了大约30-40%. 2. 延迟降低了 （大约4倍）。由于延迟的降低，redBus的访问量大约上涨了三倍。
3.	Expedia 在美国处于领先地位的旅游公司。	必须在物理上接近客户的地方运行他们的Expedia Suggest服务（ESS），以实现快速的可响应服务，使网络延迟降至最低。	AWS	平均网络延迟从700毫秒降至50毫秒以下。
4.	Xiaomi 一家中国的高端智能手机制造商。	需要一种解决方案能够为世界各国的人群提供可靠性以及令人满意的连接速度，并且在公司成长时能够无缝地拓展他们的服务。	AWS	1. 下载速度快了 30%。 2. 服务交付周期变短了，并且快速地推出了应用下载中心。 3. 更好的访问速度，减少了前期的投入。
5.	Aucor 一个芬兰的web设计公司。	他们的私有虚拟服务器在小规模时运行情况良好，但随着项目数量的不断上升，所需的服务器数目过多，还需要聘用全职的系统管理员。	GAE	1. 能够每秒处理超过7万个请求，并且让用户完全感受不到延迟。
6.	Khan Academy 一个美国的非盈利性教育组织。	最初他们维护着一个网站用于他们不断增加的视频库，这一结构已经经过了许多年，但随着访问量的增长，该平台遇到了各种限制。	GAE	1. 每个月能够支持380万独立请求，每个上学日还要提供150万个实践问题并处理回答。 2. 保存着2000个以上的视频片段，并且还在继续增长。 3. 该系统能够轻易地处理用量的增长。

结论

随着数以万计的应用迁移至云服务并开始利用它的能力，事实已经证明了云服务的实用性，并且它已经实现了整个产业的预期。在全球已经有很大一部分公司以某种形式在使用云服务了，无论这些公司的地理位置在哪里以及他们的专业领域是什么。

回头看看2008年，当时云计算的“期望夸大”（指虽然宣传力度很高，但无法继续推动）正处于巅峰期。某个价值数百亿美元的IT公司的CEO曾表示：

可以说，计算机产业是唯一一个比女性时尚更受时尚所驱动的产业了。也许我确实是个傻瓜，但是我真的不知道其它人都在说些什么。这到底是什么？

这一家IT巨擘由于忽视了这一趋势，目前已经被视为这方面的落后者，它的财富也在不断下滑。但近几年他们也参与到云计算的竞争中，并试图努力追赶领先者的脚步！因此，重要的是为你的转变进行计划，而不要等到为时已晚再开始行动。

关于作者

Basant Singh是一位软件开发者，具有12年应用程序及数据库架构设计的经验。在过去五年间，他通过他的编程技术帮助初创公司超越最小可行产品这一阶段。目前，他正充满热情地投入到他的下一个项目中，它使用了Go编程语言与Docker技术。在他职业生涯的前期受雇于某个跨国企业时，他为全球各处的财富500强上的客户创建了多个应用程序。

他的博客是Techno-Pulse和GolangPro。Twitter帐号是@SinghBasant。

软件组织正在快速地实施云技术，但迁移始终是一个无法回避的挑战。哪些部分是需要你密切留意的？哪些应用程序更适合于进行迁移？如何对应用程序进行重构以适用于云端？经历了这一转变的先行者为我们留下了什么启示？在这一系列文章中，你将从那些在帮助企业成功地迁移至云环境方面富有经验的专家那里获得实用的建议。这一领域应得到高度关注，我们希望你也能够参与这方面的讨论。

本文是InfoQ的“云迁移”系列文章中的一篇，你可以通过RSS订阅获取关于新文章的通知。

查看英文原文：Why You Should Definitely Migrate Existing Apps to the Cloud