甲骨文ACE总监：我们真的可以做到“去Oracle”吗？

译者注：在中国，“脱离”甲骨文，是被迫的行为，因为国家层面在推动去 IOE（IBM 的小型机、Oracle 的数据库、EMC 的存储），减少高新技术行业对国外的依赖。但是国产替代品一方面其性能、可靠性还不足以完全取代，另一方面由于兼容性、风险控制的原因，替代也是长期逐步进行时。无独有偶，国外大厂也在尝试“脱离”甲骨文，早在十年前，IBM 就曾发起过“破甲行动”。最近几年，亚马逊、Salesforce 等正在开发自己的数据库，以脱离甲骨文。这是怎么回事呢？尽管甲骨文在传统领域仍然有稳定性和性能上的优势，但是它的问题也特别的多。归根到底，是甲骨文落后于时代太多，不能适应现在的业务场景，维护和运行成本又很高，而且不可控，出问题只能找甲骨文解决。本文作者给出了“脱离”甲骨文的思路。

越来越多的组织向我们表达了这种愿望。有时候会成为一个很无聊的问题。但这只是一半的愿望。很明显，组织们已经不再需要一样东西了，但是他们还没有明确表示他们需要什么。我们在此追求什么？

那么甲骨文（Oracle）究竟意味着什么？甲骨文拥有广泛的产品组合，当然也是一家公司，一种业务关系。我们是否应该撤掉所有的产品，并断绝与甲骨文的一切联系？求助者是否完全不知道他们的公司正在使用该供应商的产品？很明显，这样的操作需要相当大的成本、精力和风险，是否有一些商业案例？正如我们作为架构师所被问及的所有问题，我们必须理解请求的背景和真正的目的，因此我们将提出一个“权力问题”：为什么？

在本文中，我们先来看一下想要脱离甲骨文的原因。接下来，我们将描述“甲骨文”一词所代表的内容——在各个级别的技术栈和不同的业务领域中，有 2000 多种产品。最终，我们将会描述出“脱离”的含义：定义你要“迁移”的地方，然后实际去那里。

如果你对当前的 IT 现状不满意，那么就很清楚了，为什么你应该考虑放弃甲骨文或者其他厂商的技术。你需要专注于实际问题和目标，并为你的实际需要制定适当的路线图。

为什么（脱离甲骨文）？

这种请求帮助脱离甲骨文的背后原因，通常是甲骨文公司代表的行为。强硬的、短期的销售行为、对客户成功（与所收购的甲骨文产品有关）有限的明显兴趣、持续的沟通中断，以及来自许可证管理服务（License Management Service，LMS）的意想不到的、大量增加成本的裁决，以及无法理解的价格结构变化，这些因素的组合阻碍了许多甲骨文客户的发展。高价格的支持组织的认知价值下降，以及雇佣 ACS 来实际解决问题的额外成本，也是不利的。甲骨文似乎经常被认为是僵化、生硬、利用客户的依赖性和误导性的傲慢。

“跟一个这样对待你的利害关系人一起，你就别想做生意了。毕竟，他们的产品并没有那么特别。”

和许多供应商一样，当然也不比其他供应商逊色，甲骨文也热衷于推出新产品，停产现有产品，有时产品生命周期短得惊人，而且也不总是关注现有客户的清晰迁移路径。甲骨文的产品团队通常是严格地从他们自己的背景出发，而不会在与客户一起构建的历史和由客户构建的历史方面承担太多的协调和责任。

恼怒是差劲的顾问。

尽管在许多情况下，恼怒是很容易理解的，但是这本身并不能迅速地为类似的情况提供一个合理的商业理由，从而摆脱甲骨文（产品）或其他供应商的产品。正如恐惧、不确定和怀疑一样，恼怒也是一种不好的引导。但这有理由让人恼火，这会给商业关系蒙上一层阴影，同时也是对这段关系进行批判性评价的原因。但这类评估应采用商业和技术原因，而不是情绪化的反应来完成。

有些事情可以而且应该去做。与任何其他关系一样，与对方交谈并讨论这些问题会对所有相关方都有帮助。无论是否是由甲骨文合作伙伴和 / 或其他甲骨文客户共同参与，与甲骨文组织进行认真的对话，都有可能有助于消除误解或恼怒。如果不能对备选方案或商业案例进行适当的分析，仅凭直觉作出情绪化的反应，脱离甲骨文（技术和供应商），则可能导致更坏的结果。退后一步，深呼吸，尽可能客观地评价形势，这总是更好的选择。

持续技术评估

对组织所使用的技术栈进行定期评估是一种良好的实践，它应该产生一个更新的路线图，其中包括一个中期计划，以便加以巩固、严格控制或淘汰，并用可行的备选方案来取代。要注意的是，继续使用一个组件和选择替代它一样，都是一项决策。

这类定期审查可防止组织采用和维护已不安全的技术，或在市场支持不足时可能承担更多的责任，从而增加了依赖供应商的风险，也增加了维护、操作和开发成本。

因为市场压力和业务不断变化，IT 应该提供一个方法来应对这些压力。这也是对架构和技术栈以及它们仍然提供创新功能的能力进行持续评估的另一个原因。

“在我的新云里没有旧垃圾。”

很多组织都特别想要重新考虑技术堆栈，这就需要制定云策略。到了重新审视 IT 领域已经建立很久的产品（这当然也适用于 SAP、微软或 IBM 等），并将其淘汰的时候了。

成本高昂

谈到成本问题时，我们有时会遇到另一场关于甲骨文的争论：“成本（太）高”。这个听起来可能没有那么感情用事，但是它仍然是很主观的。“昂贵”是一种判断，它反映了成本和收入之间的关系，也就是与现实的替代方案相比较。

昂贵 = （运营成本 + 管理成本 + 维护成本） > 收入 || （甲骨文解决方案的运营成本 + 管理成本 + 维护成本）>> （同等替代栈的成本）

当然，可以想象，现有的基于甲骨文的解决方案的成本要高于它所产生的业务效益，或者高于替代解决方案的成本。要是这样，迁移的成本就可以收回来，这看起来就是将特定的应用脱离甲骨文的最好理由。注意：现有的基于甲骨文的解决方案可能太大，这会产生额外的成本，而这些成本可以通过减少运行时环境的规模而得以降低。

假如你用今天的技术，就像 15 年前的老版本一样，你会得到 15 年前的成果（而 15 年的创新并没有让你受益）。

企业想要经常摆脱的东西往往是一个复杂的方面，它阻碍业务创新，并增加 IT 成本；甲骨文在很多情况下都是这种混合的一部分（IBM、微软、SAP 也是如此）。

尽管甲骨文目前的环境功能很差，而且价格并不便宜，但是可以想像，如果使用同样的产品，比如更有效、更好的使用，就会有很好的效果。甲骨文的开发者和管理员们使用了 2020 年的技术，就像他们使用 2010 年甚至 1995 年的技术一样。云计算进一步加快了技术创新的速度：每隔一季或者更短的时间就会发布新的功能和更好的机制。对当前技术能力的更好理解，以及对更现代的软件交付和软件操作管理的过程设计，能够带来实质性的、令人惊讶的结果改进。

路线图对所有技术组件和与之一起创建的系统来说都是非常重要的，一个前进的方向。6R 模型描述了可以考虑的各种方向：退役（Retire）、保留（Retain）、重新托管（Rehost）、重构（Refactor）与重新架构（Rearchitect）、重新平台（Replatform）和重新购买（Repurchase）。简单的说就是：告别、保留（可能还有现代化）、带到新的环境（通常是云端）、现代化和改进（在同一基础上进行翻新）、用新选择的平台组件重建、用标准解决方案替换。

6R：摆脱当前甲骨文组件的六种方法。

可以通过以下方式探讨“脱离甲骨文”的愿望：从以甲骨文某些产品的成本、灵活性、可管理性、安全性和规模为基础的现状走向一个理想的情况，在此基础上，可以开发、推出和管理具有吸引力的总体拥有成本的敏捷控制软件。这张图直观地展示了这些选项。

6R 模型应用于 Oracle 数据库。退役、保留（和翻新）、重新托管、重新平台、重新构建和重新购买（替换）。

其理想的情况包括人员（及其信念、参与度、历史和情感、技能和专业知识）、文化、流程、资源以及第三方产品和技术。甲骨文产品可以在这种理想的未来组合中占据一席之地。

迁移到哪里去？怎么迁移？

选择停用一种产品或技术，通常是决定使用另一种产品或技术的结果。渴望别的东西，导致选择放弃现在的东西。对我们来说，“不使用甲骨文”应该是一个过程的结果，在这个过程中，我们会仔细地评估，并自觉地决定“迁移到某处”：开始使用某一产品，然后取代甲骨文产品。

当选择保留或逐步淘汰或替换时，应考虑到不同方面。用来比较某一种技术构件的备选方案的标准包括：

• 适合目的；
• 功能（特定产品或技术组件的作用）；
• 安全性；
• 稳定性和可扩展性；
• 货币 / 最新信息；
• 成本和生产力（购置、开发、管理、维护）；
• 市场接受度；
• 产品路线图；
• 并与现有的环境和组织相适应。

尽可能客观地表示供应商的业务可靠性也是一个准则。

各个组织都希望将 IT 支出控制在一定范围内，同时结合使用和价值，并且能够根据业务需求快速创建和修改功能；甲骨文产品可以很好地成为这种理想状态的一部分。

迁移到替代方案

如果还有比当前解决方案更好的替代方案，那么问题就来了，可能的迁移方案是什么样的。它的成本是多少，谁来承担这些费用，需要多少时间和精力，资源的可用性如何，哪些停机时间是可以接受的，以及这会带来哪些风险，对提供新业务功能的能力有多大影响？一项不言而喻的考虑是雇员的参与程度和积极性：根据他们的技能、学习能力和现有职责，他们是否愿意向这一替代技术过渡？在早期阶段，他们是否参与了决策过程？

金钱总是起着重要的作用。由于迁移的成本包含了许多因素，其中有些因素通常是不确定的，因此常常难以估计。这包括注销尚未完全折旧的应用程序和平台组件，培训受影响的员工，以及暂时降低生产率。有时候，使用了 20 年以上的应用程序，在金钱、知识和情感方面的累积投资远远大于人们通常所知道的。解除该应用程序与其他系统和组织之间的相互关联需要付出巨大的努力，同时也存在巨大的风险。

若能做到这一点，那么这种迁移就像任何重大的改变一样，不能大踏步走，当然也不能操之过急。但是，采用渐进的方法的确会带来其他挑战，如需要在新旧解决方案之间建立复制机制。所以，应该提前做好充分的计划，以避免做出基于错误或不完整的假设而导致额外成本的决策。

要成功地替换正在使用中的组件，需要一个完整的功能和技术规范以及测试集来详细描述组件的使用方法和内容。使用这些方法，我们可以规划和评估现有的替代路径（它本身并无商业价值）。

在现实中，这些规范很少是完整的和最新的，因此，起草一份详细的说明往往是整个过程的一部分。这项研究可用于建立对替换的支持，并确定优化方面的低垂成果。此外，CI/CD 以及业务监测和管理的程序和工具也必须是清单和最终迁移的一部分。

应用程序应该做什么？

在要替换的系统与其他内部和外部应用程序之间的所有交互点进行自动测试，对于确保替换组件的正确性，从而降低风险具有重要价值。这种测试也很少是完整的，因此它必须作为迁移的一部分或在迁移的准备工作中建立起来。

把每一项活动分解成更小的步骤，会使它更简单，风险也更小。在从甲骨文到其他东西的迁移过程中，我们将尝试做同样的事情：定义一个有意义的平台，让我们可以一步一步地进行替换。

技术迁移也与人和流程有关。

相关工作人员，或负责管理和维护应用程序外包伙伴的人员，是迁移过程中的一个重要部分。在迁移的另一面中，他们的功能知识和技能也很有价值。他们的工作环境正在改变——他们必须接受培训、指导，甚至常常受到诱惑，才能利用新产品和新技术独立工作，从而激励他们。并不是所有员工都希望或者能够在离职后继续工作；这可能是人力资源领域的另一个挑战。

现在该做什么？

几十年来，甲骨文技术确保了 IT 和日常运营绩效的连续性，而且对于那些现在宣布要脱离它的组织来说也是如此。假如你还想替换该技术，最好列出一个清单，列出与甲骨文技术相关的、你（仍然）欣赏的、日常使用的和业务需要的东西。它们必须以某种方式回到你将要选择的替代技术中，而这可能被证明是非同小可的。

我们明确向你说明，如果没有积极的商业案例来支持你脱离甲骨文的愿望，无论是在金钱上还是其他措施上，要避免你的恼怒和其他情绪成为你的坏参谋。

从 IT 的问题状态中解脱出来，在很多组织中都是很有意义的，这使得 IT 能够像几十年前那样，并且从现在的问题状态中解脱出来，这也是产生于 IT。毫无疑问，这意味着要舍弃甲骨文的某些产品。其中可能包括保留甚至引进新的甲骨文技术产品。

左边是大多数组织想要抛弃的情况。即使甲骨文不是许多不希望的方面的原因，它通常也是混合的一部分。右边是组织想要转移到的情况。甲骨文技术通常也将成为这个闪亮的崭新世界的一部分。

作者介绍：

Lucas Jellema，荷兰 AMIS 解决方案架构师、首席技术官。甲骨文 ACE 总监、革新者大使、JavaOne 摇滚明星和程序员。

原文链接：

https://medium.com/real-vox/what-if-companies-say-help-me-move-away-from-oracle-ffbbc95afc4f