了解六个常见的云迁移策略

在确定您的云计算策略时，重要的是要了解没有两种商业情况是相同的。组织可能具有不同的专业领域、不同的商业压力、经验、团队结构、职责等。

虽然一些公司“生于云端”或已经具备强大的云能力，但其他组织可能会通过所谓的“推动因素”（例如关键基础设施产品逐步取消支持）或“拉动因素” （例如由于缺乏可用于物理服务器投资的资本支出。云迁移是组织将其部分或全部数据、应用程序和工作负载迁移到云基础架构的过程。本文将讨论高级云迁移策略，以帮助您选择最适合您业务的方法。

高层战略

一旦组织确定已准备好迁移到云，就需要做出许多特定于上下文的决策。拥有一个通用的指导策略至关重要。制定您的目标和希望通过云迁移策略解决的问题有助于确保您的业务和技术策略保持一致。你希望达到什么目的？

• 您是否正在努力削减成本或缩短上市时间？
• 您是否正在努力吸引和留住熟练的员工？
• 您是否正在努力提高产品或服务的质量？
• 这些目标是紧急的还是长期的？
• 在迁移到云端时，您是否有需要满足的合规性要求？

这些因素对于确定您的云迁移策略应该是什么样子至关重要。

供应商选择

对于具有一组同质工作负载要求的相对较小的组织，单一供应商云策略可能是最合适的，因为几乎不需要投资多个云供应商来实现技术冗余或避免供应商锁定。

更大的组织，例如具有不同工作负载和不同级别技术要求的全球银行，更有可能采用多云战略，因为这将使每个项目团队能够灵活地选择最适合其要求的供应商. 此外，较大的组织更有可能需要满足内部和外部合规性要求，而这些可能需要能够在相对较短的时间内在云供应商之间转移工作负载。

涉及传统数据中心和云供应商的混合策略对于大中型企业也可能有意义，特别是如果向云的过渡将跨越数年。如果随着您对云技术在企业中的实施了解得更多，需要更动态地发展您的云迁移策略，则此策略也可能是相关的。

六个R

一旦确定了云迁移目标和供应商策略，下一步就是决定如何将工作负载迁移到云中。首先，您需要对现有应用程序进行审核。这可以让您了解迁移到云所需的工作级别和性质。在此审核期间，您可以根据您希望负责应用程序的团队在云迁移中采用的方法对应用程序进行分类。AWS 概述了六种“常见迁移策略。这些可以全面应用，或者每个团队可以选择最适合他们当时特定设置的策略，具体取决于组织的规模和所涉及的复杂性。

1.重新托管

第一个也是最简单的策略是重新托管您的应用程序（也称为“直接迁移”）。它涉及将它们从在数据中心运行的物理服务器移动到在云中运行的虚拟服务器。通常，这不需要更改代码，并且对流程和网络等周边技术的更改相对较少。它还可能使您的组织能够开发其他云原生实践所需的云技能和经验。

2.重新平台化

这种方法也称为“提升、修补和转移”，类似于重新托管，但通过在应用程序级别集成大量基础云服务，更进一步。例如，AWS IAM（身份和访问管理）可能会集成到您的应用程序中，以取代或补充更传统的面向数据中心的 IAM 系统。

3.回购

这种方法也称为“drop and shop”，涉及用许可的基于云的服务替换现有的本地应用程序。这可能涉及更改您的企业使用的许可模式、降低维护成本，并可能允许更快、更轻松的升级路径。

4.重构/重构

一种更加云原生的方法是利用您现有的代码库并修改或扩展它们以在更现代的云服务中工作。一个示例是容器化您的应用程序代码、运行配置，并在基于云的 Kubernetes 服务（例如 Amazon 的EKS或 Azure 的AKS）中运行它们。这可能涉及对现有代码库进行大量重写，以使其能够正常运行并提高可扩展性；甚至可能需要完全重写才能使用真正的云原生工具（例如，无服务器工具，如 AWS Lambda 或 Azure Functions）。

5.退休

使用最后两个“被动”策略，工作负载根本不会迁移到云端。您的工作量审计可能会发现冗余或不再值得维护的系统。这些应用程序可以停用。

6.保留

最后一个“被动”策略，保留，涉及保持您的应用程序运行并选择在可预见的未来不将其迁移到云中。将您的应用程序保留在云之外的可能原因有很多，包括：

• 对应用程序运行位置的监管限制或对安全性的高内部合规性要求
• 软件的任务关键性可能会使在迁移周期的早期规划迁移到云技术的风险太大且不确定
• 没有关于移动应用程序造成的中断的业务案例
• 云环境不支持遗留系统

从哪里开始

除了决定您的总体战略和对每个工作负载的战术方法进行分类外，您还需要制定一个计划，如何构建您的云基础架构以支持工作负载的移动。一种方法是让每个团队选择如何在云中构建自己的系统。然而，这种方法有几个缺点，因为团队可能会复制反实施模式并重复彼此的错误或违反内部/外部合规性规则。

另一种方法是创建一种集中式“卓越中心”或云基础架构团队。该团队可以选择放置其他团队可以运行其工作负载的核心系统。在建立这些护栏时，应优先考虑某些设计元素。

帐户

云架构的最基本单元是云帐户。在您的组织中使用一个帐户几乎总是无法扩展，因为您最终会遇到帐户限制。因此，确定帐户边界很重要。该帐户将用于代表特定的业务部门、单个团队或一组软件服务吗？这将如何与您的财务部门一起运作？谁应该收到帐单？尽早弄清楚这一点很重要，因为成本会迅速增加。

下一个最基本的架构单元是身份和访问管理系统。随着您的云基础设施的增长，您将需要考虑用户访问各种云服务和数据的安全影响，而且越快越好。将这些规则追溯应用到已经运行的系统上可能会很复杂。

联网

迁移到云涉及现有网络的虚拟化或完全重新设计。VPC (AWS) 或 VNet (Azure) 服务允许您设置隔离网络以在您的帐户中运行一组单独的服务。需要仔细考虑您组织的服务与基本网络资源（如 IP 地址）之间的互联网络通信。

数据迁移

虽然将计算服务迁移到云端很容易，但迁移数据可能更具挑战性。主要数据存储可能是大型、复杂的基础设施，需要仔细规划才能移动。这需要对如何将数据移动到云中同时符合组织的性能、合规性和可操作性标准有足够深入的了解。

结论

一旦您明确了您的高级云战略，制定成功的云迁移战略就需要对您业务的各个方面进行细致的规划和考虑。下一步是为您选择正确的云供应商战略——无论是直接的单一供应商迁移、多云供应商方法还是混合战略。最后，您需要在开始载入应用程序之前首先考虑关键的基础设施组件来构建您的云迁移。