乐视网发起设立规模5亿至10亿元的投融资并购基金
06-18
将企业软件迁移到云的现代方法通常缺乏确保成功和最大化用户价值所需的敏捷性。
从事件的角度思考数字业务的设计，不仅提供了通向最先进的事件驱动架构的路径，而且提供了改进可随着客户需求和技术迭代的“非最终形式”架构的目标进步。
。
我们需要摆脱云计算迁移的“大爆炸”思维，并利用事件来映射一系列“最小可行迁移”（MVM最小可行迁移）的非最终答案，以保持最新并适应变化。
本文介绍了最小可行迁移/MVM 的概念，特别关注向无服务器云原生架构的迁移。
遗留系统/遗留系统/遗留系统/遗留系统，这个经常被低声谈论的术语，仿佛它是一个淫秽的词，是所有科技公司技术文化的现状。
在某些方面，“遗留系统”是一项成就——它有效、成功，现在是时候发展了。
企业软件上云需要作为项目进行管理，并且必须敏捷。
很多人面临的最新云计算模式是“云原生”和“无服务器”，那么如何为这样的迁移项目带来敏捷性呢？敏捷迁移 大多数团队都会采用敏捷方法来推出新产品和服务。
从最小可行产品 (MVP) 开始并迭代发布 - 收集反馈、测试假设并更快地为客户提供价值。
最小可行产品 (MVP) 是具有足够功能的产品版本，可供早期客户使用，然后客户可以为未来的产品开发提供反馈。
MVP 使我们能够更早地测试假设、更快地学习、减少浪费、更早地交付给客户并验证假设。
然而，当涉及到迁移项目时，这种情况通常会消失。
一旦新系统与现有系统达到“功能对等”（一组等效的功能和功能），团队就会寻找“大爆炸”版本。
云迁移和现代化云迁移是将数字业务资产和运营转移到云提供商（或另一个云提供商）的过程，随着公共云的出现而变得非常流行。
这些迁移通常采取“直接迁移”的形式，其中一些迁移后来只在需要时才专注于重构。
迁移的核心是域的更改，从域 A 到域 B。
这可能是从本地到公共云提供商的“传统”云迁移。
软件编程语言或技术框架级别的迁移。
将架构层从整体架构迁移到微服务。
或者从经典云托管解决方案到云原生、无服务器架构的云现代化（迁移）。
无服务器正在成为云的未来——它们是一组服务，允许您构建和运行应用程序，而无需考虑服务器（以及它们下面的所有依赖资源）。
无服务器架构降低了总拥有成本，使开发人员能够提供更多业务价值，并从第一天起就自动扩展。
因此，很多企业都希望通过“云现代化迁移”将应用程序迁移到Serverless。
对于许多人来说，这涉及掌握一套新技术以及重构和重组他们的应用程序以充分利用云。
以敏捷和增量的方式做到这一点可以采用迭代的现代化方法——降低风险并更快地交付价值。
增量迁移在纸面上看起来可能比“大爆炸”大规模迁移更复杂。
我们需要复制数据、编写接口并牢记两个系统。
除此之外，我们可能会冒着损害新系统与旧系统集成设计的风险。
如果我们循序渐进，就很难采取大胆的行动从根本上改变这个体系——毕竟，“我们不需要更快的马”。
幸运的是，通过正确的方法和技术，增量迁移可以变得更简单、更具成本效益且不那么令人畏惧。
从本质上讲，云现代化迁移不仅仅是“升级转移”，还需要系统重构。
这增加了复杂性，但也有机会发现创造性的增量迁移方法并充分利用云。
数字业务和系统建模 计算机科学家在对他们构建的系统进行建模时可以使用许多工具。
所有这些都有不同程度的抽象和标准化。
瀑布迁移项目，典型的升降式迁移项目，通常会模拟“系统的现状”和“系统的未来”，但是“逐步发展的系统之间”又如何呢？如果我们要从现在的制度逐步过渡到未来的制度，这不是一个单一的垫脚石状态，而是一个旅程。
现代最先进的云架构通常是“事件驱动的”，这意味着系统通过事件（系统变化的信号）相互交互。
事件：系统触发表示系统更改的事件（例如，进入 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 应用方法肯定有一些重叠。
最小可行迁移 (MVM) 为通常受到全有或全无瀑布式交付限制的迁移项目带来了敏捷性。
这使我们能够更早地发布、测试假设、更快地为用户提供价值，最重要的是——作为一个团队学习和学习。
MVM 是迈向“未来系统”可能的非最终版本的迭代垫脚石。
MVM 的核心依赖于事件驱动的思维和架构，因为它们提供了域之间干净的双向接口，并且可以自由地拥有独立于底层技术的恒定心智模型。
增量迁移并非没有挑战。
管理数据复制和跨域网络只是两个示例。
不过，这些挑战是值得的，因为它提供了成功的云服务迁移项目所需的敏捷性，并避免了追求“完全迁移”所带来的业务瘫痪。
MVM 自然非常适合企业云服务现代化（向无服务器迁移），但该方法也适用于数字业务迁移的许多其他领域。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-17
06-18
06-18
06-18
06-18
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态