迁移到云时要考虑的十大事项

在某些情况下，云迁移并没有无缝发生。一些公司实际上一直在努力将其数据和运营迁移到云端。然而，经历过此类障碍的团队从过去的教训中吸取了教训，并努力使未来的迁移更加顺利。

以下是一些可以帮助您顺利完成此过程的指南：

1. 首先，您需要确定架构师的角色，他将自始至终领导此迁移过程。担任此职位的人将负责规划和完成迁移的所有阶段。重点应该是定义使流程成功和顺利进行所需的重构。简而言之，架构师必须设计迁移策略、确定公共云解决方案需求并确定迁移优先级。

2. 在开始迁移过程之前，您还必须决定是选择单一云环境还是多云环境。当您希望应用程序在特定的云供应商环境中运行时，迁移非常容易。开发团队只需学习一组云 API；唯一的缺点是供应商锁定。这是因为一旦你更新了一个应用程序使其与一个供应商合作，将它转移到另一个供应商就变得困难了。此外，当你只与一家云供应商合作时，它也会影响你与供应商就 SLA 和成本等重要条款进行谈判的权力。当您决定选择多个云提供商时，有很多模型可供选择。最简单的形式是一组应用程序与一个提供商和另一组应用程序与另一个提供商。您还可以在不同的云提供商之间分发您的应用程序；所以有些公司会在一个供应商中运行部分应用程序，而在另一个供应商中运行其他部分云托管提供商。

3. 第三，选择你想要的集成级别很重要；您可以选择深度云集成或浅层云集成。对于后者，您可以转移现场应用程序并对运行应用程序的服务器进行非常有限的更改或不进行任何更改。没有使用任何独特的服务，所有的应用程序更改只是为了让这个应用程序在云端正常运行。这基本上称为直接转移模型，其中应用程序被完整地转移到云端。另一方面，深度云集成是必须修改应用程序以便利用云功能发挥优势的地方。

4. 您还应该收集 KPI 或关键绩效指标，它们本质上是您获得的关于任何服务或应用程序的指标。这些可以帮助您了解应用程序或服务的表现如何超出您的预期。因此，最好的 KPI 会告诉你迁移的进展情况，它会告诉你应用程序中仍然存在的问题。

5. 基线是指计算应用程序现有或迁移前性能以确定未来或迁移后性能是否可接受的过程。它还会告诉您迁移何时结束。您可以使用此过程来诊断迁移过程中可能出现的问题。例如，您可以为每个 KPI 设置基准指标。当您选择较短的基线期时，您可以快速行动，但存在无法获得具有代表性的性能样本的风险。当您选择更长的基线周期时，这将很耗时，但它会提供具有代表性的数据。

6. 进行云迁移时要使用的另一个重要技巧是确定迁移组件的优先级。因此，您必须决定是一次性迁移整个应用程序还是明智地迁移应用程序组件。为此，您必须识别服务之间的连接以查看哪些服务是相互依赖的。最好开始迁移依赖最少的服务。因此，最内部的服务首先出现，然后是最外层的服务或最接近客户的服务。

7. 另一个需要记住的有用准则是重构任何需要重构的东西。因此，在迁移这些应用程序之前，您可能需要处理一些应用程序。这将确保该应用程序可以与多个正在运行的实例一起使用以进行动态缩放。此外，您的资源使用可以利用动态云的功能。

8. 在没有数据迁移计划的情况下，切勿开始迁移。数据的位置对于任何应用程序的性能都非常重要。因此，当您在数据访问方法保留在现场的时候将数据转移到云端时，性能将会受到影响。迁移架构师必须参与此规划过程。您可以选择一种双向同步机制，一旦您将所有客户端移动到云中，您就可以删除现场数据库。您还可以使用 AWS 或 Azure 的云迁移服务。

9. 您还可以根据应用程序的架构和复杂性，将生产系统从本地版本切换到云版本。你可以同时做所有的事情，也可以选择一点一点地做。因此，您可以先移动几个客户端，然后进行测试，看看是否一切都按计划进行。之后，您可能会移动更多的客户。

10. 最后，您必须检查应用程序的资源分配。云已针对动态资源配置进行了优化，但如果静态分配资源，则无法享受基于云的安全解决方案的优势。您需要确保您的团队有适当的资源分配计划。您应该能够在需要时扩展资源。