云迁移的全方位解析 —— 与 Tim Beerman 的问答录

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

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

许多云提供商都会提供各种服务，以帮助新客户接入（onboarding）云平台。这些云提供商是否能够为我们准备迁移的过程提出一些建议，有哪些要避免的陷阱？为了更好的了解这些问题，InfoQ 有幸与CenturyLink 的产品战略与开发副总裁Tim Beerman 进行了一次访谈。

InfoQ：从你的过往经验来看，除了迁移之外，还有哪些内容也属于“接入”过程的一部分？

Tim：接入是一个非常广义的术语，对于不同的客户可以表示不同的意义。一般来说，一次成功的平台接入过程需要完成三个主要的目标，这三个目标的最终目的是实现一种令人满意的客户体验，这种体验将遍及整个客户关系。这三个主要目标分别是：

1) 对平台进行常规介绍，并设定期望及目标（例如：通过这次接入过程，客户希望能够实现什么目的？）。

2) 为了实现第 1 步中所定义的目标而进行帐号的配置以及动手训练。以及

3) 通过详尽的闭门会议进行讨论，让客户了解如何与整个平台支持模型建立起联系，以及在持续学习与更新时有哪些工具与知识库可以参考。

我喜欢采用这种比喻方式：一次优秀的接入计划应当能够做到“授人以渔”，让客户了解如何通过这些可用的自服务能力做到自给自足。当然，对于不同的客户来说，运维的规模不同也会导致不同的需求。因此整个接入计划也应适当地进行调整，而不是试图找到某种“万全之策”。

InfoQ：迁移过程中的哪些方面可能会比预期中更快完成，而哪些方面可能会迟于预期呢？

Tim：显然，在迁移过程中存在着大量的变数，答案很大程度上取决于整体环境的复杂度。许多人都认为，只要使用一个镜像文件，启动迁移过程，然后在目标平台上将应用部署好，整个过程就这么简单。但在启动这一流程时有许多东西需要你深思熟虑，包括许可、IP 地址、现有的应用在目标平台上的性能差别等等。如果能够提前对这些因素进行认真地规划与思考，就可以为整个过程节省大量的时间与精力。有一方面的工作往往能够比使用者预计中更快地完成，那就是目标网站的实际启动。如果能够根据迁移方式的不同采用适当的自动化功能与工具，常规的配置过程就能够快速完成。

InfoQ：在你看来，软件组织一般会选择自行开展迁移过程，随后在过程中寻求帮助，还是选择在他人的指导下开展迁移呢？

Tim：许多客户在迁移到云平台时都会考虑到云平台所提供的自服务灵活性，因此许多人会选择自行开展迁移工作。尤其是如果目标平台提供了优秀的文档，以及易于使用的迁移工具，例如镜像导入的情况下，这种倾向更为明显。这种方式能够让客户有更好的机会真正地了解他们将要开展工作的这个平台。话虽如此，但一个强壮的接入计划还是会表现出其价值所在，它为客户提供了一种了解新平台的方方面面的机会，并在开始时辅以一些专业的指导。

InfoQ：有哪些类型的应用是你不建议迁移至云平台的呢？

Tim：如果某些应用依赖于数据源（例如数据库或大型机等等）进行事务操作，而这些数据源与云平台的位置相距较远，那么这些应用就并非迁移至云平台的最佳选择。此外，有些应用在设计时就是针对物理服务器而非虚拟机，这些应用也不适合进行云迁移，因为其硬件架构或许无法满足需求，也有可能因为存储类型的不同（FC 与 iSCSI 或 NFS 的差别）导致影响性能，或是许可方式不匹配等等。当然，如果你的云提供商能够在其云平台上提供物理服务器，那么这一点就不成问题了。（够无耻的，哈哈）

InfoQ：通常来说，你会选择将一个完整的系统（包括 web、应用与数据库服务器）迁移至云端，还是只选择其中的一个子集？如果是后者，你又如何避免对性能造成的负面影响？

Tim：这个问题很大程度上取决于应用环境的整体规模与复杂度，以及源平台与目标平台之间的延迟性。如果可能的话，最好是将整个环境迁移至云端，而如果数据中心之间的距离造成的延迟变成了一个严重的问题，那么这也是唯一的一种选择。而如果这种延迟是可以接受的，并且必须对整个系统进行划分，那么最好的方式是先将应用与应用程序层进行迁移（web 层的迁移过程通常是非常顺利的）。如果由于系统划分之外的原因导致了某种问题，可以更方便地将 web 层切换回原本的数据中心（例如切换 DNS），而不用对数据库进行再次同步。

InfoQ：你的团队如何验证整个迁移过程是否成功呢？

Tim：对于迁移过程来说，验证是一个非常重要的收尾步骤。实际上，在整个迁移过程中，有一些步骤已经执行了相应的验证过程，例如在数据传输步骤对每个组件分别进行校验和的验证。一般来说，当新的环境搭建好之后，在最后的切换步骤之前，通常会在一段时间之内并行地运行两个环境（一个作为生产环境，而另一个用于测试）以确保应用程序能够正常工作，并且性能表现达到预期。如果对应用的表现感到满意，就可以与客户共同进行最后的数据同步工作，并切换至最终的生产环境中。同时保留原始的环境不变，在一段时间内起到验证作用。当然，较小的、或复杂度较低的环境不用做到这种程度的严谨，切换与验证过程也能够很快地完成。无论是哪种情况，我们都要耐心等待客户竖起大拇指，表现出他们对新环境的满意，并且做好必要的支持，帮助他们做出最后的决定。

InfoQ**：迁移至 SaaS或 PaaS平台与迁移至 IaaS**环境相比，有什么不同之处呢？

Tim：SaaS 或 PaaS 平台的迁移过程各自面临着不同的挑战，但与 IaaS 环境相比，最大的区别在于其硬件概念已经被抽象了，你在很大程度上所处理的都是与环境配置和数据传输相关的操作。如果某个客户打算迁移到某个 SaaS 环境，那么很多情况下他们都是从一个 SaaS 提供商迁移至另一家提供类似服务的提供商。在这一场景中，最复杂的过程在于将数据元素从一个 SaaS 应用映射到另一个 SaaS 应用，以尽可能实现一种无缝的数据传输。有些 SaaS 提供商为了简化这一过程提供了一些工具，这一点有助于他们在与竞争者较劲时占得市场先机。PaaS 的情况可能会简单许多，尤其在你的目标提供商也提供了相同的 PaaS 框架（例如 Ruby、LAMP 等等）时体现得更为明显。在这种情况下，迁移过程的主要任务就是数据传输，但你也要仔细地考虑一下新提供商的性能差别与收费方式的差异。

InfoQ：当你与客户首次谈到迁移时，所需要化解的最大的误解是什么？

Tim：在大多数情况下，客户在进行迁移时都是小心翼翼的，因为这一过程有可能会对他们的业务带来干扰。最大的挑战在于，许多客户将云平台设想为一个完全冗余的环境，即一旦某个组件产生了故障，云平台将无缝地切换至另一个进程或虚拟机。客户之所以会有这种想法，是由于他们习惯于利用常见的虚拟技术打造内部的云环境，并对虚拟机进行配置以满足他们的需求。而当你转移到公有云平台时，需要了解一点，这些平台是为了大规模应用，以及满足尽可能多的客户需求而创建的，所以它们的运行与处理组件可用性的方式可能会有所区别。因此，在迁移流程开始时，期望的设定是一个关键的因素。在我们所经历的许多案例中，我们都会建议客户在迁移过程中好好地了解一下他们的应用程序，看看是否能对其进行一些改进，以充分利用云平台的灵活性，包括自动伸缩、地区差异性等等。这并不是一项轻松的任务，但通过让客户了解所有这些可能性，就能够让他们在迁移过程中做出适合自己的最佳选择，或是让追随者快速地理解新的平台，以保证这次云迁移项目在长期范围内的成功。

InfoQ：当企业将本地应用迁移到云环境时，有哪些现有的工具是大多数企业都希望继续使用的？

Tim：客户希望继续使用的常见工具包括特定于应用程序的票据（追踪）系统以及监控系统，以尽量减少对于当前的运维流程的影响。因此让客户理解全新的云平台所提供的 API 功能相当重要，客户可以通过这种功能以编程的方式使新的云平台与现有的系统进行交互。

InfoQ：以你看来，在进行切换时，有哪种技术是大多数企业都会使用的？他们是否能够接受停机时间，还是会尽量尝试各种技术，以确保应用始终在线呢？

Tim：和其它许多问题一样，这一点很大程度上取决于客户的应用程序，以及他们的整体业务模型。对于成熟的、“为云环境而生”的企业来说，他们经常会将应用程序设计为一种分布式的架构，可经受新的目标平台的能力的考验，并且在迁移时的停机时间极短、甚至为零。虽然这一趋势正在不断发展中，但能够实现这一点的企业毕竟是少数。对于其它企业来说，如果应用程序在设计时没有考虑到这一点（包括 IP 地址设置、分布式的负载均衡、数据同步等等），那么要计划并实行零停机时间的迁移过程通常是不切实际的。话虽如此，但现在市面上已经出现了大量的工具，通过它们的帮助，完全有可能在某个确定的维护窗口时间内计划并出色地完成切换动作。像 Rackware、Racemi 等工具允许客户在目标平台上与原地址中的每台虚拟机之间建立一种关联，将整个虚拟机（包括应用与数据）经过一段时间复制到迁移目标平台上，而不影响生产环境的正常运行。客户也可以随时“中断”这种复制的关联，在新的平台上对应用进行测试，然后在切换到生产环境时重新建立这一关联，并进行最终的同步工作。

InfoQ：运维部门经常被人们视为实施云接入的妨碍者（或许这一坏名声是他们不应得的？），从你的经验来看事实是否确实如此？是否有哪个部门有可能会拖慢云迁移的过程？

Tim：坦白的说，运维部门对于由他们负责维护的应用程序通常具有很强的防备意识，对于那些可能会影响他们现有的流程、步骤、工具与专业知识的变更会表现得很谨慎。运维部门所担心的另一件事在于他们可能会失去控制权，甚至有可能遭遇裁员，原因是他们的职能已经没有存在的必要性了。就这点而论，我并不想将他们描绘为妨碍者，而是迁移计划流程中的关键干系人。重要的是要让运维团队充分理解，新的云环境能够很大程度上改进他们现有的环境，因为他们能够通过利用健壮的 API 更好地获取运行环境的实时数据，甚至将更多的日常工作实现自动化，从而能够关注于在业务支持方面表现得更为积极主动。这是进行一次超前思维的良机，运维团队能够因此学习到新的技能，而公司也能够对更广泛的 DevOps 这一话题进行评估，以支持他们的应用。关于这一点恐怕得再专门再经过一次采访才能说明白，这里就不展开讨论了。J

InfoQ：在迁移过程中，你所遇到过的最复杂的技术性挑战是什么？

Tim：整个迁移过程中会产生许多复杂性，但最复杂的技术性挑战是在不同的架构之间进行迁移。如果是从某个云环境迁移至另一个云环境，整个过程通常会比较顺利，因为应用程序一般来说已经为云环境进行过优化了，你只需要负责云实现中的变更就可以了。真正的挑战通常发生在客户首次迁移到云环境的过程中，尤其是他们的应用尚未实现虚拟化的情况下。最重要的注意事项主要包括以下几点：

• 许多商业技术产品的许可协议在云平台上可能会有所区别，甚至完全不支持
• 云平台上的 IP 地址与原地址往往是不同的，如果在应用中对 IP 进行了硬编码，就必须进行代码改动
• 现有应用平台的组件，例如集群协议往往在云环境中不支持
• 当前的应用如果对基础设施存在依赖性，在进行云部署时通常要经历架构上的转变
• 某些应用平台组件及底层的中间件和操作系统可能会直接绑定到现有的服务器硬件平台上，这也是可能要解决的问题之一
• 云环境的性能基准往往与现有的平台不同，并且通常比现有的基础设施有所改进，但这需要对现有的应用程序系统架构进行修正，才能够充分利用改进后的性能
• 如果将应用从本地数据中心迁移至云平台，用户的功能与体验或许会受到网络延迟所带来的负面影响，而这种影响有时必须通过对应用的架构进行重新设计才能够消除
• 如果现有的负载均衡器或安全控制的实现具有专利权，那么在新的云环境中或许要重新设计架构
• 在迁移过程中，可能还要处理服务 / 系统部署生命周期管理工具，以及例如监控、备份、恢复、自动化（配置、构建、补丁及部署）及 ITIL 等流程化工具所面临的问题

InfoQ：要做到“为迁移做好准备”，企业应当怎么做呢？

Tim：如果企业打算为迁移做好准备，那么他们所能做的最好的一点就是在充分了解的前提下开始迁移流程，并且保持一种开放的态度。首先，要充分的理解准备进行迁移的应用程序的各方面知识。我经常看到有些企业在没有完全理解应用程序需要哪些相关设施才能有效运行的情况下，就开始启动迁移过程。这些相关的内容包括数据源、一些尚未准备进行迁移的其它应用程序依赖，以及为了启动通信所必须的端口号与协议。如果客户启动了迁移过程，却发现应用程序由于某个未知的依赖而无法按计划运行，客户会感觉十分受挫。企业也应当充分了解他们所选择的云平台的能力，以及某些潜在的限制。这种能力不仅包括技术能力，还包括 SLA、收费模式、如何寻求支持、以及为了满足运维方面的期待，目标平台是否能够提供高级支持模式，并且是否有这种必要等等。最后一点，在迁移过程中要保持一个开放的态度。将业务迁移到云平台，能够为企业进行应用程序设计与未来的开发的方式带来许多新的机会，而为了把握住这种机会，通常需要你改变思考与运营的方式。如果企业在进行迁移时始终保持着一种观点，要求“所有功能”都必须保证如同之前一样运行，那么结果往往是令人沮丧、不尽人意的。

关于受访者

Tim Beerman是 Centurylink 公司的产品战略与开发部的副总裁，他专注于平台的迁移与接入战略。自从 2008 年加入 Centurylink 以来，Tim 就一直担任高级领导职位，负责世界级的基础设施产品与应用程序解决方案，这也是该公司主机托管服务业务的支柱。就在最近，在他的战略指导下，团队实现了将 CenturyLink 的托管服务产品套件转移到核心的 Centurylink Cloud 平台，将应对今后不断涌现的托管服务的基础搭建在一个单一的统一平台上。目前，Tim 负责建立一项策略，让 Centurylink Platform 上的客户能够专注于将遗留产品与服务迁移到云平台上，并且为来自核心渠道的新客户打造一种易于使用的、无痛的接入服务。

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

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

查看英文原文： Anatomy of a Cloud Migration Program: Q&A with Tim Beerman