安全、成功的云迁移有这三个阶段

将复杂的业务关键型应用程序从内部迁移到云时，最安全、最有效的方法包括三个阶段。

在第一阶段，应用程序被“lifted and shifted”到云端，而无需重构。

在第二阶段，IT可以使用克隆的环境来提高软件开发和测试的效率，同时逐段重构应用程序以使用云原生服务。即使不使用云原生服务，也可以引入环境构建的增量自动化，从非自动化工作模型开始，逐步创建全自动化版本。

在第3阶段，大多数应用程序以云原生格式存在，但它保持与内部的连接。本文概述的概念为云创新创造了一条快速而安全的道路，同时减少了对现有内部资源的依赖。

让我们详细了解一下这条“通往云的安全之路”。

第1阶段——lift and shift

在第1阶段，内部应用程序在目标云中复制，无需重构。这使得它能够将“云灵活性”应用到历史上“云顽固”的系统中，使快速克隆、短暂性、软件定义的网络和API自动化能够应用到现在在云中运行的应用程序中。这一步完成后，IT可以将环境“克隆”分发给多个工程组，使每个工程组能够以更快的速度同时独立地工作。

好的做法是创建内部上最终记录系统的“克隆”，但不将任何组件重新设计为云原生等价物。创建相同数量的VM/LPAR（逻辑分区）、相同的内存/磁盘/CPU分配、相同的文件系统结构、相同的确切IP地址、相同的确切主机名、相同的网络子网等。

阶段1：将应用程序从内部迁移到云，进行有限的架构更改。

请注意，在IBM i系列或AIX中运行的应用程序不能在没有专门修改的情况下lift and shift到Azure、GCP或AWS。但是，有些解决方案提供商提供了这种功能。向这些传统应用程序添加云功能的好处通常会超过这样做的投资成本。

一旦在云中创建了表示“环境”的VM/LPAR的集合，环境就被保存为一个称为模板的对象。该模板用于克隆其他工作环境。克隆是模板的完全副本，包括主机名、IP地址、子网和磁盘分配。多个环境克隆可以同时运行而不会发生冲突，尽管设置这些克隆所需的工作因云提供商而异。

从模板创建随时可用的环境是基于云的方法最强大的地方。它提供了参考系统的多个精确副本，分发给许多工程/开发/测试组，所有这些组都可以并行运行。不需要更改单个服务器的IP地址或其主机名。

每个环境都在一个虚拟数据中心中与其他环境协调运行。如果环境需要与其他内部资源通信，则通过隔离的NAT机制来区分它们。许多环境包含具有相同主机名、IP地址等的相同VM克隆基本镜像。

内部到云工作流：应用程序成为可以克隆的模板。

如有必要，将模板分配给项目，并将这些项目分配给用户组。大多数云提供商都提供了一个内置的访问控制/安全模型，因此用户只能处理分配给他们的内容——例如，QA用户无法看到单独分配给ENG的环境。用户还具有角色分配，允许他们查看/编辑/管理在分配给项目的环境中定义的VM/LPAR。

如何创建具有重复地址空间的克隆环境

要创建与最终目标系统复本相同网络拓扑的多个工作环境，必须实现某种形式的隔离，以避免重复环境之间的冲突。在这种情况下，“复制”意味着在每个环境中重新使用相同的主机名、IP地址和子网。理想情况下，每个环境都应该存在于自己的软件定义的网络空间中，而其他正在运行的环境是看不到的。每个环境都成为一个虚拟的私有数据中心。

这里有一种使用“环境虚拟路由器”（EVR）实现的方法。克隆环境通过EVR与上游内部资源通信，EVR隐藏包含重复主机名和IP地址的低级VM，并向较大内部网络公开唯一的IP地址。这为多个重复环境在不破坏基本网络结构的情况下和谐地存在创造了一种简单而优雅的方式。

通过允许存在重复的主机名和IP地址，单个主机不必经历“重IP”过程，这是一个容易出错且耗时的过程。与“跳转主机”配对的EVR可以配置为转发ssh请求（通过ssh代理、OpenSSH7.x和更高版本），这允许SSH进入环境中的每个唯一主机。从内部，用户将SSH连接到环境中的任何主机（例如 ssh user@environment-1-host-2），它向内部公开一个唯一的IP地址，然后在单个环境中向下中继到VM。

具有重复的RFC1918IP地址且没有冲突的多个环境。

一旦克隆环境被创建并传递给适当的团队，项目就可以进入下一阶段了。

第2阶段——重构

一旦应用程序组件被迁移到云中，它们就可以被用作开发/测试“沙盒”，同时它使用“Side Car”或“Strangler”等经验证的设计模式将它们增量地重构到原生云服务。开发人员也可以逐步将自动化构建到应用程序中，即使他们不使用云原生服务。另一种方法是，只需重新托管应用程序，而无需显著更改其原始的内部结构。

这种方法遵循Martin Fowler描述的“Strangler Pattern”方法。微软最近通过以下可视化方式描述了该过程：

迁移阶段遗留与代码原生转换的平衡。

这种增量方法为最终重构应用程序的敏捷团队提供了以下好处：

——它允许使用增量方法进行转换，而不是从头开始。重构研发是以合理的方式进行的，这样整个应用程序就可以继续运行。这就避免了创建应用范围广泛的“全新”开发工作。迁移中的多个应用程序采用“从头开始”的方法是高风险的，并且违背了敏捷原则。

——速度加快。通过克隆原始的内部应用程序，可以将参考应用程序的完整工作版本交付给执行短期冲刺的敏捷团队，每个团队调查要重构的应用程序的不同方面。

——将整个应用程序拆分为更小的部分可以降低整个项目的风险，并有可能缩短整个迁移过程。交付重构的一小部分而不是整个应用程序符合敏捷宣言中“工作软件”和“响应变化”的价值观。

第3阶段——迁移完成

在第3阶段，大多数应用程序以云原生格式存在，但保持一个专用的连接返回到内部IT。如果你将迁移过程看作一个工厂，那么多个应用程序将以不同的速率在装配线中运行。当应用程序在第3阶段退出工厂时，转换目标列表中的其他应用程序将进入第1阶段和第2阶段。随着使用云原生服务和组件的经验增长，“工厂层”可以加快，因为在转换过程中早期发现的问题的解决方案可以快速应用，而不需要过度的研发、反复试验和重新工作。

内部应用程序最初“按原样”移动到云

重构后，许多/大多数应用程序组件现在都是原生云服务

安全、敏捷、成功

这种分三个阶段的方法使组织能够利用云的好处，如按需容量，并与许多敏捷软件开发最佳实践相匹配。它通过允许团队同时工作来加速许多工程、QA和开发/测试过程，同时通过在迁移过程中不重新构建平台或重新构建来降低风险，并通过以小的、可管理的增量来处理这些工作。对于重要的本内部应用程序来说，它既是最安全的迁移策略，也是最有可能成功的迁移策略。

原文链接：

https://thenewstack.io/3-phases-to-a-safe-and-successful-cloud-migration/