这篇文章的版本最近跑了新的堆栈。
我从事云计算已经十多年了，我听过许多致力于将关键企业应用程序转移到公共云上的IT高管的讲话。在一些情况下，他们的团队在云迁移方面遇到了困难，或者只取得了有限的成功。但他们从未放弃，他们利用所学到的经验在随后的尝试中提高了自己的成绩。
如果您的组织正在寻找使关键任务应用程序的现代化，并且您正在计划作为此过程的一部分的云迁移，您不想重复他人的错误。因此，此帖子利用这些学习来构建一个需要考虑的主要领域的10步云迁移清单和地址以最大限度地提高您成功的云迁移的机会。
云迁移核对表包括：
步骤1:建立迁移架构师角色
在开始云迁移之前，建立迁移架构师角色来领导这项工作。迁移架构师是一个系统架构级别的职位，负责规划和完成迁移的所有方面;他们的核心职责应该包括定义成功迁移所需的必要重构、设计数据迁移策略、定义云解决方案需求、确定迁移优先级和生产切换机制。
在大型迁移项目的过程中，必须做出许多决策和技术计划，拥有一个负责迁移的所有方面的迁移架构师对项目的成功至关重要。
第2步：选择您的云集成级别
将应用程序从本地数据中心移动到云端时，有两种方式可以迁移应用程序 - 浅云集成或深云集成。
对于一个浅云集成（有时称为“升力和换档”），您将本地应用程序移动到云，并对云中实例化的服务器进行无限制或有限的更改，以运行应用程序的目的。任何应用程序更改都足以让它在新环境中运行。您不使用云 - 独特的服务。该模型也称为升力和偏移，因为应用程序被抬起“如”并移动，或移位，或移位，或移位到云层。
对于一个深云集成，在迁移过程中修改应用程序以利用密钥云功能。这可能比使用自动缩放和动态负载平衡更先进，或者可能像利用无服务器计算功能一样复杂AWSλ用于应用程序的某些部分。它还可能涉及使用特定于云的数据存储，比如亚马逊S3或者DynamoDB。
第3步：选择单个云或去多云
在开始云迁移之前，解决此问题：您是否希望选择单个云提供商并迁移您的应用程序，以便为该单个环境进行优化，或者您希望您的应用程序在多个云提供商上运行
优化应用程序以使用特定的云提供商相对简单。您的开发团队只需学习一组云api，您的应用程序可以利用所选云提供商提供的一切。
这种方法的缺点是厂商锁定。一旦您更新了您的应用程序以只使用一个提供者，那么将您的应用程序迁移到另一个提供者可能需要与原始云迁移一样多的工作。此外，单一的云提供商可能会对您与云提供商协商重要条款(如定价和sla)的能力产生负面影响。
等等，事情变得更复杂了。有几种不同的模型用于使用多个云提供商:
一个云中的一个应用;在不同的云中的另一个应用程序。也许最简单的多云方法是在一个云提供商中运行一组应用程序，在另一个云提供商中运行另一组应用程序。这种方法为您增加了与多个提供者的业务杠杆，并为将来将应用程序放置在何处提供了灵活性。它还允许您为它所运行的提供者优化每个应用程序。
跨多个云提供商分割应用程序。有些公司选择在一个云提供商中运行应用程序的部分，而在另一个云提供商中运行应用程序的其他部分。这种方法允许您利用每个提供商提供的关键优势(例如，一个提供商可能比另一个提供商拥有更好的AI能力，这是众所周知的数据库速度)。这里的风险是，您的应用程序与两个提供者的性能都有关联，任何一个提供者的问题都可能影响您的应用程序的客户体验。
将您的应用程序构建为云不可知论。其他公司构建其申请以运行任何云提供商。使用此方法，您可以在多个提供程序上同时运行应用程序，也可以将应用程序加载拆分为它们。此模型为您提供了供应商协商的最终灵活性，因为您可以轻松地将负载从一个云提供商转移到另一个云提供商。缺点是您可能会发现难以使用每个云提供商的关键功能，从而减少托管应用程序在云中的好处。此方法还可能使您的应用程序开发和验证流程复杂化。
第4步：建立云KPI
关键性能指标(kpi)是您收集的关于应用程序或服务的指标，用于衡量应用程序或服务在您的期望下的执行情况。您可能已经为应用程序和服务定义了一些kpi，但一旦应用程序或服务进入云中，它们是否仍然是正确的kpi呢?云迁移的最佳kpi显示正在进行的迁移是如何进行的，揭示了可能潜伏在应用程序中的可见或不可见的问题。也许最重要的是，云迁移kpi可以帮助您确定迁移何时完成和成功。
有几个关键类别的云迁移kpis：
| 类别 | 样本KPI |
|---|---|
| 用户体验 | 页面加载时间 滞后 响应时间 会话持续时间 |
| 应用程序/组件的性能 | 错误率 吞吐量 可用性 Apdex |
| 基础设施 | CPU使用率 ％ 磁盘性能 内存使用情况 网络吞吐量 |
| 商业参与 | 购物车添加了 转换和转换％ 接触率 |
对于每个类别，确定哪些指标对您的业务最重要，以及哪些指标将受迁移到云计算的影响最大。
参考New Relic规划云迁移的教程获取有关确定指标以定义kpi的提示。
第5步：建立性能基线
基准是测量应用程序或服务的当前（预迁移）性能的过程，以便确定其未来（迁移后）性能是否可以接受。基准帮助您确定迁移何时完成并提供您预期的迁移后性能改进的验证。您还可以在云迁移期间引用基准，以诊断出现的任何问题。
为您决定要度量的每个KPI设置基线指标。确定收集数据以确定基线的时间。选择较短的基线周期(如一天)可以让您移动得更快，但您可能无法收集具有代表性的性能样本。选择较长时间的基线(例如一个月)显然需要更多的时间，但可以提供更有代表性的数据。
您还需要确定是否希望只收集平均或代表性的基线数据，或者是否希望包括在“峰值”或“关键”时期收集的数据。例如，如果您是一个新闻站点，您是希望在有重大新闻事件的一天内收集数据，还是希望避免这样的日子?
无论哪种数据收集模型适合于您的行业，都要确保清楚地定义要收集的数据类型和收集时间。
有关使用新遗物为云迁移创建应用程序基线的更多信息，请参阅新的遗物规划云迁移的教程。
步骤6:优先考虑迁移组件
您还必须决定是一次性迁移整个应用程序，还是逐个组件或逐个服务将其迁移到云组件。
首先，确定服务之间的连接，以及哪些服务取决于其他服务。对于更大，更复杂的应用程序，使用应用程序性能监视工具,可以使用地图服务生成依赖图。使用依赖关系图决定应该迁移哪些组件并以什么顺序。从具有最少依赖性的服务开始，它通常是有道理的。在这种情况下，您将迁移您的最多内部第一个服务，然后跟进您的最外面的服务，通常是最接近客户的服务。替代方法是从最靠近客户的服务开始 - 最多外部服务——这样你就可以控制对客户的任何影响。
新的遗物规划云迁移的教程提供使用New Relic来确定迁移组件的优先级的技巧。
第7步：执行任何必要的重构
在迁移应用程序和服务之前，您可能希望对它们进行其他工作，以便它们尽可能高效地在云中工作。例如，你可能想要重构你的应用程序:
- 因此，它有效地运行了可变数量的运行实例，以允许动态缩放，可能会在云服务成本上节省金钱。
- 因此，您的资源利用率可以更好地利用动态云功能，例如动态分配和根据需要进行解除资源的能力，而不是在时间提前分配它们。
- 迁移到迁移之前移动到更具服务的架构，以便您可以更轻松地将各个服务移动到云端。
步骤8：创建数据迁移计划
迁移数据是云迁移的最棘手的部分之一。数据的位置可以显着影响应用程序的性能。当数据访问方法仍然主要是内部部门时，将数据移动到云端可能会显着影响性能。如果数据仍然是本地，但访问它位于云中的服务时也是如此。
数据迁移的选项包括:
- 在您的内部部门和云数据库之间使用双向同步机制。将数据的所有消费者移动到云端后，删除本地数据库。
- 使用与基于云的数据库单向同步的本地数据库，并允许消费者仅连接到本地数据库版本。准备好后，禁用对本地版本的访问，使基于云的版本成为主数据库，并允许基于云的用户访问新数据库。
- 使用云数据迁移服务，比如可用的亚马逊网络服务。
不要低估数据迁移计划的复杂性和重要性。在开始云迁移之前不密切关注数据迁移计划可能导致迁移失败，或者至少不能满足预期。迁移架构师应该积极参与数据迁移规划过程。
第9步：切换生产
何时以及如何将生产系统从传统的本地解决方案转换为新的云版本？答案取决于您的应用程序的复杂性和架构，尤其是数据和数据存储的架构。
有两种常见的方法:
- 一次做所有的事情。等待，直到您将整个应用程序或服务转移到云上，并验证它在那里工作，然后将流量从本地栈切换到云栈。
- 一次做一点。把一些客户移过来，测试一下是否还能工作，然后再转移一些客户。继续这个过程，直到将所有客户转移到基于云的应用程序为止。
第10步：查看应用程序资源分配
即使你完成了迁移到云端的一切之后，也有更多需要考虑的事情。最重要的是资源优化。云进行了针对动态资源分配进行了优化，并且当您在静态地分配资源（例如服务器）时，您就不会利用云的优势。当您进入云时，确保您的团队有计划为您的申请分发资源。当您需要将额外资源分配给云中的应用程序时，它们通常在短时间内从供应商处提供。这意味着您通常可以相信您可以根据需要进行扩展以满足需求，假设您的团队具有应用架构，以支持动态缩放。
云迁移的其他注意事项
这个云迁移清单中的10个步骤涵盖了很多方面，但是在云迁移过程中肯定还有其他需要考虑的事情。例如，创建一个安全可靠的云环境显然是任何云迁移的关键部分。幸运的是，主要的云提供商提供了重要的工具和资源来帮助您构建和维护安全的系统。
谈到云计算成本，有两条关于云计算定价的经验法则:云服务比本地服务便宜， 和云计算比本地部署更昂贵。根据情况，两者都可能是对的或错的。
当然，如果开始使用云计算，就会发现与物理数据中心的支出相比，您的基础设施账单实际上有所增加。出现这种情况有以下几个原因:
首先，在所有基础架构系统中存在隐藏的成本，您可能无法考虑运行自己的数据中心所涉及的所有成本，而您来自云提供商的每月账单会使成本非常清楚。结果？有时，您最终将苹果与橙子进行比较，使云解决方案似乎比内部部署更昂贵。
其次，本地基础设施的成本主要由资本支出（CAPEX）组成，而基于云的基础设施通常会出现营业费用（OPEX）。根据您的业务如何管理其书籍，CAPEX可能比OPEX更容易，反之亦然。了解基于云的基础设施的支付与本地基础设施不同，并确保贵公司的金融模式支持区别，对识别云成本改进至关重要。
有关云成本的主题，请退房如何计算云迁移的成本。
最后，我建议计划云迁移的人熟悉一些主题，比如特别是使用服务和微服务构建现代应用程序twelve-factor应用程序，并使用devops方法以及作为构建和运行云服务和应用程序的最佳实践的过程。哦，别忘了优化您的客户体验一旦您完全迁移到云端。
如果您希望将应用程序的成本降低95％并将应用程序部署到公共云90％更快，请查看此最近的Forrester咨询研究，用于云迁移和优化的新Relic平台的总经济影响™(TEI)。
