迁移到 AWS 云注意事项

发布时间：2022-12-14 09:17 所属栏目：124 来源：互联网

导读：如果有一天，您被告知迁移到 AWS/GCP/Azure/任何其他云提供商怎么办？轻描淡写可能会带来一些压力，对吗？在我的职业生涯中，我见过不少迁移，在这篇文章中，我想分享一些想法，以帮助 DevOps 工程师、架构师、经理或任何其他可能参与此类迁移的人。我专注

　　如果有一天，您被告知迁移到 AWS/GCP/Azure/任何其他云提供商怎么办？轻描淡写可能会带来一些压力，对吗？

　　在我的职业生涯中，我见过不少迁移，在这篇文章中，我想分享一些想法，以帮助 DevOps 工程师、架构师、经理或任何其他可能参与此类迁移的人。我专注于迁移到 AWS 主要是因为我在这个主题上有专长并且因为它相当普遍，但我认为这些经验适用于任何其他云提供商。对于这种情况，我将介绍从本地到云的迁移，因为这些类型的迁移（在我看来）比云到云的迁移要困难得多。我还将分享我自己对迁移的注意事项的看法。但请通过批判性思维过滤它们，并记住每个人都有自己的背景和经验。对一个人有利的事情可能对另一个人不利。

　　什么是云迁移？
　　让我们从定义什么是迁移开始。你怎么知道它是否是迁移？我喜欢下面的定义：

　　云迁移是将数据中心的功能转移到 IaaS 提供商的过程。

　　“能力”是关键词。企业不会迁移服务器/虚拟机/硬件/数据或其他任何东西。企业迁移其能力。

　　有七种迁移策略（或七个 Rs）：重新定位、重新托管（提升和转移）、重新平台、重新购买、重新架构/重构、保留和退休。

　　例如，我曾见过一家公司正在开发一种新产品来取代现有的本地托管产品。该产品从一开始就设计为架构良好且云原生，并将托管在云中。是迁移还是绿地项目类型？从上面的定义，我们可以说这是一个迁移。这是迁移的重构策略。

　　如果我们购买新的 SaaS 订阅而不是我们在本地托管的某些软件怎么办？这也是一种迁移：一种回购策略。

　　让我们更深入地研究这七种迁移策略：

　　搬家。我们在本地托管一些工作负载，然后将它们按原样迁移到云端。这在有限的情况下是可能的；当我们迁移与云无关的工作负载或平台可能是云原生时。示例：将 Kubernetes 集群从本地迁移到云端或使用 VMware Cloud 迁移 VMware 机器。

　　重新托管。这也称为提升和转移。我们将本地虚拟机/服务器转换为云中的虚拟机。示例：使用 CloudEndure 将本地虚拟机迁移到 EC2 实例，或创建 EC2 实例，安装软件并应用与本地相同的配置。

　　重新平台化。我们在不重新构建系统的情况下将工作负载迁移到云原生平台。示例：将 PostgreSQL 迁移到 AWS RDS 或将 Docker 容器迁移到 ECS。

　　回购。我们用 SaaS 替换了一些自定义/遗留系统。示例：用 SendGrid 替换自定义本地电子邮件系统或用 Salesforce 替换 CRM。

　　重新设计。我们将您的应用程序架构更改为云原生并使用托管云服务。这还包括从头开始重建。示例：更改您的应用程序的代码以将文件上传到 S3 而不是本地存储或将应用程序容器化并迁移到 ECS。

　　退休。如果不需要，我们决定消除一部分工作量。示例：不再需要日志服务器，因为迁移的应用程序使用 CloudWatch。

　　保留。我们将其留在本地。通常，这是暂时的。示例：具有大量功能和自定义功能的庞大 Oracle 数据库由于巨大的成本而没有迁移到 AWS。它决定将其保留在本地，直到在现代化阶段被另一个解决方案取代。

　　我喜欢下图，它显示了每种迁移类型的高级阶段。它可能是处理迁移的有用备忘单。

　　迁移禁忌
　　在执行迁移时，我不建议执行以下操作：

　　迁移太快。企业可能会想，“我们必须快速迁移到云端。让我们现在就做升降机！最好不要马上开始。您确定重新托管策略真的会比其他策略更快吗？在一个实例中，我们尝试迁移本地 VM，但没有成功，因为机器上的操作系统很旧。某些操作系统级别的依赖项在 AWS 的硬件上不起作用。这需要大量的配置工作、自定义代码和测试，而最初的估计是完全错误的。它最终证明是一个重新平台。

　　评估你所拥有的，分析它，分析商业案例并思考。在这项工程工作中，我们应该静下心来，三思而后行。

　　没有明确目标的迁移。你为什么要移民？如果您无法回答问题，您可能需要找到答案或根本不迁移。我见过企业希望迁移到云以降低成本的情况。他们在没有进行总成本分析的情况下执行了直接迁移。只有在事后他们才意识到它的成本甚至比在托管中心时还要高。此迁移可能被认为是不成功的。

　　为避免这种情况，定义明确的目标并定义实现这些目标的目标状态。如果成本是驱动因素，请进行适当的计算并制定相应的计划。当您计划目标状态时，成本优化将是主要关注的事情。如果可用性是原因，请对其进行衡量，定义 SLO 并关注目标状态下的可用性。

　　黑盒迁移。不要将迁移的工作负载视为黑盒。了解您迁移的具体内容、它有什么技术要求、它有什么依赖关系以及它如何工作几乎是至关重要的。该信息将使您能够选择正确的工作负载迁移策略。如果不这样做，您很有可能会选择错误的路径并且结果会丢失。捕获有关系统的信息是规划时最重要的任务。

　　不要忘记架构良好的. 迁移是有压力的。这就是为什么人们倾向于尝试在尽可能短的时间内快速完成它，专注于唯一的事情：让一切尽快在云中运行。他们搁置了结构良好的框架支柱。这是个错误; 它可能会导致一系列不同严重程度的负面后果。不要忽视结构良好的框架支柱，否则在潜在问题或风险已经具体化之前，您不会知道它们。

　　一切都使用一种策略。为所有工作负载制定一个总体计划总是很容易的。例如，决定进行直接迁移，然后将所有内容重新托管在云中。但是，如果某些东西可以退役呢？如果可以不费吹灰之力地对某些组件进行平台改造会怎样？通过分析工作负载的所有组件并为每个组件确定独特的策略，您将节省大量资源。收集数据并妥善计划。

　　云迁移做的
　　执行云就绪评估。如果一个人迁移到新地点，他们应该考虑：

　　气候会有所不同
　　该位置使用的语言可能不同
　　生活成本会有所不同，而且可能会更贵
　　当一家公司迁移到云端时，他们应该提出的问题包括：

　　我们是否考虑了所有的风险？
　　必须更改什么才能使工作负载真正起作用？
　　我们是否拥有所有工作所需的人力资源？
　　我有完成所有事情的预算吗？
　　Cloud Readiness Assessment 是关于公司中不同流程的长篇访谈，用于确定公司是否已准备好在云中生活。它基于 Cloud Adoption Framework (CAF)，让我们了解应该更改哪些内容才能成功进行迁移。AWS 有一个涵盖所有这些的云就绪评估工具。我强烈建议您对考虑迁移的所有工作负载使用此过程。

　　创建一个商业案例。描述业务案例。迁移的驱动因素是什么？迁移解决了哪些问题？移民应该达到什么目标？具体一点：如果您打算降低成本，则计算总和。如果你打算提高可用性，那么定义一个明确的 SLO。这将是您迁移的第一推动力。所有其他工件都应该基于它。

　　自动发现和数据收集。使用自动数据收集和分析来创建迁移组合。不要将您的分析基于手动创建的电子表格或口头交流。让机器收集有关库存和使用统计信息的数据。您收集的数据越精确越好。在大多数情况下，AWS Migration Evaluator 服务将帮助您做到这一点。

　　投资组合管理。创建要迁移的工作负载组合，对其进行分析，为每个工作负载选择迁移策略，为试点/第一波迁移选择一些，估计时间表并准备计划。之后执行迁移。重复直到迁移组合为空。共享数据。让主题专家对其进行审查。

　　找到了 CCoE。这是上述 CAF 的一部分。在执行迁移之前，创建一个负责制定战略并定义云中良好生活标准的人员团队：卓越云中心。它应该包括具有各种主题专业知识的人员，包括管理、运营、平台、人员、财务以及在云中使用或提供服务的所有其他部门。这些人会为迁移准备一个登陆区，为登陆区准备硬政策和软政策；为公司在云中的生活做准备。不要害怕重新审视任何政策。随着新因素的出现，做出改变。

　　良好架构的框架审查 (WAFR)。在迁移浪潮期间和之后进行架构完善的框架审查 (WAFR)。这将使你避免愚蠢的错误，并从技术角度对你所做的事情有一个高层次的概述。

　　现代化计划。准备现代化计划和迁移计划。迁移不是故事的结局。要在云中发挥作用，您必须进行架构完善的审查和现代化改造。第一次现代化可能是巨大的；这就是为什么提前计划和安排预算和资源很重要。如果不这样做，将导致运营成本增加，而不是成本降低。

　　概括
　　如果我们想降低与迁移相关的风险并减轻压力，我们不会仓促行事。您可能认为仓促行事会节省您的时间，其他问题会在以后得到解决，但经验告诉我们这是错误的。最有可能的结果是，您将最终解决在最紧张的情况下遇到的所有问题：当您切换到新的基于云的生产环境时。不是经过深思熟虑和提前解决问题，而是在胁迫下做出选择。此处必须应用正确的工程原理。拿起一座桥并将其从一条河流中移到另一条河流上是行不通的。迁移成功的关键是衡量、分析、设计和计划。将工作负载迁移到云端很困难，但我希望这些该做的和不该做的会让事情变得更容易。

（编辑：ASP站长网）

迁移到 AWS 云 注意事项

迁移到 AWS 云注意事项