您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 云计算 > 正文

迁移到 AWS 云:注意事项

发表于:2022-12-13 作者:科技狠活与软件技术 来源:今日头条

如果有一天,您被告知迁移到 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)。这将使你避免愚蠢的错误,并从技术角度对你所做的事情有一个高层次的概述。

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

概括

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