企业云迁移的平台工程

十年乃至更长时间的遗留系统现代化停滞期，平台工程如何为企业云迁移及DevOps扫清障碍？

译自 Finally， Platform Engineering for Enterprise Cloud Migration，作者 Jennifer Riggins 是一位科技文化叙事者、记者、作家以及活动和播客主持人，致力于分享文化与技术碰撞的故事，并解读我们正在构建的技术的影响。

伦敦 —— 担任财富 500 强 CTO 的角色可能令人困扰。不一定是在那些占据多数头把交椅的科技原生公司，但对于仍在使用大型主机的 71% 的公司来说，挫折、人员流失和失败的云迁移预算确实很高。这些庞大的企业竞争力缓慢，而且它们系统的无法审计性已经成为一个巨大的安全风险。但如果采取行动太快，可能会对收入造成灾难性的影响。

遗留系统现代化是一个价值数十亿美元且前景无穷的行业。究竟是什么阻碍了团队获得 DevOps、开源和云的好处？平台工程和生成式 AI 如何实现第一种使用案例并从那里加速？

Rob Mee、Mechanical Orchard 的 CEO 在接受 The New Stack 采访时表示，忘记提升和转移，走渐进式的道路。继续阅读以开始理解先前迁移尝试失败的原因，以及您可能如何使下一次企业云迁移成为最后一次。

没有 CTO 官希望留下的遗产

平均年龄在 50 岁出头的财富 500 强 CTO，他们现在的职位可能是最后一份工作。这使他们左右为难，既希望在最后获得成就感，又不愿惹是生非。而且，拥有数百万客户，避免中断至关重要。他们很可能已经走过这条数字化转型之路 —— 不止一次。他们的怀疑和沮丧完全可以理解。

然而，"事物运转良好就不要去修理它"这一说法已经不再适用。变革的步伐太慢，难以与云原生公司以同样的速度进行创新。实时操作无法实现。

"我们需要这样做，因为这个企业必须进化，"Mee 谈到那些拥有 30、40 或 50 年历史的单体系统的组织时说道，它们有 1000 万行大型主机代码和数十亿条数据库条目，很难招募到接受过相关技术培训的人员，而且遗留知识已经丢失很久了。除此之外，康威定律正在发挥作用，这意味着几十年来，组织及其沟通方式都成长为那种复杂、巨大的技术堆栈的形状。

平均拥有 15 年技术经验的生成式 AI 原生遗留系统现代化公司 Mechanical Orchard 很清楚自己在 CTO 或 CIO 的办公室里将面临什么。

Mee 回想起与第一个客户 —— 一家财富 500 强零售商的早期对话时说:"我把自己置于了困境中，因为我说'我敢打赌我知道你们为什么失败了'。"那家公司每天批量处理数据，无法实现点击并收集以及实时更新库存。"他们说，'好吧，我们已经尝试过三次了，那你就来启发我们吧。'"

他们感到沮丧是有理由的。当一家大型咨询公司未能成功将一家企业迁移到云端时，很少会有单一的失败原因。但 Mee 发现了三种常见的失败方式:

• 项目面临级联复杂性;
• 聘请了一家系统集成商;
• 他们试图一次性完成所有工作。

每一种失败模式都往往会拖延几年时间，在此之后你才能真正测试它是否有效。

"因此，这种感觉就像撞上了一堵墙 —— 或者是多面不同的墙。你可以朝不同的方向前进，试图走出这个迷宫。有一种精疲力竭的感觉，但仍然面临着高压力和高风险，"Mee 说。"而且现在，紧迫感已经从很高升级到了极度紧迫，因为他们开始意识到自己正在错失生成式 AI。"

他继续说道:"这些组织也无法利用开源，而我认为开源是本世纪最真正的开发生产力进化，在云世界中，你会为所有事物使用开源。"

除此之外，他们正在耗尽能够维护系统的人员，因此一切都变得脆弱和紧迫。

并非所有的一切都始于一场大爆炸

"你有一个组织，它和系统已经相互塑造了几十年。如果你无法找到一种方式来合并它们或分阶段进行，那通常会变得过于庞大，"Mee 说道。"还有数据迁移的问题。通常，人们会为此类事情制定一整套数据迁移策略。这也变得非常复杂。而且你还试图在转型过程中保持同等的功能。这些项目最终会面临一系列级联复杂性，它们会变得越来越大，[迁移]最终在几年后失败。"

这些更传统的组织大多数迁移了很少或根本没有迁移，因为他们觉得必须一次性完成所有工作 —— 一次大爆炸式的提升和转移。充其量，他们已经找到了一种方式来创建新的云原生业务部门，同时仍在利用旧的大型主机来完成最初的工作。最终仍将一切以某种方式运行在某种不再受支持或修补的专有软件之上。

其他组织则投资于大规模的翻译工具。

"你可以使用编译器将一百万行 COBOL 代码非常快速地转换为一百万行 Java 代码，但之后你可能需要花费几年时间才能真正将其投入生产并让它运行起来，"Mee 回想起一位曾尝试过这种方式的供应链领域客户时说道。"他们花费了两年半的时间和数千万美元的资金。当他们启动系统并进行用户验收测试时，发现它的运行速度只有原来的十分之一。"

"对我们来说，最难的是让人们克服对那些处理大量收入的系统产生的恐惧感。这些系统已经冻结很长一段时间了。他们不敢去碰它们。他们不敢让供应商去碰它们。他们可能已经失败过多次。" —— Rob Mee， Mechanical Orchard

这个组织已经只剩下极少数人具有对那些代码的上下文经验。但一旦它从 COBOL 变成了机器生成的 Java 代码，就再也没有人具备这样的经验了。

"那种架构将非常类似于 Java 版的大型主机架构，"Mee 说。"正如这个例子所示，你启动它后会发现'哎呀，它的性能很差'，因为如果你是以云原生的方式编写的，就不会这样编写。所以最终你需要花费两年时间才能让它工作。之后你可能还需要再花费几年时间来调优和重构它，使得需要维护它的人员能够理解它。"

在他的经验中，他遇到的几家非常大的组织已经丢失了至少一些系统的源代码。"想象一下，有一个系统已经冻结了 10 年之久，"Mee 说。"客户会说，'好吧，我们失败了。供应商也失败了。这个系统真是棘手，这就是我们冻结代码的原因。'"

但是，如果采取一次大爆炸式的路线，风险将会一直缓解到项目的最后阶段。但就像构建它的瀑布式项目管理一样，这是一种累计风险更大、可能会爆炸的做法。

谨慎，紧跟数据流

如今，当 Mee 与潜在客户会面时，他不会再去猜测他们的失败原因。相反，他会要求他们谈论自己最主要的五到十个技术痛点。然后，Mechanical Orchard 团队会开始根据拦截输入和输出来分析遗留系统的行为，以便从那里以开源、云原生的方式再现系统。这并不意味着他们不会在有源代码时使用它 —— 只是它不再是起点。

"源代码非常有用，但重要的是我们将运行中的系统及其数据流视为真理的源头，"Mee 解释道。"有了这个，我们就可以相对轻松地抛弃他们的代码，"因为在这些几代人的旧系统中，有许多代码已经不再使用或从未执行过。

与他之前创立的专注于为客户提供技能提升服务的 Pivotal 公司不同，Mechanical Orchard 团队实际上是在构建和运行这些企业系统。他说:"我们正在逐步实现现代化，而不是一次大爆炸。我们正在分块进行，并将每一块推向生产环境。"

与其举行并转移，不如从一个试点项目开始，试图展示早期和经常性的进展。他们会从庞大的单体系统中选择第一个切片 —— 最容易隔离的、可能拥有数百个集成的大痛点。他们在一个沙盒测试环境中再现该部分，然后观察它的运作，利用生成式 AI 进行询问，并观察数据如何流经它。之后，他们会反向工程该部分，以云原生的方式用相同的输入和输出重新构建它。

较老的组织天生就是风险规避的。Mee 的团队最初并不直接将系统的部分迁移到云端，而是利用测试环境来避免完全进入生产环境，从而消除变量并无需在两个系统之间进行协调。唯一保持不变的是组织的数据。Mee 的团队需要验证他们能否使用新的云原生代码产生相同的输出。

"我们将向你展示现代化的格式，证明它能够像现有系统一样高效地执行相同的功能，"Mee说。

下一步是将这个新的云原生部分推向生产环境。只有将其从沙盒环境中移出并推向生产环境，他们才能够真正面对企业环境中的实际风险。"我们必须处理安全性。我们必须处理网络。我们必须处理所有的DBA。我们必须穿过组织中所有的障碍。"

这并不是通往云端的一条捷径 —— 需要构建大量技术 —— 但它确实能更快地取得成果，通常在一个季度内就能看到。一旦他们将第一个部分推向生产环境，其对应的遗留部分就可以被淘汰。但同样，这不能是一次切换。虽然Mechanical Orchard负责CloudOps，但其余部分还需要与客户的DevOps团队进行大量协调。Mee说，这涉及到大量的编排工作，"但如果你要逐步部署并及早解决风险，你就必须这样做，努力使编排真正发生。"

事实上，他们发现迄今为止，组织希望将他们构建的系统并行运行的时间远远超过必要时间，以确保最终用户完全察觉不到任何变化，并且这种变化不会扰乱下游系统。

他们尚未完成任何一次云迁移，但目前已有几个组件在生产环境中运行。

Mee 表示，这种一块一块迁移的计划"让我们能够及早解决风险，然后加快、再加快、再加快速度。"