迁移至 AWS 云：注意事项
发布时间：2023-02-27 10:49:29 所属栏目：云计算 来源：
导读：假如某天你被告知要迁移到 AWS/GCP/Azure或其他云服务提供商,你要做什么？轻描淡写可能会带来一些压力，对吗？
在我的职业生涯中，我见过不少迁移，在这篇文章中，我想分享一些想法，以帮助 DevOps 工程师、架构师
在我的职业生涯中，我见过不少迁移，在这篇文章中，我想分享一些想法，以帮助 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 并关注目标状态下的可用性。 黑盒迁移。不要将迁移的工作负载视为黑盒。了解您迁移的具体内容、它有什么技术要求、它有什么依赖关系以及它如何工作几乎是至关重要的。该信息将使您能够选择正确的工作负载迁移策略。如果不这样做，您很有可能会选择错误的路径并且结果会丢失。捕获有关系统的信息是规划时最重要的任务。 不要忘记架构良好的. 迁移是有压力的。这就是为什么人们倾向于尝试在尽可能短的时间内快速完成它，专注于唯一的事情：让一切尽快在云中运行。他们搁置了结构良好的框架支柱。这是个错误; 它可能会导致一系列不同严重程度的负面后果。不要忽视结构良好的框架支柱，否则在潜在问题或风险已经具体化之前，您不会知道它们。 一切都使用一种策略。为所有工作负载制定一个总体计划总是很容易的。例如，决定进行直接迁移，然后将所有内容重新托管在云中。但是，如果某些东西可以退役呢？如果可以不费吹灰之力地对某些组件进行平台改造会怎样？通过分析工作负载的所有组件并为每个组件确定独特的策略，您将节省大量资源。收集数据并妥善计划。这样做的好处是，您可以更好地管理您的业务，同时保持最佳性能。 （编辑：聊城站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐