视频
关于微服务的 5 个误解
了解更多
快速的未来正在你所在的城市举办活动。
加入我们参加 Redis 发布会
分享
我们揭穿了将工作负载迁移到大型云提供商（如 AWS）的持续误解。
你致力于云迁移。很好。但你需要将数据从现有的系统中迁移到新的系统中。
你认为没问题。你知道如何去做!
真的是这样吗？一些经验丰富的技术专家建议，许多人做出了错误的假设，导致浪费时间和金钱，并造成不必要的挫折。对于不再显得新奇的事情，关于迁移到云的误解仍然很多。即使问题是迁移过程的实际问题——数据传输过程，正如我们在这里讨论的那样——而不是对在云中运行的整体误解。
我们探讨了是什么导致人们产生这些错误的想法，解释了现实情况，并提供了资源来帮助你了解更多信息。
一个常见的云迁移误解是，你应该始终使用“提升和迁移”方法，以便尽快将你的工作负载迁移到云中。“提升和迁移”意味着将应用程序和数据从内部部署环境移植到云供应商基础设施，而无需对它们进行云原生化重构。只需将其迁移过来，稍后再考虑重新设计！
许多公司以最好的意愿实施了这种策略。他们从提升和迁移开始，以尽快将所有内容迁移到云中，并且他们有宏伟的计划，计划在稍后将所有内容重写为云原生。剧透警报：公司经常无法实现这一目标。
通常有充分的理由以这种方式开始迁移。这似乎是最快将工作负载迁移到云中的方法——就像把所有物品都扔进箱子里，并在搬到新家后进行整理一样。有时，迫切需要将工作负载从物理内部部署服务器迁移到云中，这些理由是合理的，例如办公室租赁终止、公司收购或对可能发生故障的旧设备的担忧（“我们需要在为时已晚之前将我们的关键应用程序从这艘沉船上移走！”）。
**现实：**有时，“提升和迁移”方法是正确的。但它不应该成为你的云迁移策略的默认选择。
需要仔细考虑的一个例子是，当遗留系统技术架构过时，并且在新的云环境中没有等效的技术组件时。在这种情况下，你实际上别无选择。你无法提升和迁移，因为没有可供“迁移”的并行系统。
有时，迁移的决定是出于这样的动机：你的现有许可成本过高，并且你在云中找到了替代技术。但在这种情况下，最好是淘汰旧系统。花时间从头开始重构和重新设计应用程序，重新设计数据，并在云中运行这个新的云原生版本。因为虽然你*可以*将所有物品都扔进随机的箱子里，并在新房子里整理出来，但如果你能够以更井然有序的方式进行处理，那么这样做就很愚蠢。如果别无他法，这意味着你更有可能在第一个早上找到咖啡机。
误解在于你应该始终从提升和迁移开始。问题在于“始终”。有时它实际上是正确的方法。如果你在开发内部部署应用程序时始终以云优先为策略——例如，你在内部部署环境中使用容器化技术——那么将工作负载迁移到云就非常容易，因为它们在云中运行的方式与在内部部署环境中相同。
因此，如果你从一开始就在你的内部部署应用程序中使用虚拟化技术，那么你已经做好了云准备；提升和迁移是有意义的。（AWS 提供了有用的自动化工具，例如AWS 应用程序迁移服务，以帮助你入门。）
许多公司认为，云迁移可以由内部的一小群通用专家处理，或者聘请顾问或承包商来处理迁移，并在完成后将维护工作移交给内部团队。一个相关的误解是，你可以在迁移到云后节省员工成本。
但这并不一定正确。
**现实：**迁移到云是一个复杂的过程，需要具有深厚云技术专业知识的主题专家来管理项目。成功的迁移需要一个经验丰富的团队。理想情况下，这些人包括迁移解决方案架构师、数据架构师、云解决方案架构师、企业架构师以及 IT 或 DevOps 工程师。这些是专门的技能，虽然一个人可以身兼多职，但这些角色不可互换。
迁移完成后，这些角色并非多余。云迁移很少是一次性事件，特别是对于随着时间的推移需要将大量遗留应用程序迁移到云中的大型公司而言。此外，数据驻留要求通常需要一些上游或下游系统保留在内部部署环境中，并且你必须维护云环境与内部部署环境之间的双向路径。在这种情况下，你需要保留这些经验丰富的云专家来维护这些复杂的系统。
采用顾问/承包商的方式也会带来自身的问题。通常，项目完成后向内部团队移交工作会很匆忙，而且你现有的员工不了解他们没有参与构建的系统的复杂性。顾问也不总是专注于构建可维护的系统，因此在他们完成交付后几个月内，系统就会过时。
所有这些因素都是为什么确保你拥有合适的团队来处理迁移以及随后的系统维护如此重要的原因。
当一家公司开始将其数据和应用程序迁移到云时，从小型开始是自然的想法。通常的做法是从迁移依赖关系最少、最不重要的工作负载开始，以便团队能够学习流程，并对迁移的技术要求充满信心。事实上，这是一个推荐的方法，AWS 提供了有关如何优先考虑应用程序以进行初始迁移的建议，包括选择低风险、低复杂性的工作负载，以降低开始时的风险。
但仅仅选择“最不重要的”应用程序并不一定正确。
**现实：**你应该进行云就绪评估，以优先考虑你的工作负载。使这成为你的云迁移计划的关键部分。
你应该首先迁移哪些工作负载？理想情况下，选择一个对业务影响最大，但风险最小的工作负载。保持整个过程迭代。以增量方式迁移，采用爬行-行走-奔跑的方式，随着你学习流程并获得信心，逐渐提升。
但是，在你学习的同时，你也希望创造价值。没有哪家公司希望在没有看到一些商业价值的情况下投资云。工作负载评估的一部分应该包括“如何让老板印象深刻？”，即使你在报告中没有这样说。
云迁移也不一定是“边学边做”的最佳时机。这是一个复杂的过程，应该由具有云专业知识的团队管理。这些专业人员应该知道如何最好地优先考虑用于初始迁移的工作负载，确保云迁移计划能够快速为企业带来价值。
很容易将内部部署遗留系统视为过时和过时的，而云则以尖端、先进技术而闻名。因此，技术人员可以假设，一旦他们将工作负载迁移到云，他们将立即获得类似或更好的 SLA。
如果你驾驶一辆旧的破车多年，然后买了一辆新的跑车，那么你期待一下车从停车场开出来的那一刻起，你的驾驶体验就会快很多，这是有道理的。但对于云迁移而言，情况并非总是如此。
**现实：**当你将现有基础设施和系统架构迁移到云时，它不会以相同的方式运行。它也不会立即变得更快或更好。虽然你可能会在第一天获得更好的跑车驾驶体验，但这可能会以其他方面的牺牲为代价，例如燃油效率和熟悉程度。
提高 SLA 是一个值得称赞的目标。但是，与将数据迁移到云中的任何其他元素一样，这需要计划。
首先，定义现有系统的 SLA 及其配置。然后在云中运行一个单独的基准测试，以确定这些 SLA 会受到什么影响。由于系统架构中的额外跳转，延迟是否增加了，还是快了很多？在新的云环境中定义这些 SLA，然后根据系统要求选择你的云资源。然后调整配置以实现这些所需的 SLA。
这些工作通常由您迁移团队中的云架构师、数据架构师和迁移解决方案架构师完成。只有在您完成所有这些仔细的配置后，您才应该进行实际迁移。
另一个误解是，如果您将所有架构和技术堆栈迁移到云中，您将不再需要复杂的复制和故障转移计划来保护应用程序。人们认为，一旦您的工作负载位于云中，它们就“安全”，就像备份到云存储中的文件一样。
这种想法可能源于将云抽象为非物理空间，而不是物理存在的本地服务器，本地服务器显然容易受到自然灾害和其他破坏性事件的损坏。但这是一个危险的想法。
现实情况：将应用程序、架构和完整技术堆栈迁移到云中，并不意味着复制、故障转移和高可用性就得到完全保证。并非如此。事实是，这取决于您如何配置云实例。
将您的工作负载迁移到云中时，您必须选择是否跨多个区域运行它们。整个云和全球基础设施被划分为区域，每个区域内都有数据中心，也称为可用区 (AZ)。例如，AWS 云目前跨越全球 31 个地理区域的 99 个可用区，亚马逊计划扩展它。您可以将这些可用区视为“数据中心”，每个数据中心彼此至少相距 150 英里。您可以在云中设计和部署应用程序，并将其仅迁移到一个区域；如果发生地震等自然灾害导致系统瘫痪，您的整个应用程序也将瘫痪。但如果您选择多区域部署，您的应用程序将具有故障转移保护。因此，这实际上取决于您如何设计部署。
如果您目前在本地运行系统，您始终希望拥有多个数据副本和多个正在运行的服务器实例，以便如果一个实例出现故障，您的数据将得到备份，您也将受到保护。但是现在您的组织已经决定迁移到云中。您只需将最基本的，您应用程序的单个副本先迁移到云中，让它在云中运行，观察其性能，然后从那里开始。或者，您可以将所有复杂性都迁移到云中，包括复制故障转移、整个技术堆栈。但如果您这样做，您将给云带来更多复杂性，而您甚至不知道它将在云中如何运行。
不要让您的迁移项目更加复杂。按原样迁移应用程序，不要担心所有的花里胡哨。将应用程序的最简单形式迁移到云中，看看效果如何。在基本的云功能正常运行后，您可以向高层管理人员展示其价值，然后添加高可用性方面、故障转移方面、复制方面。
一个执行良好的云迁移计划需要仔细的规划、专家指导和分阶段方法，有效地优先考虑工作负载。明智地抓住云采用的机遇，应对挑战，确保应用程序和数据的迁移过程成功高效。
有关如何启动云迁移的分步说明，请阅读本实用指南：将 Redis 工作负载迁移到 AWS 上的 Redis 企业云。
非常感谢 Redis 高级云解决方案架构师 Srinivas Pendyala 提供的见解和帮助。
