2011 年 10 月一位 Google 工程师在内部社交平台 Google 上写了一篇吐槽长文。因为隐私设置没搞明白这篇本来只给同事看的内容被公开了随后被科技媒体大量转载成了当年技术圈讨论度最高的一篇“内部檄文”。作者叫 Steve Yegge文章后来被统称为 “Google Platform rant”。十多年过去了文章里的具体案例和技术细节早就过时。但你会发现它讨论的问题——平台思维、API 优先、服务化架构、组织激励、开发者生态——到现在依然是云原生和平台工程领域的核心议题。这篇文章不只是一个技术圈八卦。它其实是一个从业二十多年的资深工程师拿 Amazon 和 Google 两家公司做对照讲清楚“平台是怎么设计出来的”。如果你想搞清楚下面几个问题这篇值得往下看为什么 AWS 能长成巨头生态而 Google 早期很多优秀产品却很难被第三方深加工为什么有些公司内部工具总在重复造轮子平台工程到底在解决什么问题今天这篇就来复盘这次事件并且把它映射到当前做 API 设计、服务治理和内部开发者平台的具体实践上。1. 事件回放那篇被公开的帖子到底说了什么1.1 作者是谁程序员、博主、Amazon 前员工Steve Yegge 在技术圈不是无名之辈。去 Google 之前他在 Amazon 工作多年参与过与电子书、搜索推荐相关的业务开发。他是个很能写的人在博客时代就输出过大量关于编程语言、软件工程和职业发展的长文风格犀利喜欢把一个观点讲到极致。2011 年他加入 Google。站在这个位置回看 Amazon他对两家公司的“平台观”差异体会很深。于是在 Google 讨论 Google 社交产品时他顺势把积攒下来的想法写成了一篇长文。从流传版本来看这篇内容与其说是“吐槽”不如说是一篇夹杂着大量真实工作体验的平台战略分析。1.2 帖子是怎么被公开的当年的具体情况大致是Steve 把长文发在 Google本想设定为内部可见最终却被公开。文章很快就被技术社区和科技媒体保存、转载。这里要提醒一句当时转载流出的版本并不是一次有组织的官方发布属于个人言论的意外公开。我们今天能看到的翻译版本、摘录版本很多但最准确的说法仍要以当时的原始文本为准。很多程序员后来把这篇长文称作“谷歌平台失败史”其实有点标题党它更像一份亲历者视角的观察报告。1.3 核心论点拆解用现在的语言来概括文章的核心论点可以拆成下面几层论点大致内容Amazon 是平台思维服务能力必须通过接口暴露不仅对外部开发者开放公司内部团队之间也必须按服务方式调用Google 是产品思维很多产品追求最终用户体验但缺少让第三方接入、扩展现有能力的基础设施平台不是工具集合有 API 文档、有开放接口只是平台的一部分大量服务的协同、商业模型、开发者支持也很关键组织激励决定平台成败如果绩效只看产品指标团队就没有动力去做长期主义平台投入搜索业务也可以平台化Google 拥有数据和用户能力却一直没有把它们开放成可编程基础能力这是 Steve 认为最可惜的地方这五层内容放到今天看依然能对得上现代公司在做“内部平台”时的痛点。产品是直接满足用户需求平台是让更多人能基于你的能力做事这中间的实施逻辑差别很大。2. 平台思维与产品思维一条容易混淆的界线2.1 什么是平台思维Steve 在文章里强调的“平台思维”核心是把能力抽象成可复用、可编程、可被他人扩展的基础服务。搜索引擎对普通用户来说是一个产品但如果把搜索能力开放成 API让企业可以构建垂直搜索工具那它就变成平台。数据库引擎对开发人员来说是产品但把它托管成云数据库按需调用、弹性扩展它就成了平台。平台思维不关心“最终用户点击了什么”更关心“开发者能不能利用这套能力做出自己的东西”。一个最直接的判断标准是如果团队把某个能力封装成服务并且允许团队之外的调用方通过网络接口使用它这个能力就是在向平台演进。反之如果所有能力都只能在自家产品页面里操作那无论公司多大都只是产品公司。2.2 产品思维为什么不是平台思维很多团队把“提供 API”误认为“做平台”。实际上平台涉及的东西更多至少包括稳定的契约、版本治理、鉴权体系、配额管理、错误码、文档、SDK、计费或者成本分摊。产品思维关注体验和转化率平台思维关注接入效率和扩展边界。这里放一张对比表方便理解维度产品思维平台思维用户终端用户开发者、其他产品团队核心指标日活、留存、转化接入量、调用成功率、开发者满意度交付形态页面、App 功能API、SDK、CLI、服务目录迭代方式按版本快速发布体验优先兼容优先升级谨慎长期投入功能开发与增长契约管理、文档、生态工具成功标志用户愿意持续使用开发者愿意基于它构建应用不是说产品思维不对。优秀的终端产品非常难得但平台思维能带来更大的杠杆效应。同一份基础能力通过 API 开放给一万个开发者可以衍生出比原团队自研更多的使用场景。2.3 平台化的三个层次在实际落地过程中平台化通常分三层第一层是可复用服务。把公共能力从业务代码中抽出来变成独立服务。比如做统一登录、统一配置、统一文件存储。这阶段还没有对外部开发者开放但内部已经建立起服务边界。第二层是面向开发者开放。服务不只内部使用还能通过 API 被外部应用调用。此时需要完整的接入文档、测试环境、配额策略和版本管理。第三层是形成生态。开发者不只是调用几个 API而是能在平台上面创建、分发、交易自己的应用。典型的例子包括云市场上的第三方镜像、插件系统、低代码平台上的组件市场。Steve 的 rant 之所以犀利是因为他认为 Google 当时的问题恰恰停留在第一层和第二层之间。内部产品已经很多但没有把这些能力统一抽象成对开发者友好的服务生态。3. Amazon 的 API 优先模式为什么让他印象深刻3.1 从 Amazon 内部“服务化”到 AWS 平台化Steve 在 Amazon 的工作经历让他直观感受到了 API 优先带来的工程纪律。Amazon 很早就强调团队之间不能直接读其他人的数据库不能直接共享代码仓库来实现业务调用必须通过服务接口完成。这套规则后来在公开报道中被反复提到和 Steve 文章里的描述一致。表面上看这是为了技术解耦。更深层的意义在于它强制每个团队把能力看作可独立交付的服务。你必须在接口稳定性、数据模型、权限控制方面达到能被外部调用方依赖的程度。这种严谨度很容易迁移到公有云上。当 AWS 对外提供计算、存储、数据库等服务时底层逻辑与内部服务化是一致的。3.2 强制 API 带来的工程纪律强制 API 的效果之一是避免了“改别人的表结构”这类混乱。服务之间的访问变成请求和响应而不是直接操作内部实现。接口的稳定性和可测试性往前迈了一大步。另一个效果是服务拥有者必须回答“我这个能力谁能用、怎么用、用了出问题找谁”。这个要求在开发阶段看起来很麻烦但它逼着团队提前考虑文档、鉴权、限流、错误码。这些围绕 API 的能力反而是平台成长的基础。今天做微服务、做中台遇到的大量问题都可以追溯到服务边界没定义清楚。如果内部团队之间可以随意读写数据库表面上是效率高实际上是把耦合成本推迟到未来。3.3 开发者生态的飞轮当 AWS 把这些服务对外开放飞轮就转起来了API 数量越多开发者越容易组合出复杂应用开发者使用越多平台方越清楚应该补齐哪些服务新服务上线又有更多使用场景被创造出来。这是 Steve 文章里对 Amazon 模式最羡慕的一部分。Google 不缺技术缺的是把技术变成可编程生态的系统性投入。对今天做平台工程的人来说这个飞轮依然成立生态不是靠一个“开放平台”口号形成的而是靠一个个稳定、易用、能解决真实问题的 API 逐渐积累起来的。4. Google 被批评的四个问题4.1 产品之间不打通内部 API 薄弱文章中一个很著名的观察是 Google 内部有很多产品线但产品之间的能力复用并不顺畅。不同团队会遇到相似的问题却往往各自重复解决。本质上是因为缺少一个以 API 为中心的协作机制。这种不打通带来两个代价一是内部开发效率下降二是对外的整体性变差。用户会觉得你家的服务各自为战开发者更觉得很难把 Google 能力整合进自己的产品。当年那个环境下这类批评并不是孤例。4.2 面向开发者的 API 开放缓慢Steve 的观点里Google 一些产品在推出时并没有把 API 当作一等公民。即使后来开放了 API往往也是以产品页面的方式去推广而不是以开发者平台的方式运营。对比 AWS 的流程先有 API再有控制台界面界面只是 API 的调用工具。而很多互联网产品通常是先有产品界面API 变成某个后续补充的功能。这导致开发者接入的优先级很低文档质量、版本管理、兼容性保障也很难达到平台级标准。4.3 组织与激励不支撑平台化平台化投入周期长短期指标难看收益归属也很模糊。如果绩效评估只关注产品增长和用户量团队理性选择就是把精力放在短期功能建设上。Steve 的文章抓住了组织激励和平台发展之间的关系。平台建设需要跨团队协作如果缺少对共享基础设施贡献的认可机制潜在贡献者就不会参与。这个观察在今天依然非常准确——做平台工程首先要设计合理的激励机制否则口号再多也没用。4.4 搜索业务的平台化机会在 Steve 看来搜索是 Google 最重要的资产但一直被当成产品没有被打造成可以被第三方深度调用的平台能力。他甚至认为竞争对手如果做类似搜索平台的事情会构成威胁。这个判断当时引发了很多讨论。客观来看搜索能力开放给第三方存在商业模型、数据安全、查询质量等多方面难题不是简单开放 API 就能成立。但其中的核心思路值得保留核心资产如果只能通过自己的页面提供给用户那么扩展性就会受到很大限制。5. 现在回看这篇 rant 是预言还是偏见5.1 后来发生了什么从大趋势来看AWS 在云基础设施上形成了强大的生态云计算本身的赛道选择和平台策略被证明是成功的。Google 这边也在后续多年里做了不少平台化演进开源 Kubernetes、推出 Firebase、把更多云服务放到 Google Cloud 上。尤其是 Kubernetes 能够从一个内部容器编排系统成长为今天云原生领域的基石本身就是“把内部工具平台化并开放出去”的典型样本。从这个角度来说Steve 批评的方向有一定道理平台化的确值得做。5.2 Google 的平台化演进十多年过去Google Cloud 已经是公有云市场的重要参与者API 网关、云函数、托管数据库等基础设施完备程度比 2011 年高出很多。与此同时Google 在 Android、Chrome 等生态上一直坚持平台化路线。但在当年语境下Google 的核心收入来自搜索广告公司更愿意把资源投入到能直接贡献营收的产品上对长期生态的投入谨慎。这种业务结构决定了它的平台节奏和 Amazon 不一样。Steve 的 rant 更多是在表达工程师视角的遗憾而不是完整商业判断。5.3 客观看待平台不是万能药也有人批评 Steve 把 Amazon 模式过于理想化。AWS 的 API 优先模式也有问题比如服务复杂度高、成本估算难、供应商锁定风险。做平台不等于每个业务都要做成平台。小团队在资源不足时先做产品验证市场再慢慢平台化反而更稳妥。所以这篇文章最大价值不是“Google 不如 Amazon”的结论而是提供了一组判断工具平台化需要什么条件、会碰到什么组织阻力、短期利益和长期杠杆之间怎么权衡。这套思考框架比事件本身的八卦属性更有用。6. 平台工程从 rant 到现代工程实践现实中的平台工程不像 Steve 文章里那样只谈战略它已经变成一套可执行的工程体系。下面用几个例子说明当年 rant 里提到的问题在今天的工程实践中如何落地。6.1 API 优先设计平台化的出发点是服务对外能力时先定义 API 契约。这里的常见做法是使用 OpenAPI 来描述接口让文档、代码生成、测试工具都围绕契约展开。下面是一个示意用的 OpenAPI 片段说明一个内部订单服务如何暴露接口openapi: 3.0.0 info: title: Internal Order API version: 1.0.0 paths: /orders/{id}: get: summary: 获取订单详情 parameters: - name: id in: path required: true schema: type: string example: 20240611001 responses: 200: description: 返回订单详情 content: application/json: schema: type: object properties: orderId: type: string status: type: string amount: type: number这只是一个示意文件实际项目里还需要补充鉴权、分页、错误码等字段。重点是API 先行页面和调用方实现跟在契约后面。契约稳定平台才能稳定。6.2 内部服务目录与 API 治理平台化之后服务数量会快速增加。这时候需要有一个内部服务目录把服务负责人、API 文档地址、环境入口、版本策略集中管理起来。示例配置如下services: - name: user-service owner: team-account apiSchema: ./openapi/user.yaml versioning: semver environments: dev: https://api.dev.internal/user staging: https://api.staging.internal/user prod: https://api.internal/user observability: metrics: prometheus/user-service traces: jaeger/user-service这个目录可以被内部开发者门户加载让其他团队像逛应用商店一样发现服务。很多公司做的内部开发者平台本质上就是在做一个更智能的服务目录把 API 发现、权限申请、配额审批、监控告警串成一条线。6.3 开发者体验DX度量平台使用者是开发者平台好不好用要看开发者体验。可以先把最基础的健康检查和接口可用性指标采集起来。示例同样为示意命令# 检查服务健康状态 curl -s https://api.example.internal/health | jq .status # 查看最近 5 分钟调用成功率 curl -s https://metrics.example.internal/api/v1/query?querysum(rate(http_requests_total{job\order-api\}[5m]))这类命令可以进入平台的自动化巡检脚本也可以用来做开发者接入前的自检。当平台团队能看到每个服务的调用量、错误率、P99 延迟时平台的改进方向就变得更清晰了。7. 平台化落地清单如果你来搭建一个内部平台7.1 从第一天就暴露 API做内部工具时不要只做一个 Web 页面要同时提供 API。哪怕页面只是 API 的调用演示也比“页面先行、接口后补”好。这样其他团队可以更早做集成测试平台能力也能更快被验证。反过来说如果一开始只知道做页面后续补 API 时会发现很多页面逻辑已经和服务状态耦合在一起接口设计空间被大大压缩。7.2 文档、版本、兼容性管理平台的生命力来自契约稳定性。给每个接口定义好文档并用语义化版本管理升级。破坏性变更要让调用方有足够时间迁移。千万不要用“反正内部使用随便改”的心态对待 API 契约。实际项目中可以借助工具自动生成文档并在 CI/CD 里检查 OpenAPI 变更拦截不规范的破坏性升级。7.3 可观测性平台服务必须有日志、指标、链路追踪。调用方出了问题第一件事是查平台侧日志平台侧如果查不到调用轨迹问题就会变成两边互相踢球。至少在服务入口打上请求 ID并在响应头返回给调用方。7.4 吃自己的狗粮平台团队应该用自己搭建的平台去开发真实业务功能。如果你连自己的平台都用不下去那么外部团队更不可能愿意用。吃自己的狗粮能最快发现 API 设计问题、文档缺失和配额策略不合理。7.5 建立平台保障机制平台的运行要有保障机制比如 SLO、降级方案、成本分摊规则。内部团队使用平台产品也需要一个快速的反馈闭环。平台团队最好有固定的 oncall 机制问题响应要像对外产品一样严格。8. 给个人开发者的建议8.1 把你的项目也当成平台你现在做一个开源项目或者一个工具可以多想一层别人能不能通过编程方式使用它提供一个 CLI 或 REST API比只提供 GUI 更容易被集成到别人的流水线里。这会让你的项目拥有更大的影响半径。在个人项目里实践 API 优先并不难先定义好输入输出格式再写业务逻辑最后再加 UI。这样做出的项目天然具备被脚本调用的能力。8.2 写博客、开源代码就是在构建个人平台Steve Yegge 之所以能在技术圈留下一笔不只是因为他在 Google 和 Amazon 工作过更因为他持续公开输出观点。对一个技术人来说持续输出高质量文章和开源代码本质上就是把自己大脑里的思路做成可被外部调用的 API。你的文章可以被网络搜索引用你的代码可以被其他项目依赖。这就是个人影响力层面的“平台化”。哪怕没有公司级资源这套逻辑也成立。8.3 学会从历史教训里抽象框架不要把这篇 rant 当成简单的“某公司好、某公司坏”。它的价值在于抽象出了一个框架平台需要明确的契约、合理的组织激励、稳定的服务基础设施以及愿意长期投入的团队。你在设计接口、划分服务边界、做技术方案评审时都可以试着问一句这是不是在为一个可扩展的平台做铺垫答案不一定要“是”但想清楚比不明不白地做要强得多。这里要特别提醒一点无论做内部平台还是外部开放能力都要注意数据和内容合规。接口开放意味着数据可能被更广泛地流转至少要提前确认授权边界、隐私保护和测试环境隔离。特别是在涉及用户画像、人脸、声音、版权素材等敏感能力时合法授权是平台化的前提不是可选项。