lawrence krubner 曾经是三家初创公司的技术联合创始人，其中两家公司在发展到中等规模后就被卖掉了。在过去 20 年，lawrence krubner 一直帮助大中型公司做技术咨询，而在最近与一家大公司的合作中发现：这家公司的技术栈实在是太糟糕了，以至于两年时间花了不到两亿人民币也没能构建出统一的 API 系统。
两年近两亿，未能构建出一套 API 系统
由于涉及商业隐私等问题，lawrence krubner 将这家大型公司称为 SuperRentalCorp，这家公司拥有 11000 名员工，分布在 180 个国家。两年之前，这家公司就在尝试构建一套 API 系统，并决定成为 MuleSoft （一家提供基于云的应用集成服务商）的客户，帮助创建一套新的 API。
到目前为止，lawrence krubner 已经在涉及 MuleSoft 的项目上花费了大约 2500 万美元（换算成人民币超过 1.7 亿人民币）。MuleSoft 有一些用于构建 API 的工具，但这些工具对读操作的帮助远大于写操作。也就是说，MuleSoft 有助于处理简单的事情，但对复杂的事情帮助不大。
在 lawrence krubner 最初被告知这一消息时，他认为非常不可思议。他表示：“现在是 2019 年，有一百万个工具可以轻松设置 API，为什么这是一件非常难的事情呢？一个好的工程师甚至可以在一天时间内完成这项工作，为什么 SuperRentalCorp 如此挣扎呢？”
历史原因：沉重的技术包袱
lawrence krubner 最初的想法是假设有一个数据库，你只是把 API 放在数据库和外部世界之间，这是他工作过的早期创业公司的常见场景。有一个 greenfield Ruby On Rails 项目，可以在一个小时内构建这种 API。但是，在了解了 SuperRentalCorp 的历史之后，我对这个问题有了更加全面的理解。
SuperRentalCorp 成立于 100 多年前，当时世界上大部分地区由几个欧洲帝国统治，大多数公司在一些西方国家经营全球业务。但在 1948 年至 1980 年间，所有的旧帝国都分崩离析，取而代之的是 100 多个新国家，每个国家都在保护自己获得的独立性。因此，SuperRentalCorp 决定采用去中心化的结构。在大多数国家设立子公司，子公司作为独立公司经营。有时，子公司的部分所有权被出售。这意味着，当上世纪 70 年代末第一批大型数据库出现时，这家公司没有中央数据库、中央 IT 部门，没有 CTO 或 CIO。
不久之后，由于局势比较稳定，合并一些服务的好处显而易见。因此，SuperRentalCorp 合并了一些子公司，成立了区域公司。有一家区域公司负责中东和北非，一家负责欧洲，一家负责北美，一家负责亚洲，一家负责南美。伴随着这种结构调整，公司进入了 90 年代，这时公司开始认真通过网络数据库管理所有服务。
面对上世纪 90 年代激烈的全球竞争，该公司决定通过收购其竞争对手来实现增长，这种收购一直持续到 Web 2.0 时代到来。
最近，新的首席执行官决定：最好是把公司团结起来。几家国际子公司被 100% 收购，目前正在进行重组，以使它们作为公司内部的部门运作，而不是独立的公司。
基于上述背景，SuperRentalCorp 希望创建一套统一的 API ，以使外界认为该公司拥有内部统一的技术架构。也就是说，SuperRentalCorp 希望创造一种幻像，即公司只有一个数据库，并且很容易与该数据库交互。
但现实如何呢？SuperRentalCorp 有 20 个主要数据库，由 20 个不同的团队在至少 10 个不同的国家里运行，这些团队中有许多都曾作为独立的公司运营。每个团队都想保护自己的数据，部分原因是出于安全隐患的担忧，部分来自于当地法律关于用户隐私的担忧，以及国际用户数据转移的规定，而部分只是单单因为脾气倔。
与任何数据库操作一样，这里有两个关注点：读和写。
读其实并不难。我们可以从 20 个不同的数据库中提取（必要的）数据，将数据存储在一个充当缓存的集中式数据库中，并在该数据库和世界其他部分之间放置一套 API。陈旧数据可能会有一些小问题，我们必须进行实验来确定哪些数据是高优先级的，需要在几秒钟内复制。不太重要的数据可以每 5 分钟复制一次，或者在更新时再通过触发器进行复制。
读并没有那么难 (不容易，但也不是不可能)。
而写却是另一回事。如果伦敦的用户想从一间伦敦的子公司租用数据资源，租用请求（数据库写）将发送到中央 API，但这是否意味着中央 API 必须得知道要写到内部哪个特定的数据库？同样的，在尼日利亚、德国和巴西发生的写请求也将进入不同的数据库。这就变成了一场噩梦。二十年前，这种思路导致了企业服务总线体系（ESB）结构的创建，但是 ESB 现在已经不受欢迎了，因为它过于复杂、僵硬和笨拙。
在最佳集成架构方面，在我看来唯一的长期解决方案是类似于 Jay Kreps 在 2013 年所写的统一日志架构。所有进来的写操作都需要放入一个集中的日志中，比如 Kafka，然后各个数据库就可以从中提取需要的东西，每个团队都可以从中心日志中决定需要什么。
然而，SuperRentalCorp 有使用 POS 机（销售终端）系统的零售店，它们与特定的数据库直接对话，并且写路径（直接 POS 机到数据库）是硬编码的方式，这很难改动，所以它需要花费数年来建立单一的 write-point（写操作端点）。
目前，每个数据库团队需要接受来自多个源的写操作。但从长远来看，统一的日志是可行的。这对 20 个团队中的每一个来说都代表着一个巨大的过程变化。这也有助于解释为什么该公司花了两年时间和 2500 万美元试图构建一套 API，但到目前都没有成功。
外包靠谱吗？
如上，我只讨论了来自内部数据库和内部流程的问题。从某种意义上说，与依赖外部服务供应商相比，内部问题都很容易，因为外部供应商都不受 SuperRentalCorp 的控制。从上世纪 90 年代开始，出现了一种管理理念，主张公司应该专注于“核心竞争力”，把其他一切都外包出去。这就好像你是一家报社，不需要雇佣门卫来保持办公室的清洁，而是把清洁工作外包给一家专门从事办公室清洁的公司。
如果什么事情都亲力亲为，那么你就犯了“非我发明综合症”（Not Invented Here Syndrome）。尽管我已经看到了这样做的缺点，但在这个论点中有很多我同意的地方。外包限制了灵活性，因为你最终与外部公司建立了长期的、紧密的联系，而这些公司可能不会随着你的需求而发展。尽管解雇一项清洁服务公司并雇佣另一项清洁服务公司似乎很容易，但有一些种类的服务是很难替换的。
早在上世纪 90 年代，SuperRentalCorp 就决定将客户忠诚度计划的管理外包出去，因为这被视为一项财务职能，而 SuperRentalCorp 并不是一家财务公司。他们外包的公司也落后于时代，原始得令人吃惊——该公司没有为他们的服务提供公共 API。现在，当 SuperRentalCorp 想要将忠诚度系统嵌入在各种 CRM（客户关系管理）和 POS 系统时，却做不了，因为它在公司里对管控忠诚度计划的技术决策没有控制权。是的，SuperRentalCorp 可以终止与这家公司的关系，并开发自己的技术来管理忠诚度计划，但他们已经在技术上浴血奋战多年。目前，很难这么做。
信任问题
这个问题一部分归咎于技术问题，一部分归咎于信任问题。如果希望构建统一的 API 系统，每个团队都必须放弃一些权力，然后信任一条他们无法控制的流程。当公司有了新的 CEO 之后会发生什么呢？如果决定再次打散公司怎么办？团队能在多大程度上信任当前企业战略的持久性？他们是不是应该给自己留点余地，好让自己能够回到过去做事的方式？
数十亿美元的公司不断地与那些不守信用的内部和外部参与者（外包）打交道。这不是仅存在于理论中，这是现实。关于如何更敏捷的说法并没有多大帮助，因为他们面对的是关于公司结构、所有权和战略的实际问题。
大公司不断面临着被公司内外的贪婪所毁灭的风险。创业公司更容易处理信任问题，因为当整个团队只有 5 个人的时候，互相看着对方的眼睛就可以大致看出他的状态。如果在 180 个国家拥有 11000 名员工，那这就是不可能的了。在很大程度上，“敏捷”几乎等同于“相互信任”。如果想知道为什么大公司在敏捷方面有困难，部分原因是 11000 人不可能像 5 个人那样相互信任。
综上，所有这些都有助于解释为什么在规模更大、历史更久的公司，技术改造很困难，因为需要不断与历史进行斗争。
评论