\n\n本文分析了数据栈整合带来的隐藏风险。大型并购将中立开源工具变为平台专有功能，导致“架构债”累积和团队技能萎缩。工程领导者应重视架构中立性，确保系统的可移植性。
译自：What engineering leaders get wrong about data stack consolidation
作者：Anil Inamdar
当 IBM 宣布以 110 亿美元收购 Confluent（在此之前不久还吸收了 DataStax）的协议时，大多数评论都集中在这次收购对 Kafka 的路线图意味着什么，或者 IBM 是否能执行云原生集成策略。虽然这些问题很合理，但工程领导者们的思考可能过于狭隘了。
当团队依赖的开源工具不再保持中立时，工程自主权会发生什么变化？
这部戏我们已经看过很多次了
这种模式已经熟悉到足以给它起个名字。一项开源技术之所以出现并获得广泛采用，是因为它真正保持中立且非常有用。没有人拥有它，也没有人能完全控制它的路线图。你的团队在这些项目上的专业知识可以转移到任何地方，它成为了行业标准。然后，一家大型老牌公司收购了其背后的商业实体，这项技术便缓慢地（或者往往并不那么缓慢地）从社区资产转变为平台功能。
如果你达到了一定年龄，你会看到这在虚拟化领域发生过，然后更近期是在早期的云时代。现在，我们正目睹这在流处理和数据库基础设施领域同时发生。你所依赖的数据栈工具正被吸收到更广泛的企业关系中，从“同类最佳”的选择重新定位为捆绑功能。
需要明确的是，这一切并非心怀叵测。整合在商业上是有意义的，而且有时在更多资源的支持下，工程质量确实会变得更好。但收购消除了一些即使在商业供应商基于开源构建专有功能时也很重要的东西：即保持客户能够离开的竞争压力。在收购之前，供应商锁定是一个供应商会非常谨慎管理的风险。在收购之后，它就变成了母公司平台战略的一个功能。
被贴错标签的风险
当高管对话中谈到整合时，通常会被归结为采购问题。价格杠杆和合同条款确实重要，但它们只是更严重问题的下游产物。整合随着时间的推移悄无声息地创造出来的，其实是我称之为“架构债”的东西。开发者常说的技术债务是指代码中需要重新审视的捷径，但这有所不同。架构债累积在基础设施层，而且更难察觉。
“整合随着时间的推移悄无声息地创造出来的，其实是我称之为‘架构债’的东西。”
当供应商将 Apache Kafka 之类的工具集成到其专有云中时，它会增加便利层。这些可能包括自定义 API、专门构建的连接器以及与其更广泛平台挂钩的安全钩子。孤立来看，每一个都是合理的，但经过 3-5 年的积累，你最终得到的东西将不再是可移植的或基于标准的基础设施。你现在拥有的是该特定供应商平台的自定义实现，即使你从未打算这样做。
这种债务不会出现在代码审查或你的技术路线图中。当你尝试迁移或重新谈判时，它才会显现出来，到那时，解除这些依赖关系的成本可能会高得惊人。供应商当然明白这一点。高昂的转换成本是他们的护城河，无论他们是否继续在你购买的产品上进行创新，这都能保护他们的收入。
这种动态也存在于我们的市场中，以免显得我在针对任何一家公司。任何在开源技术之上增加过多专有工具的数据基础设施托管服务提供商，都会产生某种程度的这种问题。工程领导者面临的问题是，这种依赖关系是自觉构建的，还是默认形成的。
组织架构图看不见的成本
随着架构债的加深，它也会拖累其他东西。
在的中立开源环境中，你的工程师学习的是核心技术。例如，他们了解 Kafka 在分区层级是如何工作的，以及 Cassandra 在负载下如何处理一致性。这是属于工程师的可转移知识，而不是属于平台的。
然而，在高度托管的专有环境中，团队不再学习流数据，而是开始学习“供应商 X”的流服务。随着时间的推移，底层技术的专业知识会萎缩。团队操作原始技术的能力越低，他们就越依赖供应商的托管层，从而进一步减少了接触底层技术的机会。这个循环闭合了。你组织的制度性知识正在悄悄地迁移到软件提供商的支持团队中。这种风险很少出现在任何风险登记册中，并且会随时间推移而复合增长。
真正的“刻意中立”是什么样的
这并不是反对整合，也不是主张每个团队都运行自己的开源基础设施。大规模运行 Kafka 确实很难，托管服务的存在有其充分理由。
更多领导者需要理解的是，架构中立性以前是随开源工具自动提供的。现在不再如此了，那些将其视为理所当然的工程领导者，实际上是在通过“不做决定”来做出决定。
这种区别会产生实际后果。当你的团队在评估一项托管数据服务时，该技术今天是否好用只是对话的一部分。更有价值的问题是，正在构建的集成点在三年后是否仍然具备可移植性。一个实际的测试是：如果你必须在 18 个月内离开这家供应商，你的团队能否在无需耗时数年的情况下完成迁移？明显的犹豫本身就是一个答案。
坚持开放标准而非开放 API 是其中的一部分，同样重要的是，要有纪律让你的内部平台来定义与供应商工具的接口。如果这种关系反向运行，你就是在根据别人的决定来构建你的架构。
默认选项不复存在
数据栈将继续整合。这是市场成熟的本质，工程领导者需要在这个现实中做出决定，而不是绕过它。
“可移植性曾是开源基础设施的一个隐含特性。现在它不再是了。”
只要明白，接受整合这一事实与将其视为你实际考虑过的设计约束之间是有区别的。可移植性曾是开源基础设施的一个隐含特性。现在它不再是了。那些现在就采取行动的工程师和 CTO，在下一轮收购落地时将拥有选择权。而那些不采取行动的人，谈判的余地将会小得多。全 端 端
