最小可行迁移——敏捷迁移到无服务器架构之道
企业软件上云的现代化方法通常缺乏确保成功和最大化用户价值所需的敏捷性。从事件的角度思考数字化业务的设计，不仅提供了通往最先进的事件驱动架构的途径，而且还提供了一个「非最终形态」架构的改进目标，可以随着客户需求和技术进步而迭代它。我们需要摆脱「大爆炸」式的云计算迁移思维，并使用事件来映射一系列非最终答案的「最小可行迁移」 (MVM – Minimum Viable Migration)，以保持最新并适应变化。本文介绍了「最小可行迁移 / MVM」的概念，特别关注向无服务器云原生架构的迁移。
遗留系统 / Legacy System
遗留系统 / Legacy System，一个经常被低声说起好像它是淫秽词汇一样，这是所有科技公司的技术文化现状。在某些方面，「遗留系统」是一项成就——它奏效了，它成功了，现在是进化的时候了。
企业软件的云迁移作为项目来管理是必要的，并必须保持敏捷。许多人面临的最新云计算模式是「云原生」和「无服务器」，那么我们如何才能将敏捷性带入此类迁移项目呢？
敏捷迁移
大多数团队将采用敏捷方法来推出新产品和服务。从最小可行产品 (MVP) 开始，然后迭代发布——收集反馈、测试假设并更快地为客户提供价值。
最小可行产品 (MVP) 是具有足够功能的产品版本，可供早期客户使用，然后他们可以为未来的产品开发提供反馈。
MVP 使我们能够更早地测试假设、更快地学习、减少浪费、更早地交付给客户并验证假设。
然而，当涉及到迁移项目时，这通常会消失。一旦新系统与现有系统达到「功能对等」（一组等效的功能和功能），团队就会寻找「大爆炸」版本。
云迁移和现代化
「云迁移」是将数字业务资产和运营转移到云提供商（或另一个云提供商）的过程，随着公共云的出现变得非常流行。这些迁移通常采用「提升和转移」迁移的形式，后来一些人专注于仅在需要时进行重构。
迁移的核心是域的转变，从域 A 到域 B。
这可能是从内部部署到公共云提供商的「传统」云迁移。
在软件编程语言或技术框架层的迁移。
从单体架构到微服务的架构层迁移。
或者从经典云托管解决方案到云原生、无服务器架构的云现代化（迁移）。
无服务器正在成为云的未来——它们是一系列服务，使您无需考虑服务器（及其下面的一切依赖资源）即可构建和运行应用程序。无服务器架构降低了总拥有成本，允许开发人员交付更多业务价值，并且从第一天起就可以自动扩展。因此，许多公司都希望通过「云现代化迁移」将他们的应用程序迁移到无服务器。对于许多人来说，这涉及掌握一套新的技术以及重构和重组他们的应用程序以充分利用云。以敏捷渐进的方式执行此操作允许采用迭代方法进行现代化——降低风险并更快地交付价值。
与「大爆炸」式大规模的迁移相比，渐进式迁移在纸面上看起来可能更复杂。我们需要复制数据、编写接口并牢记两个系统（的部署细节）。除此之外，我们可能会冒险影响新系统的设计与旧系统的集成。如果我们逐步前进，就很难大胆地从根本上改变系统——毕竟「我们不想要更快的马匹」。
幸运的是，通过正确的方法和技术，渐进式迁移可以证明更简单、更具成本效益且不那么令人生畏。云现代化迁移就其本质而言，不仅仅是「提升和转移」，还需要对系统进行重构。这会增加复杂性，但也有机会发现创造性的渐进式迁移方法并充分利用云。
为数字业务和系统建模
在对他们构建的系统进行建模时，计算机科学家可以使用许多工具。所有这些都具有不同的抽象和标准化级别。
瀑布式迁移项目，典型的升降式迁移项目，通常对「系统现状」和「系统未来」进行建模，但「逐步发展的系统之间」又如何呢？如果我们要逐步从现有系统过渡到未来系统，这不是一个单一的垫脚石状态，而是一段旅程。
现代最先进的云架构通常是「事件驱动」的，这意味着系统通过事件（系统变化的信号）相互交互。
事件：系统变化的信号
系统触发事件（例如进入 AWS EventBridge 总线），而不是预定义的 API 和「同步」请求与响应，并监听来自其它系统的事件。事件结构成为共享接口，系统可以决定它们发出和订阅什么事件。
事件处理系统是一种非常有用的设计模式，无论是在现实世界还是数字系统中。如果我们关注业务领域的事件，而不是实现细节，我们就能用一致的方式理解和推理系统（无论底层技术领域如何）。
有关这方面的更多信息，请参阅我之前关于 EventBridge Storming 的文章。
我们可以通过它处理的事件来了解「遗留系统」。遗留系统不太可能以事件驱动的方式实现——但我们仍然可以推断出旧系统中支持业务功能的业务「逻辑」事件。通过这种方式，我们可以考虑事件传播的系统和渠道。这将帮助我们绘制一张「业务事件地图」，让我们清晰勾勒出系统迁移的旅程。
映射事件
如果我们抽象出数字业务系统要完成的业务，最终将得到一组路线和目的地，以及它们之间的路径（类比下面伦敦地铁路线图）。
避免应用一堆图论方程的诱惑，让我们从所有设计师研究的抽象示例中获取灵感：伦敦地铁的地铁路线图。
众所周知，这个示意图抽象了车站的地理位置，而不是代表它们的相对位置。
如果我们使用车站地铁图的概念模型，并将其应用于企业软件的「遗留」架构（当前架构），我们会得到如下结果：
现在，我们可以了解所涉及的系统和通信路径。这种服务映射可以在不同的粒度级别上进行。它可以映射通过 API 进行通信的高级隔离系统，它可以映射单体的内部源代码服务。我们需要了解不同业务操作所需的处理逻辑位置，以建立一个准确的思维模型，从中规划我们的渐进式迁移路线。
渐进式「最小可行迁移」（MVM）
从系统现状到未来系统不应该是一步全有或全无的飞跃。正如上面所讨论的，我们应该保持敏捷的心态，并应用我们在 MVP 中相同的思考原则来规划迁移项目。
这段旅程应该有很多步骤——事实上，理想情况下它并没有终点。系统应该随着客户需求和技术进步而变化——需要一种可以促进 MVM 的架构。这种架构风格是事件驱动的。
回到我们上述的交通地图类比，我们需要调整交通网络的形状，进行升级并增加车站——同时我们要保持火车准时运行。
绘制旅程图——识别 MVM
识别要迁移的子系统是一个复杂的权衡。我们需要平衡许多因素，并以我们想要测试的假设或想要实现的结果为指导。它可能是我们想要消除的可扩展性的单一瓶颈、技术方法的验证、技术团队能够使用目标架构的工具集的验证、与基础架构相关的成本节约、安全性升级/补丁，甚至是需要引入当前架构无法支持的新功能……清单还可以很长。
关键是我们需要有限范围的迁移，将一组业务流程或子流程移动到新平台和新领域，同时将其它流程或子流程留在现有的领域中，并确保可以将其作为新旧混合体投入生产。
如果我们查看上面的地图，我们可能会发现现有的 CRM（基于传统技术的定制解决方案）无法满足需求，并且是整个系统可扩展性的瓶颈。因此，提高可扩展性是我们希望通过此 MVM 实现的结果。
此 CRM 模块处理的业务事件已被识别，例如 LEAD_CREATED、LEAD_CONVERTED、CUSTOMER_DETAILS_UPDATED……我们可以在新的目标域中构建一个新的 CRM 模块。
绘制旅程图——搭建桥梁
为了能够将这个新的 CRM 模块发布给客户，同时将与之通信的其它系统保留在现有域中，我们必须在两个域之间建立一座桥梁。桥允许我们的事件在域之间双向流动。 （注意这些是我们的业务事件，不是技术事件）
事件驱动的无服务器架构 — 使用 Amazon EventBridge
例如，如果新的目标域是 AWS 上的事件驱动无服务器架构，那么 Amazon EventBridge 很可能是新系统微服务之间事件的通信总线。幸运的是，Amazon EventBridge 具有灵活的开发工具包并支持跨账户事件。例如，如果我们从 AWS 上的单一 .NET 应用程序的现有域迁移出去，我们可以使用 AWS 开发工具包直接从现有代码库调度事件。或者，如果无法更改现有系统，数据库触发器或网络代理可以拦截和推断事件。
一旦 CRM 模块的迁移完成，它在逻辑上只是将事件调度到新系统，我们可以上线，交付价值和测试之前的迁移假设！允许我们避免因新旧系统完整性对比没通过导致的死循环。在这个例子中，我们带来了可扩展性的提升，并验证了一些目标域的技术选择。
MVM 的执行路径
MVM 本质上是必须迭代执行的。向真实用户发布、测试假设并搜集反馈能为下一个 MVM 迁移提供方向指导。通过混合方法，逐步将每个逻辑系统和子系统迁移到新域，从而允许完整的业务操作在所有步骤中运行。
并且，剧透警报……没有最终的「未来系统」。相反，渐进式 MVM 一直在不断发展，但这次采用的是事件驱动架构，可以适应不断变化的客户需求和技术进步。
注意：与 Martin Fowler 著名的 Strangler Fig Application 方法肯定有一些重叠。
综上所述
最小可行迁移 (MVM) 为迁移项目带来了敏捷性，这些迁移项目通常受到全有或全无瀑布交付的限制。这让我们可以更早地发布、测试假设、更快地为用户提供价值，最重要的是——团队学习和总结。
MVM 是通往可能的非最终版「未来系统」的迭代垫脚石。 MVM 的核心依赖于事件驱动的思维方式和架构，因为它们提供了领域之间干净的双向接口，并且可以自由地拥有不受底层技术影响的恒定思维模型。
渐进式迁移并非没有挑战。管理数据复制和跨域网络仅是其中的两个例子。尽管这些挑战是值得的，因为它提供了云服务迁移项目成功所需的敏捷性，并避免追求「完整迁移」带来的业务瘫痪。
MVM 自然非常适合企业云服务现代化——迁移到无服务器，但该方法也同时适用许多其它领域的数字化业务迁移。
如果您喜欢这样的内容，请考虑订阅我们的每周通讯！
（作者：Ben Ellerby，Aleios 公司创始人和 AWS Serverless Hero）
