将 IT 基础架构从一个地方移动到另一个地方就像移动一个人：总是充满压力！但是您可以通过从他人的经验中吸取教训来最大程度地减少这种压力。
在我的职业生涯中，我见过不少云迁移，在这篇文章中，我想分享一些简单的想法，以帮助 DevOps 工程师、架构师、经理和任何其他可能参与其组织迁移到云的人。
但首先，一些免责声明：
本文主要关注 AWS 云迁移，因为我是这方面的专家。但是，此信息也可能适用于其他云提供商。
本文主要关注从内部部署到公共云的迁移，因为在我看来，这些迁移比云到云的迁移要困难得多。
对一个组织有效的方法可能对另一个组织不利。虽然我会告诉你在云迁移中什么是更好的做法以及什么是避免的，但请通过你的批判性思维来过滤它，并记住每个人都有自己的背景和经验。
话虽如此，以下是 AWS 云迁移的注意事项：
操作系统
1. 进行云就绪评估
如果一个人迁移到新地点，他们应该考虑：
气候会有所不同。
该地点使用的语言可能不同。
生活成本会有所不同，而且可能会更贵。
当一家公司迁移到云端时，他们应该问类似的问题。这些可能包括：
我们是否考虑了所有的风险？ （另请阅读：您的组织是否了解这 6 大公共云风险？）
必须更改什么才能使工作负载真正起作用？
我们是否拥有所需的人力资源？
我们有完成所有事情的预算吗？
正式提出这些问题称为云就绪评估——它是一种关于不同组织流程的长篇访谈，用于确定公司在云中的准备程度。
云就绪评估基于云采用框架 (CAF)，使您能够了解应该在流程方面进行哪些更改才能成功地在云中生存。 AWS 有一个涵盖所有这些的云就绪评估工具。
2. 创建一个商业案例
贵公司云迁移的驱动因素是什么？您希望迁移解决哪些问题？它应该实现什么目标？
具体说明这些答案：如果您打算降低成本，请计算总和。如果您打算提高可用性，那么请定义一个明确的服务级别目标。
您的业务案例将是您迁移的首要文件。所有其他工件都应该基于它。
3. 自动化发现和数据收集
不要将您的数据分析基于手动创建的电子表格或口头交流；让机器收集有关库存和使用统计的数据。
您收集的数据越精确越好。在大多数情况下，AWS 的 Migration Evaluator 服务将帮助您做到这一点。
4. 管理你的投资组合
创建要迁移的工作负载组合，对其进行分析，为每个工作负载选择迁移策略，为试点/第一波迁移选择一些，估计时间表并准备计划。
之后执行迁移。重复直到迁移组合为空。共享数据。让主题专家对其进行审查。
5. 打造云卓越中心
这是上面提到的云采用框架的一部分。在执行迁移之前，创建一个 Cloud Center of Excellence (CCoE)：一个负责制定战略并定义云中良好生活标准的人员团队。
您的 CCoE 应包括具有各种主题专业知识的人员，包括：
管理。
操作。
平台。
人们。
金融。
在云中使用或提供服务的任何其他部门。
您的 CCoE 成员将为迁移准备一个着陆区，包括硬性政策和软性政策，并且通常会为您的公司在云中的生活做好准备。
不要害怕重新审视任何政策。随着新因素的出现，做出改变。
6. 做好架构框架审查
这应该在迁移浪潮期间和之后发生。这将使您避免愚蠢的错误，并从技术角度对您所做的工作有一个高层次的概述。
7. 现代化计划
准备一个现代化计划以及您的迁移计划——迁移不是故事的结局！要在云中发挥作用，您必须跟上它的步伐。 （另请阅读：专家分享顶级云计算趋势。）
第一次现代化改造可能规模巨大，因此提前规划并安排预算和资源非常重要。在许多情况下，如果不这样做，将导致运营成本增加。
不要做
1. 完全按照另一家公司的做法去做
一个企业可能会说，“我们必须非常快地迁移到云。让我们现在就快速提升和转移。”
但最好不要马上开始做。您确定重新托管策略会比其他策略更快吗？根据我的经验，情况并非如此：当我们尝试使用 Cloud Endure 迁移本地 VM 时，它不起作用，因为机器的操作系统相当陈旧，而且一些操作系统级别的依赖项在 AWS 上不起作用”硬件。
评估你所拥有的，分析它，分析商业案例——然后思考。
2. 没有明确目标的迁移
你为什么要移民？如果您无法回答该问题，您可能需要找到答案或根本不迁移。
我见过企业想要迁移到云以降低成本的情况。他们在没有进行总成本分析的情况下执行了直接迁移。只有在事后他们才意识到它的成本甚至比托管中心还要高。
为避免这种情况，定义明确的目标并定义实现这些目标的目标状态。如果成本是驱动因素，请进行适当的计算并制定相应的计划。当您计划目标状态时，成本优化将是主要的事情。如果可用性是您迁移的原因，请衡量它，定义您的 SLO 并确保可用性是您在目标状态中考虑的主要因素。
3. 在黑盒中迁移
不要将迁移的工作负载视为“黑匣子”。
了解您究竟迁移了什么、这些东西如何工作以及它们的技术要求和依赖关系至关重要。该信息将使您能够选择正确的工作负载迁移策略。如果不这样做，您很有可能会走上错误的道路。
获取有关系统的信息是您进行规划时最重要的任务。 （另请阅读：数据孤岛：它们是什么以及如何处理它们。）
4.忘记架构良好的框架支柱
迁移是有压力的。这就是为什么人们倾向于尽可能快地完成它，只专注于一件事：尽快让一切在云中运行。
但是，如果您将架构良好的框架支柱搁置一旁，您可能会遇到只有在风险具体化后才能了解其严重性的后果。
5. 对所有事情都使用一种策略
为所有工作负载制定单一的总体计划总是很容易——例如，决定进行直接迁移，然后将所有内容重新托管在云中。但是，如果某些东西可以退役呢？如果可以不费吹灰之力地对某些组件进行平台改造，会怎样？
通过分析工作负载的所有组件并为每个组件确定独特的策略，您将节省大量资源。收集数据并妥善计划。
七种云迁移策略
请记住：云迁移是将数据中心的功能转移到基础架构即服务 (IaaS) 提供商的过程。这里的关键词是“能力”——你不是在迁移你的服务器、虚拟机、硬件、数据或任何其他东西。企业迁移其能力。
为实现这一目标，有七种云迁移策略：重新定位、重新托管（提升和转移）、重新平台、重新购买、重新架构/重构、保留和退休。
以下是关于每个的一些信息：
1.搬迁
在本地托管一些工作负载并将它们按原样移动到云端。
这在有限的情况下是可能的，例如，当我们迁移与云无关的工作负载或平台可能是云原生时。该策略的更具体示例包括：
将 Kubernetes 集群从本地迁移到云端。
使用 VMWare Cloud 迁移 VMware 机器。
2.重新托管
这也称为“提升和转移”。重新托管策略涉及将本地虚拟机/服务器转换为云中的虚拟机。例子包括：
使用 CloudEndure 将本地虚拟机迁移到 EC2 实例。
创建 EC2 实例、安装软件并应用与内部部署相同的配置。
3.重新平台化
我们在不重新构建系统的情况下将工作负载迁移到云原生平台。
例子：
将 PostgreSQL 迁移到 AWS RDS。
将 docker 容器迁移到 ECS。
4.回购
我们用 SaaS 替换了一些自定义/旧系统。此策略的示例包括：
用 SendGrid 替换自定义的本地电子邮件发送系统。
用销售人员取代 CRM。
5. 重构
将您的应用程序架构更改为云原生架构并使用托管云服务。这还包括从头开始重建。
例子：
更改您的应用代码以将文件上传到 S3 而不是本地存储。
容器化应用程序并迁移到 ECS。
6.退休
消除一部分不再需要的工作负载。例如，不再需要日志服务器，因为迁移的应用程序使用 CloudWatch。
7.保留
将您的工作负载留在本地。通常，这是暂时的。
这种策略的一个例子可能是：你有一个巨大的 oracle 数据库，有很多功能和定制，并且选择不将它迁移到 AWS，因为它会花费太多。相反，您决定将其保留在本地，直到它在现代化阶段被另一个解决方案取代。 （另请阅读：您需要数据库管理系统的 7 个原因。）
结论
如果您想降低与云迁移相关的风险并减轻压力，请不要着急。
您可能认为匆忙会节省您的时间，其他问题将在以后得到解决，但经验告诉我们，这是一个错误的假设。事实上，匆忙进行云迁移很可能会导致您遇到压力最大的结果：在您已经迁移到新的基于云的生产环境后，对遇到的问题进行打地鼠游戏。
必须将正确的工程原理应用于云迁移。拿起一座桥并将其从一条河流中移到另一条河流上是行不通的。迁移成功的关键是衡量、分析、设计和计划。将工作负载迁移到云端很困难。
