由于云计算行业的飞速发展，现在很多企业都致力于将关键企业应用程序迁移到公共云。在某些情况下，企业团队在云迁移中遇到了困难，并且成果有限。但可以通过所学到的经验教训在随后的尝试中改进结果。
如果企业正在寻求对任务关键型应用程序进行现代化改造，并且计划将云迁移作为此过程的一部分，那么借鉴他人的经验则可以事半功倍。
因此，本文将通过这些知识来构建企业管理者需要考虑和解决的主要领域的 10 个步骤，以最大限度地提高成功迁移云的机会。
1、建立迁移架构师角色
在开始云迁移之前，需要建立迁移架构师角色来领导这项工作。迁移架构师是系统架构师级别的职位，负责规划和完成迁移的所有工作流程。他们的核心职责应包括定义使迁移成功所需的必要重构、设计数据迁移策略、定义云解决方案要求以及确定迁移优先级和生产切换机制。
在大型迁移项目的过程中，必须做出许多决策和技术计划，而拥有一个负责迁移各个方面迁移架构师对于项目的成功至关重要。
2、选择云集成级别
当企业将应用程序从本地数据中心迁移到云时，可以通过两种方式迁移应用程序 - 浅层云集成或深层云集成。
对于浅层云集成（有时称为“提升和转移”），企业将本地应用程序移动到云中，并且为了运行应用。任何应用程序更改都足以让它在新环境中运行，不使用云独有的服务。此模型也称为提升和转移，因为应用程序“按原样”提升并移动或转移到云中。
对于深度云集成，企业可以在迁移过程中修改应用程序以利用关键的云功能。企业可以使用先进的自动扩展和动态负载平衡，或者它可能与将AWS Lambda等无服务器计算功能用于部分应用程序一样复杂。它还可能涉及使用特定于云的数据存储，例如Amazon S3或DynamoDB。
3、选择单一云或使用多云
在开始云迁移之前，请对此问题进行思考：是想选择一个云提供商并迁移您的应用程序，以便它针对该单一环境优化运行，还是希望应用程序在多个云提供商上运行？
优化应用程序以与特定的云提供商一起工作相对简单。开发团队只需学习一组云 API，应用程序就可以利用云供应商提供的一切。
这种方法的缺点是供应商锁定。一旦企业更新了应用程序以仅与一个提供商合作，将应用程序移动到另一个提供商可能需要与原始云迁移一样繁杂的流程。此外，拥有单一云提供商可能会对企业与云提供商协商重要条款（例如定价和 SLA）的能力产生负面影响。
而且，它也变得更加复杂。使用多个云提供商有几种不同的模型：
1）一云一应用。 另一个云中的另一个应用程序。也许最简单的多云方法在一个云提供商中运行一组应用程序，在另一个云提供商中运行另一组应用程序。这种方法使企业可以提高与多个提供商的业务杠杆作用，以及将来在何处放置应用程序的灵活性。它还允许企业针对运行它的提供程序优化每个应用程序。
2）跨多个云提供商拆分应用程序。 一些公司选择在一个云提供商中运行应用程序的一部分，而在另一个云提供商中运行它的其他部分。这种方法让企业可以利用每个提供商提供的关键优势（例如，一个提供商可能具有更好的 AI 功能，而另一个提供商可能以其数据库速度而闻名）。这里的风险是企业的应用程序与两个提供商的性能相关，任何一个提供商的任何问题都可能影响应用程序的客户体验。
3）将应用程序构建为与云无关。 使用这种方法，企业可以在多个提供商上同时运行应用程序，或者将应用程序负载分散到它们之间。该模型为企业在供应商谈判中提供了最大的灵活性，因为企业可以轻松地将负载从一个云提供商转移到另一个云提供商。缺点是会造成很难使用每个云提供商的关键功能，从而降低了将应用程序托管在云中的好处。
4、建立云 KPI
关键绩效指标 (KPI) 是企业收集的有关应用程序或服务的指标，用于衡量其执行情况是否符合预期。云迁移的最佳 KPI 显示了企业正在进行的迁移是如何进行的，阐明了可能潜伏在应用程序中的可见或不可见的问题。也许最重要的是，云迁移 KPI 可以帮助企业确定迁移何时完成并成功。
云迁移 KPI 有几个关键类别：
对于每个类别，确定哪些指标对自身业务最重要，哪些指标将受迁移到云的影响最大。
5、建立绩效基准
基线是测量应用程序或服务的当前（迁移前）性能的过程，以确定其未来（迁移后）性能是否可以接受。基线可帮助团队确定迁移何时完成，并验证预期的迁移后性能改进。还可以在云迁移期间参考基线来诊断出现的任何问题。
管理者需要决定衡量的每个 KPI 设置基线指标。确定将收集数据多长时间以确定基线。选择较短的基线期（例如一天）可以让团队更快地行动，但可能无法收集到具有代表性的绩效样本。选择更长的基线时间（例如一个月）显然需要更多时间，但可以提供更具代表性的数据。
团队管理者还需要确定是否只想收集平均或代表性的基线数据，或者是否希望包括在“高峰”或“关键”时期收集的数据。无论哪种数据收集模型适合所在行业，请务必明确定义要收集的数据类型和时间段。
6、优先考虑迁移组件
企业管理者还必须决定是一次迁移整个应用程序，还是将其逐个组件或逐个服务迁移到云组件。
首先，确定服务之间的连接以及哪些服务依赖于哪些其他服务。使用依赖关系图来决定应该迁移哪些组件以及以什么顺序迁移。从具有最少依赖关系的服务开始通常是有意义的。
在这种情况下，需要首先迁移最内部的服务，然后跟进最外部的服务——通常是最接近客户的服务。另一种方法是从最接近客户的服务（最外部的服务）开始，这样就可以控制对客户的所有影响。
7、执行任何必要的重构
企业可能希望在迁移应用程序和服务之前对其进行其他工作，以便它们在云中尽可能有效和高效地工作。例如，他们可能想要重构应用程序：
因此，它可以有效地与可变数量的运行实例一起工作，以允许动态扩展，从而可能节省云服务成本。
这样，企业的资源利用率就可以更好地利用动态云功能，例如根据需要动态分配和取消分配资源的能力，而不是提前静态分配资源。
在迁移之前迁移到更加面向服务的架构，以便企业可以更轻松地将单个服务迁移到云中。
8、创建数据迁移计划
迁移数据是云迁移中最棘手的部分之一。数据的位置会显著影响应用程序的性能。当数据访问方法仍然主要是在本地时将数据移动到云会显著影响性能。如果数据仍然在本地，但访问它的服务驻留在云中，情况也是如此。
数据迁移的选项包括：
在本地数据库和云数据库之间使用双向同步机制。将所有数据使用者移至云后，删除本地数据库。
使用与基于云的数据库单向同步的本地数据库，并允许消费者仅连接到本地版本。准备就绪后，禁用对本地版本的访问，以便基于云的版本成为主数据库，并启用基于云的消费者对新数据库的访问。
9、切换生产
企业何时以及如何将生产系统从旧的本地解决方案切换到新的云版本？答案取决于应用程序的复杂性和架构，尤其是数据和数据存储的架构。
有两种常见的方法：
1）一次性完成。 等到将整个应用程序或服务移到云上并验证它可以在那里工作，然后将流量从本地堆栈切换到云堆栈。
2）一次做一点。 移动一些客户，测试一切是否仍然有效，然后再移动一些客户。继续此过程，直到将所有客户转移到基于云的应用程序。
10、查看应用程序资源分配
即使在完成将所有内容迁移到云之后，还有一些事情需要考虑。最重要的是资源优化。云针对动态资源分配进行了优化，当静态分配资源（例如服务器）时，企业并没有利用云的优势。
当迁移到云中时，请确保团队制定了将资源分配给应用程序的计划。当需要为云中的应用程序分配额外的资源时，供应商通常可以随时从供应商处获得几乎任何数量的资源。
文中的 10 个步骤涵盖了很多内容，但在云迁移过程中，还应该考虑其他事项。例如，创建安全可靠的云环境显然是所有云迁移的关键部分。幸运的是，主要的云提供商提供了重要的工具和资源来帮助企业构建和维护一个安全的系统。