云迁移策略误解

我们将揭穿关于将您的工作负载迁移到像 AWS 这样的大型云提供商的常见误解。

您已承诺进行云迁移。太好了。但您需要将数据从现有系统迁移到新系统。

没问题，您想。您知道正确的做法！

或者您真的知道吗？一些经验丰富的技术专家表示，许多人会犯下错误的假设，这不仅浪费时间和金钱，还会带来不必要的挫败感。对于一个不再新鲜的事物来说，关于云迁移的显著误解仍然普遍存在。即使问题是迁移过程的实际操作（即我们在此讨论的数据传输过程），而不是普遍的云操作误解，情况也是如此。

我们将探讨导致人们产生这些错误想法的原因，解释实际情况，并提供资源帮助您了解更多信息。

#1：您应该始终从“提升和转移”（lift and shift）开始您的云迁移计划。

一个常见的云迁移误解是，您应该始终使用“提升和转移”方法来尽快将您的工作负载迁移到云端。“提升和转移”意味着将应用程序和数据按原样从本地环境迁移到云供应商的基础设施，而无需针对云进行重新架构。只需将它们迁移过去，稍后再考虑重新设计！

许多公司都怀着最好的意愿采用这种策略。他们先采用提升和转移的方式，以便尽快将所有内容迁移到云端，并制定了宏伟计划，打算稍后再将所有内容重写为云原生应用。剧透警告：公司通常永远不会真正实现这一点。

通常，以这种方式开始迁移有正当的理由。这似乎是将工作负载迁移到云端最快的方式——就像将所有物品扔进箱子，搬进新家后再整理一样。有时，确实存在紧急需求，需要将工作负载从物理本地服务器迁移到云端，这些理由是合理的，例如办公室租赁终止、公司收购，或者担心老化设备存在故障风险（“我们需要在为时过晚之前将关键应用程序从这艘正在下沉的船上转移出去！”）。

现实情况：有时“提升和转移”方法是正确的。但它不应该是您云迁移策略的默认选择。

需要深思熟虑的一个例子是，当遗留系统的技术架构过时，并且新云环境中没有同等的技术组件时。在这种情况下，您实际上别无选择。您无法进行提升和转移，因为没有可以“转移”到的并行系统。

有时，迁移的决定是因为您现有的许可成本过高，并且您在云中找到了替代技术。但在这种情况下，最好是淘汰旧系统。花时间从头重构和重新架构应用程序，重新建模数据，并在云中运行新的云原生版本。因为虽然您可以将所有物品随意扔进箱子，然后搬到新家后再整理，但如果您能以更有条理的方式进行，这样做就显得很傻。至少，这意味着您在第一个早上更容易找到咖啡机。

误解在于您应该始终从提升和转移开始。问题在于“始终”。有时这确实是开始的正确方法。如果您在开发本地应用程序时的策略始终是云优先——例如，您在本地环境中使用容器化技术——那么将工作负载提升和转移到云端就非常容易，因为它们在云端运行的方式与在本地环境中的运行方式相同。

因此，如果您从一开始就在本地应用程序中使用了虚拟化技术，那么您就已经为云做好了准备；提升和转移是合理的。（AWS 提供有用的自动化工具，例如 AWS Application Migration Service 来帮助您入门。）

#2：您可以独自处理云迁移。您已经知道所有需要知道的事情。

许多公司认为云迁移可以由一小队内部多面手处理，或者认为聘请顾问或承包商处理迁移，完成后再将维护工作移交给内部团队是个好主意。一个相关的误解是，迁移到云端后可以节省人员成本。

但这并非必然如此。

现实情况：迁移到云端是一个复杂的过程，需要具备深厚云技术专业知识的主题专家来管理项目。成功的迁移需要一个经验丰富的团队。理想情况下，这些人员应包括迁移解决方案架构师、数据架构师、云解决方案架构师、企业架构师以及 IT 或 DevOps 工程师。这些都是专业技能，虽然一个人可以身兼多职，但这些角色是不可互换的。

迁移完成后，这些角色也并非多余。云迁移很少是一次性事件，特别是对于拥有众多遗留应用程序需要逐步迁移到云端的大型公司而言。此外，数据驻留要求通常需要一些上游或下游系统保留在本地，并且您必须在云环境和本地环境之间维护双向路径。在这种情况下，您需要留住那些经验丰富的云专家来维护这些复杂的系统。

选择顾问/承包商的方式会带来自身的一系列问题。项目完成后，移交给内部团队的过程通常仓促且突然，您现有的员工并不理解他们未参与构建的系统的复杂性。顾问也并非总是专注于构建一个可维护的系统，因此在他们提交成果几个月后，系统就可能过时了。

所有这些因素都说明了确保您拥有合适的团队来处理迁移以及后续维护系统的重要性。

#3：您应该先迁移最不重要的工作负载，以便提前测试流程。

当公司开始将其数据和应用程序迁移到云端时，从小处着手是很自然的。通常会先迁移最不重要、依赖最少的工作负载，以便团队学习流程并对迁移的技术要求建立信心。事实上，这是一种推荐的方法，AWS 提供关于如何优先处理应用程序进行初始迁移的建议，包括选择低风险、低复杂度的工作负载，以降低初始风险。

但是仅仅选择“最不重要”的应用程序并非必然是正确的方法。

现实情况：您应该进行云准备度评估，以确定工作负载的优先级。将其作为您云迁移计划的关键部分。

您应该优先迁移哪些工作负载？理想情况下，选择一个业务影响最大而风险最低的工作负载。保持整个过程迭代进行。在学习过程和建立信心的同时，以小增量、循序渐进（crawl-walk-run）的方式进行迁移。

但在您学习的同时，您也希望交付价值。没有哪家公司希望在没有看到任何商业价值的情况下投资云。工作负载评估的一部分应该包括“什么能让老板印象深刻？”，即使您在报告中没有这样措辞。

云迁移可能也不是“边干边学”的最佳时机。这是一个复杂的过程，应该由具备云专业知识的团队来管理。这些专业人员应该知道如何最好地确定初始迁移工作负载的优先级，确保云迁移计划能快速为业务带来价值。

#4：期望迁移完成后立即获得相似或更好的 SLA。

很容易将本地遗留系统视为陈旧过时的，而云则以尖端先进技术著称。因此，技术人员可能会认为一旦将工作负载迁移到云端，就能立即获得相似或更好的 SLA。

如果您多年来一直开着一辆老爷车，然后买了一辆新的跑车，那么在您把新车开出停车场的那一刻，期望它能快得多是很自然的。但对于云迁移来说，情况并非总是如此。

现实情况：当您将现有的基础设施和系统架构迁移到云端时，它不一定能以同样的方式运行。也不一定会立即变得更快或更好。即使您在新跑车的第一天就能获得更好的驾乘体验，这可能也会以其他方面的牺牲为代价，例如燃油效率和熟悉度。

提高 SLA 是一个值得称赞的目标。但是，与数据迁移到云端的任何其他环节一样，它需要规划。

首先，定义您现有系统的 SLA 及其配置。然后在云端运行单独的基准测试，以确定这些 SLA 如何受到影响。是因为系统架构中的额外跳数导致延迟增加，还是快得多？在新云环境中定义这些 SLA，然后根据系统要求选择相应的云资源。接着调整配置以实现所需的 SLA。

这项工作通常由您迁移团队中的云架构师、数据架构师和迁移解决方案架构师完成。只有在完成所有这些仔细的配置工作后，您才应该进行实际的迁移。

#5：将工作负载迁移到云端后，就不需要复杂的复制和故障转移计划了。

另一个误解是，如果您将所有架构和技术栈迁移到云端，就不再需要复杂的复制和故障转移计划来保护应用程序了。这种想法认为，一旦您的工作负载进入云端，它们就是“安全的”，就像备份到云存储中的文件一样。

这种想法可能源于将云抽象为非物理空间，与本地服务器非常明显的物理存在形成对比，后者显然容易受到自然灾害和其他破坏性事件的损害。但这是一种危险的想法。

现实情况：这是一个误解，认为只要将应用程序、架构和完整的技术栈迁移到云端，复制、故障转移和高可用性就都得到保障了。事实并非如此。实际情况取决于您如何配置您的云实例。

将工作负载迁移到云端时，您必须选择是否将其跨多个区域运行。整个云和全球基础设施被划分为多个区域，每个区域内都有数据中心，也称为可用区（AZs）。例如，AWS Cloud 目前在全球 31 个地理区域内拥有 99 个可用区，并且亚马逊计划进一步扩展。您可以将这些可用区视为“数据中心”，每个可用区之间至少相距 150 英里。您可以在云端设计和部署一个应用程序，并将其部署到单个区域；如果发生地震等自然灾害导致系统宕机，那么您的整个应用程序也会随之宕机。但如果您选择多区域部署，您的应用程序将具备故障转移保护。所以这实际上取决于您如何设计您的部署。

如果您当前在本地运行系统，您总是希望拥有多个数据副本和多个服务器实例运行，这样即使其中一个发生故障，您的数据也能得到备份和保护。但现在您的组织已决定迁移到云端。您可以先只迁移最基本的部分，即应用程序的单个副本，让它在云端运行起来，看看它的性能如何，然后在此基础上继续。或者，您可以将其全部复杂性一并迁移——包括复制故障转移、整个技术栈。但如果您这样做，您将把更多复杂性带到云端，甚至不知道它在那里将如何运行。

不要进一步复杂化您的迁移项目。按原样迁移应用程序，不要担心所有附加功能（bells and whistles）。将应用程序最简单的形式迁移到云端，看看效果如何。在核心功能在云端运行正常，并且您可以向上级管理层展示其价值之后，再添加高可用性、故障转移和复制等方面的内容。

云的召唤

一个执行良好的云迁移计划需要仔细的规划、专家的指导以及一个有效优先处理工作负载的阶段性方法。明智地抓住机遇并应对云采用的挑战，确保您的应用程序和数据迁移过程成功且高效。

有关如何启动云迁移的详细分步说明，请阅读这本有用的指南：Migrate Redis Workloads to Redis Enterprise Cloud on AWS。

特别感谢 Redis 高级云解决方案架构师 Srinivas Pendyala 为本文提供的见解和帮助。