Amazon Web Services

David：结果大家都很喜欢我们讲 amazon.com 的那期节目，反响特别好。这让我有点担心这期的表现。

Ben：当然，反响好得惊人，远超我们以前所有节目。乔治·卢卡斯拍《帝国反击战》时，会不会也有这种压力？

David：你刚才是不是把我们比作乔治·卢卡斯？我们明明很谦虚的。

Ben：好了，开始吧。

欢迎收听 Acquired 第 11 季第 3 期。这是一档讲述杰出科技公司及其故事和经营策略的播客。我是 Ben Gilbert，西雅图 Pioneer Square Labs 及其风投基金 PSL Ventures 的联合创始人兼董事总经理。

David：我是 David Rosenthal，一名住在旧金山的天使投资人。八月的旧金山真冷。

Ben：我们是节目的主持人。David，假设你经营一个柠檬水摊，以最低价格——每杯 1 美元——卖给我品质最高的柠檬水。把柠檬等可变成本，加上租桌子等固定成本都算上，每杯大约要花 98.5 美分。你当然很高兴能赚点钱，但天哪，你得卖非常多柠檬水才行。

David：所以你是说，我就是 2001 年第四季度的 amazon.com？这正是我们要讲的故事开头？

Ben：也许吧。但你发现了件有意思的事：卖柠檬水让你很擅长经营柠檬水生意需要的一切，比如杯子、冰块、柠檬。后来你发现，自己掌握的这些东西也能卖给其他企业。你发现，给别的公司提供服务时，每收 1 美元，成本只有 70 美分。这就是 30% 的利润率，不再是柠檬水那种约 1.5% 的利润率。要赚到同样的钱，你需要卖出的服务远少于柠檬水。

David：如果你这么告诉我，我还会深入调查，发现现有那些卖摊位、杯子之类产品的公司，实际毛利率高达 70%。我会很乐意以 30% 的利润率去颠覆它们，哪怕这比我的柠檬水生意做得更好。

Ben：听众朋友们，我们上一期讲的是 Amazon 的零售业务，这一期讲的是云计算先驱 Amazon Web Services。刚才提到的利润率数字，都是真实的：一个是零售业务，一个是 AWS。

AWS 的营收只有 Amazon 庞大零售业务的大约 15%，但 AWS 的利润，准确说是营业利润，总额却与电商业务相当，甚至更多。我觉得从 2015 年 Amazon 开始单独披露 AWS 财务数据以来，AWS 的年度营业利润每年都高于零售业务。

David：可能有个别季度不完全如此，但整体趋势确实是这样。

Ben：太惊人了。今天我们讲的是和上期完全不同的业务类型。不过，一个从网上书店起家的零售商和云计算先驱之间，其实有很多相似之处，远超你的想象。

说到电商，我们有个大消息：Acquired 周边终于能在网上购买了！网址是 acquired.fm/store，也可以点节目说明里的链接。你可以买自己喜欢的 T 恤、圆领衫、连帽衫、背心，甚至连体衣。我知道很多听众和 David 一样，家里有小宝宝。

听完节目后，欢迎到 acquired.fm/slack，和 David、我以及 Acquired 社群里另外 13,000 位聪明的成员讨论。如果还想听更多节目，可以在任何播客播放器里搜索 Acquired LP Show。

下一期节目邀请 David 在 Kindergarten Ventures 的搭档 Nat Manning，聊他的公司 Kettle 以及再保险业务的运作方式。如果你是付费 LP，这期已经上线；网址是 acquired.fm/lp。

闲话少说，David，带我们进入正题。听众朋友们，请记住，本节目不构成投资建议。David 和我可能投资了节目里讨论的公司。本节目仅供信息和娱乐用途。

David：上一期 amazon.com 的节目，我们讲到了 2007 年 Kindle 故事末尾那段类似 PlayStation 的插曲。当时外界似乎觉得 Amazon 通过 Kindle 正式转型为一家科技公司。我记得《一网打尽》里 Eric Schmidt 有句评论：‘这些卖书的人终于懂技术了。’当然，正如我们聊过的，Jeff Bezos 一直都懂技术。这并不是什么转变。

尤其是，今天整期要讲的内容都说明，这不是什么新变化。为了讲清楚这一点，我们得倒回 2001 年底、2002 年初，也就是互联网泡沫破裂后不久。

现在很难想象，但当时 Bezos 和 Amazon 处境艰难，他就像一位四面受敌的 CEO。公司刚解雇了 COO Joe Galli，董事会请来管理教练 Campbell，Amazon 正在 eBay 和华尔街的夹击下为生存而战。

Ben：会不会很荒唐？董事会是不是觉得 Jeff Bezos 需要一位经验丰富的管理者监督他，好让他学会经营大型公司？这可是 Jeff Bezos 啊。显然，那办法没有奏效；Bezos 重新站了出来，又经营了公司 20 年。

David：之后又过了 20 年，他把权力交给了另一位 CEO。我们马上会花不少时间聊他，也就是 Amazon 现任 CEO Andy Jassy。

我不知道该用什么词形容 AWS。我笔记里写了‘庞然大物’。

Ben：先驱，发明者。

David：没有任何说法能充分体现 AWS 的规模和重要性。它是现代世界最大、最重要的企业、技术和产品之一。

Ben：毫无疑问。

David：我觉得说它甚至比 amazon.com 更重要，也不算有争议。

Ben：有意思。疫情期间也可以说 amazon.com 更重要，因为大家都需要买东西、送货上门。

David：但大家也都需要上网，而互联网运行在 AWS 上。今天我们就来讲这个故事。很有意思的是，市面上没有一本专门写 AWS 的《一网打尽》。相关资料和故事很零散，而且关于 AWS 真正起源的说法互相矛盾、争论很多。你可以说 AWS 的起源有点云里雾里。看出我们的双关了吗？

Ben：确实如此。准备这期节目时，David 和我读了 Brad Stone 写的两本好书，也看了 PBS《Frontline》的纪录片。当然，那部片子采取了特定角度来报道这家公司。你读 Amazon 的分析文章时，95% 的内容都在讲零售业务，比如公司和员工的关系，以及 2015 年《纽约时报》刊登的重要报道。

文章会讲仓库员工待遇，或者问 Amazon 对世界好不好。这些问题重要，也值得关注，但几乎没有文章真正深入讨论 AWS，通常只会附带一个传闻中的创立故事，而那个故事并不准确。

David：你指的是一种 AWS 起源说法。我们发现，不是一种、两种或三种，而是有四种不同的起源故事。这期会全部讲到。我觉得从中可以了解 AWS、Amazon，以及 Amazon 的企业文化。

先从第一个说法讲起。它显然不是真的，但讽刺的是，普通人最相信的恰恰就是这个版本。

Ben：对，因为这个说法很有诱惑力，听起来太顺理成章了。

David：这个说法叫‘闲置容量论’。故事是这样的：2001 到 2003 年左右，Amazon 零售业务和其他零售公司一样，有明显的季节性。第四季度的节假日购物季，流量和需求都会激增，所以公司每年第四季度的营收占比最高。

Ben：据说在公司最初至少五年里，到了十一、十二月就不允许把新代码部署到生产环境。

David：没错。

Ben：那时必须全员待命，除非是严重的故障修复，否则不准发布新功能。

David：我们在 amazon.com 那期没讲过，公司高管、业务部门员工和工程师，多年来每逢第四季度都会去仓库帮忙工作。

Ben：也有人去客服部门帮忙。时代变化真大。你能想象现在有人第一天加入 AWS 就被安排去拣货、打包一阵子吗？

David：我觉得他们后来即使不再需要这样做，也延续了一阵子，作为企业文化的一部分。当然，现在这早已不复存在。都市传说是：因为这个业务模式，在努力实现盈利期间，Amazon 意识到第一到第三季度的信息技术基础设施有大量闲置容量。

他们得按第四季度的峰值需求建设服务器，支撑网站流量和所有交易；但一年剩下的时间里，这些容量都闲着。他们于是想：把闲置容量租给其他开发者。太聪明了，可以把企业的一大笔成本转化为收入。

Ben：简直是变魔术。不过这种说法有很多根本性的问题。首先，如果你待过任何一家云服务出现之前的科技公司，就知道……

David：事情根本不是这么运作的。

Ben：对。你不能说：‘太好了，服务器现在空着，这些服务器没有高度定制，也没有和我们的应用紧密耦合，我们只要让其他公司轻松运行自己的应用就行。’安全性还要设置好，让其他公司能访问我们的数据中心。

网络设备还得能服务其他租户，而不只是服务我们。这些条件当时一个都不具备。绝不可能是其他公司突然开始使用我们的基础设施，然后我们只需简单替换一下设备就行了。

David：云计算之前，你要把软件和代码安装在自己拥有的服务器上。amazon.com 的代码库就是安装在 Amazon 自己的一堆机器上，没法直接把这些容量租出去。

Ben：直到 2000 年，他们用的还是 Digital Equipment Corporation，也就是 DEC 的 Alpha 服务器。这些服务器利润率高得惊人，我想是向厂商租用的。它和 IBM 长期使用的商业模式类似，也和 Oracle 过去或现在的模式相似：把高度整合的硬件与软件平台捆在一起，用来运行应用。

这些产品的毛利率能达到 80%，加价非常高。它们还是一体化的封闭系统。说实话，Linux 才是真正改变这一切的技术。Linux 出现后，你可以用开源操作系统完成原本需要 Unix 工作站才能做的事情。一切都变了，因为你可以买各种硬件、安装 Linux，再自己编写应用。

这为基础设施不必贵得离谱打下了基础。基础设施的所有利润也不必都被 DEC、Oracle 或 IBM 这样的公司拿走。这为后来许多变化奠定了基础，坦白说，甚至帮 Amazon 公司活了下来。

2000 年，Amazon 几乎因为现金紧张而倒闭。他们在基础设施上花了太多钱，于是转向开源体系，大规模重写整个 amazon.com 网站，让它运行在 Linux 上。他们还和 HP 做了一笔大交易，使用 HP 服务器。

David：对，不再用 DEC。

Ben：从成本角度说，这项迁移在公司资金极度紧张时救了 Amazon。

David：不过这不是虚拟化云服务器，也不是我们说的 AWS。还有一个原因说明闲置容量论是个神话。

Ben：如果 AWS 客户也只能使用第一到第三季度的闲置容量，那它第四季度怎么服务客户？假设我是 Netflix，所有视频流媒体都依赖 AWS。Amazon 到第四季度需要服务器时，难道会对我说不能用了？太荒唐了。

David：圣诞节期间不能看电影了，连《虎胆龙威》都不能看。

Ben：如果有人想弄清楚这家网店怎么变成真正的科技公司，‘他们有一堆闲置服务器’这个解释确实很方便，但不符合事实。

David：关于这一点，我们必须引用最接近当事人的说法。AWS 当时的 CTO、现在 Amazon 的 CTO Werner Vogels，2011 年在 Quora 上明确写道：‘闲置容量的故事是个神话。从来不是为了出售闲置容量。事实上，AWS 上线两个月后就已经耗尽了 amazon.com 的闲置容量。Amazon Web Services 从一开始就是一项独立业务，并且预期它最终可以和 amazon.com 零售业务一样大。’也许吧。

Ben：还有件有意思的事要指出：这个故事低估了 Amazon 的主动规划和战略性。

David：没错，它把 Amazon 的能力说小了。

Ben：他们确实有一批额外容量，当时把它视为成本中心。这里有两点。第一，科技业务对 Amazon 来说从来不是成本中心。他们从不认为‘我们有一个 IT 部门’。他们一直把自己看成科技公司。他们总会想：18 个月后，摩尔定律会让算力翻倍，我们能用它做些什么酷东西？他们始终把技术当作投资，而不是成本。

另一点是，就像你说的，这个说法低估了 Amazon 的主动规划。这是一项极其刻意的战略，像全新的商学院案例，精准聚焦在他们有理由相信自己能够创造的新兴市场上。

David：这是第一种起源说法。第二种说法稍后会深入讲。我之前做研究时都没意识到 AWS 的创新有多深，也没意识到 Amazon 为此所做的事情远超当时其他公司的水平。

这是真正的根本性创新。我们先说 Kindle 那个插曲：Kindle 的创意到底来自谁？结果发现是 Tesla 创始人 Martin Eberhard。

Ben：太疯狂了。他发明过第一款电子阅读器，但当时还不够实用。他试图把产品卖给 Amazon，也想让 Amazon 投资。Amazon 说：‘不，我们等技术再发展一段时间，等条件成熟后再做。我们希望完全拥有这项技术，而不是投资一个其他竞争者也可能用的技术。’几年后，Amazon 才在内部开发出 Kindle。

David：AWS 的愿景也受到另一个人的启发，就是 Tim O'Reilly。年纪稍长的听众一定记得 O'Reilly 出版的编程书和他办的会议。对我来说，Tim 和他的组织尤其推动了 Web 2.0 这个概念。

Ben：没错。我记得自己最早读的是他们出的 PHP 书。Web 2.0 的意思是：我不仅能浏览网页，也能在网上发布内容，后来这催生了社交媒体。关键技术之一是 Ajax。我记得读 O'Reilly 的 Ajax 书时，觉得太神奇了：我可以用异步 JavaScript 和 XML 创建动态网页，而不必刷新页面。

David：他们为 Web 2.0 定义了几个核心原则。它部分是相对 Web 1.0 提出的，当时的网页被认为是静态的。正如你说的，Web 2.0 更动态，但不止于此。

Web 2.0 另一个重要概念是参与式文化和互操作性。网站用户可以和网站互动，比如在 Flickr 上传照片，参与并改变网站内容。Google Maps 也是典型的 Web 2.0 项目。但比用户与网站互动更重要的是，让其他开发者也能互操作。Ben，还记得 mashup 吗？

Ben：就是把 API 混搭起来？

David：对。那时 Web 2.0 的 mashup 特别流行。Google Maps 是核心案例，人们用它的 API 和地图数据搭建各种其他网站。Flickr 也有 API。API、互操作、人人都能访问，都是在把我们创建的东西开放出来。

Ben：完全是。现在听加密货币的人谈可组合性特别有意思。我有时觉得自己像个站在树上喊‘别踩我草坪’的老头，但很明显大家没经历过 2006 到 2010 年那波一模一样的承诺。当时人们说的不是智能合约或区块链可组合性，而是 RESTful API、CRUD 操作，也就是创建、读取、更新和删除服务上的数据。

只要通过身份验证，你就不一定非得使用网页界面。你可以直接用 API，程序化上传照片，或者下载自己全部的推文。过去网络上的内容分散在各自孤立的应用里；现在，数据似乎可以自由流动，不受资本主义意图影响，也不会被某家公司关起来独占。

David：这些概念刚出现时，大概是 2002 年初，Tim O'Reilly 飞到西雅图见 Jeff Bezos。他想亲自去见 Jeff，是因为两人过去关系有些波折。O'Reilly 显然是图书出版商，对 Amazon 有自己的看法。他想劝 Jeff 拥抱 Web 2.0，把 amazon.com 改造成一个参与式网站。

Ben：这主意很好。做 Web 2.0 公司意味着你可以不先谈商业拓展协议，就和其他公司做生意。你不需要先签合作协议，只要发布 API，告诉大家按使用量付费、如何付款、如何开账号。必要时我们可以关掉你的账号，但你可以通过应用程序接口，用程序化的方式和我们开展业务。

这很棒。甚至可能两家公司都不需要直接交谈，就能建立合作关系。这样你就能和成千上万家公司做生意，而不是只和业务拓展团队挑选出来的少数公司合作。

David：对，Jeff 完全理解。他看到了 API 对 amazon.com 很明确的商业用途：让其他开发者和网站使用它的数据和内容。他们当时有一个庞大的联盟营销项目，叫 Amazon Associates。

Ben：他们有一个包含各种唯一产品条目的目录，尤其是媒体产品，之后还会扩展到更多类别。要是我在网站上想告诉大家去买这张 CD，能不能直接调用权威目录，拿到产品图片并显示出来？

David：直接显示 CD，再和 Amazon 分享销售收入。

Ben：我这么做对双方都有好处。

David：会后 Jeff 做了两件事。第一，他完全接受了 Tim O'Reilly 的想法，经常邀请他去西雅图，在公司全员会议上演讲，宣传 Web 2.0 和 API 的理念。

第二，他在 Amazon 内部成立了新团队，专门做 Tim 建议的事情。他们开发了 API，让任何网站开发者都能连接到 amazon.com 的产品目录，完成你刚才说的那些事。团队的目标和使命是向开发者开放 amazon.com 的 API，‘让他们用这些工具做出让我们惊喜的产品。’

同一年，Amazon 行动很快，为开发者办了一场会议。2002 年，参会者总共只有八人。他们在会上宣布，Amazon 新成立了一个部门，叫 Amazon Web Services。

Ben：正如你说的，这在当时还不是什么大事。Amazon 只办了一场八个人参加的开发者会议；再看今天的 re:Invent，主旨演讲有 10 万人观看，完全是另一个世界。

David：对，世界不同，产品也完全不同。它叫 Amazon Web Services，但不是大家熟悉的云计算基础设施，而是让开发者使用 amazon.com 的产品目录。最初的 AWS 确实隶属于 Amazon Associates。

Amazon Associates 当时由 Collin Breir 负责。Collin 后来做了很多事情，还和别人合著了《Working Backwards》，这是一本好书，我们为这期和上一期 amazon.com 节目都参考了它。2002 年，Collin 可以算是 AWS 的第一任负责人。

Ben：对，而且当时 AWS 只是 Amazon Associates 的一部分。这个起源故事的范围很重要：AWS 的野心是让 Amazon Associates 的合作伙伴调用 amazon.com 的资产，获取图片和产品信息；当有人购买时，订单信息会回传，再分享一部分收入。这就是它在组织里诞生时的目标范围。

David：这些内容都是真的，第二个起源故事里没有神话或虚构。接下来我们会从第二种说法转到第三种。但我觉得第二种说法的重要之处是：它带来了 Web 2.0 和 API 的概念，这些想法开始在 Jeff Bezos 心里扎根，最后确实发展成 AWS，但当时还不是我们今天所说的那个 AWS。

Ben：这段故事里我们一次都没说‘云计算’或‘云’。我们说的是 Web Services。我觉得现在大家听 AWS 听得太多了，忘了它的名字其实有点名不副实。它还是叫 Amazon Web Services，但客户花大量的钱买 AWS，绝大多数情况下买的并不是 Web Services，也不是这些用来读取、发送信息的 RESTful API 接口。

David：顺便问一下，你知道 IT 基础设施里的‘云’这个词是怎么来的吗？

Ben：不知道。

David：这太酷了，起源于 General Magic。

Ben：真的吗？

David：真的，太疯狂了。General Magic 是 Apple 拆分出来的公司，比 iPhone 早 20 年就发明了 iPhone 的雏形。他们当时还想建立一种分布式、随时可访问的后端 IT 基础设施，为移动设备上的各种服务提供支持。那时互联网还几乎不存在，所以我觉得他们并没有把它当成互联网。他们把这种基础设施叫作云，让设备可以随时访问。

Ben：General Magic 在很多方面都是先驱，太不可思议了。

David：确实是先驱。好，我们回到 Amazon。它已经推出了 AWS，也开始谈 Web 2.0，诸如此类。这些都不错，但当时 Amazon 里没有人把主要精力放在这些事情上，他们忙着解决公司内部一大堆问题。

最大的问题或许是 amazon.com 的代码库。Shel Kaphan 在 1995 年设计了它，做出了很多很好的技术决策，我们在 amazon.com 那期节目里讲过。

他按照 1995 年网站的方式来设计系统：团队规模小、不必大规模运营，软件代码库采用单体架构。就像我们在节目开头讲的，当时这个价值数十亿美元的公司，整个 amazon.com 都运行在同一个单体代码库上。

Ben：我和早期 Amazon 工程师聊过。每年夏天，他们都会研究第四季度上市的新服务器，问哪一款性能最强、最值得买。他们就从 DEC 或别家公司买最贵、配置最高的服务器，然后尽量靠它们撑过圣诞季。

David：对。Amazon 每年节日前都会冻结代码。想想看，这和我们今天熟悉的科技公司完全不同。如今科技公司的运作方式，很大程度上都要感谢 AWS。

当时年底前必须冻结代码，因为你只要添加功能、模块或开发团队就可能出问题。Amazon 那时已经有 A9 搜索团队，Lab126 刚刚起步，还有许多团队、大量工程师和产品经理在开发新功能。每个团队都得访问网站的不同部分。只要给单体代码库加入一个新功能，整个系统就可能崩溃，所以只能冻结代码。

要记住，Amazon 那时正努力实现盈利和提高效率。公司几乎停摆了。《Working Backwards》里有不少内容写到，由于技术和基础设施复杂得像一团乱麻，在 Amazon 做出新东西、把它建起来变得越来越困难。

Ben：这里有两个问题。一个是增加复杂度就会让服务器崩溃。另一个是 Amazon 一直在做 Amazon 擅长的事：进入新业务和新类别，持续扩张。

之所以必须持续增长，是因为他们设计了一种现金流模式——上一期提过，用供应商的钱推动增长，再晚些时候才付款。简单说，他们把这笔浮存金投入了增长，所以公司必须继续扩张，因为账单迟早要到期。他们不断寻找新类别，发现到处都是竞争对手，只想尽快做大。

问题是，新增代码会让服务器不堪重负，因此无法推出新业务，也不能继续扩张，更不能增加客户，因为客户越多，流量越大，服务器就越容易崩溃。

David：我们举一个特别典型的例子：市场平台业务。Amazon 找到这个方向时，它彻底改变了公司。这是高利润收入，也是它和 eBay 竞争的方式。但为了实现这个业务，他们必须重构系统，让商品购买按钮能在网站上工作。想象一下，在单体代码库上做这种事有多难？

Ben：这会让实际软件开发速度变慢，发布变慢，创新也变慢。因为你会担心：‘刚才另一个团队往代码库里提交了什么？这意味着什么？我还能信任这个函数原来的接口约定吗，还是有人为了自己的需求，修改了一个与它紧密耦合的函数？’

用不了多久，代码里就会到处都是彼此依赖的假设。你想改点什么也会发现系统很脆弱。每次编辑代码之前，你都得先和一堆人谈，因为稍不留神就可能弄坏其他东西。

David：对，这不只是 Amazon 的问题，所有互联网公司都遇到过。最早达到这种规模的公司之一是当时的 Amazon；那之前没有互联网公司到过这个规模。公司一大，就会因为复杂性撞上一堵墙。

这成了一个大问题。Jeff 非常关注这件事。他当时新来的技术助理 Andy Jassy 也很关注。很多听众可能不知道这个职位，但熟悉 Amazon 或在那里工作过的人都知道 Jeff 身边的‘影子’职位有多传奇。

Ben：这个职位之前是 Microsoft 的做法。Bill Gates 的技术助理就是范本。

David：没错，技术助理。Jassy 成为 Jeff 的第一位‘影子’，是因为他有 Harvard MBA 学位，也负责过产品线。他曾为 Amazon 推出音乐业务，之后进入市场营销部门。后来 2000 到 2001 年互联网泡沫破裂，Amazon 整个市场部门都被裁了：‘我们不再做广告了，必须盈利。’

Jassy 原本也会被部门裁掉，但 Jeff 很喜欢他，说：‘我要留下 Andy，不让他被裁。我会给他找点事做。’Jeff 想起 Microsoft 的技术助理职位，就说：‘我们来试试这个办法，让他做我的影子。’这样就为他创造了这个角色。

Ben：在此之前，Andy 并没有技术背景。他后来成了技术助理，人很聪明，但最初是个负责推出品类的 MBA，帮公司探索音乐、电子产品等新类别。我记不清他具体负责推出哪一个，但应该是音乐业务。几年前他甚至考虑过进入体育行业。

David：没错，他想当体育解说员。

Ben：他是很有名的体育迷，地下室弄得像酒吧一样，差点就走上体育行业这条路。我们说的不是一位杰出工程师出任技术顾问，也不是技术巨匠，而是一个非常聪明、适应力强、善于沟通的人。

David：这本来只是为了把 Andy 留在公司、给他找份工作。但公司最大的技术问题，也成了 Jeff 和 Andy 最关注的事。这些线索在这里交汇，我想到这点真是惊叹不已。

如果技术基础设施几乎停摆、无法发布任何内容、公司内部沟通困难，你很自然会做什么？我想大多数公司当时都会想：‘我们得改善沟通。加强协调流程，让沟通更频繁、更紧密，团队之间配合更好。我们得建立更成熟的工程管理体系和流程，提升效率，解决复杂性问题。’

Ben：十几年前，Microsoft 遇到这个问题时发明了项目管理岗位。这个岗位主要有两项职责：世界上没有足够多既是十倍效率的开发者、又特别擅长沟通的全才，所以我们就为他们配备沟通协调人员。我们可以招聘智商极高的工程师，但他们通常不擅长沟通。

于是每位开发者配一位项目经理，或者每两到五名开发者配一位。这样就有人负责沟通，项目经理之间也可以协调两个团队的工作。之后双方一起写规格文档，工程师再写技术文档，然后就能开始执行了。项目经理持续沟通，确保大家理解一致。

David：我不太清楚这个历史，你以前就是做这个的人。

Ben：对，那就是我的工作。

David：Microsoft 的项目管理项目，注意是程序项目管理，不是产品管理，是现代硅谷产品经理岗位的起源吗？

Ben：它确实是程序管理的起源。Microsoft 把产品管理看作营销职能，归市场部门，更多负责上市和推广；Microsoft 的程序经理则属于工程组织，和工程师使用相同的薪酬及晋升级别。

David：哪天我们应该请人来聊一聊科技和硅谷里产品经理的发展史。

Ben：还得说清楚这里的 P 到底代表什么，因为不同公司里可能完全不一样。

David：没错。大多数公司，包括那些非常成功、聪明、杰出的公司和创始人，比如 Microsoft 和 Bill Gates，都会这么做。但 Jeff 和 Andy 并没有这样做。

Ben：要不我们减少沟通？

David：要不干脆不沟通？这时 Tim O'Reilly 提出的 Web 2.0 和 API 概念，对 Amazon 和整个互联网都产生了更深远的影响。Jeff 和 Andy 都接触到了 Web 2.0 和 API 的想法。Jeff 突然做了个大胆决定：我们应该在公司内部也使用 API。

如果我们把所有东西都变成‘强化接口’——这是 Amazon 的说法——也就是加固的 API 接口，就能彻底打破眼前的困局。我们要规定：不准互相沟通，所有内部交互都必须通过 API。任何其他团队都能访问所需接口，不必和你直接谈。

Ben：这很有道理。如果把公司看成由一群独立、灵活、富有创业精神的团队组成，或者更准确地说，是一群各自经营的小型创业公司，那就应该把他们当成独立公司。如果外部创业公司能在没有业务拓展人员牵线的情况下互相合作，通过 API 调用、数据交换和服务交付来开展业务，那么这也许是下一代公司的正确内部组织模式。

David：学术界当时已经开始探讨这个方向。我觉得 Amazon 是第一个在实践中采用这种模式的公司，后来称为面向服务的架构。传统软件是单体架构；面向服务的架构则是让每个小团队、每项功能都成为独立服务，与其他部分完全分开。

Ben：这里还得区分一下。一方面是文化层面的做法：减少梅特卡夫定律所描述的问题。每增加一个人，组织里需要沟通的潜在关系就按人数平方增长，团队越大，这个问题越严重。

你刚才说的就是这个文化层面的做法。面向服务的架构则是工程上的对应方案：每个功能都做成完全独立的应用，再通过组合共同构成用户看到的产品。

David：对，通过 API。这里还有一篇传奇文章，是互联网历史上最受欢迎的文章之一。

Ben：是 Steve Yegge 写的那篇吗？

David：对，就是 Steve Yegge 的吐槽。他当时已经转到 Google 工作，文章是在那之后发的。他之前在 Amazon 工作过，亲历了这个时期。感谢 Acquired Slack 社群的 Jeremy Diamond 提醒我们这件事。

Ben：最有意思的是，这篇文章怎么公开的。他当时在 Google，刚好公司发布 Google+。他本来想发到内部论坛，结果不小心公开到了 Google+。这件事马上就传开了，因为一个员工本来想发内部邮件，最后却泄露到网上——产品设计太差，连负责开发产品的人都分不清内部和公开发布的区别。这种故事太吸引人了。

David：这篇文章背后的故事和文章本身一样精彩，也特别能体现 Google 和 Amazon 文化的差异。文章一开始不断批评 Amazon 的文化。Amazon 不在乎这些，不过作者提到了强化接口和 Amazon 对此的看法，还提到 Rick Dalzell。

上一期我们可能没说过，Rick 在加入 Walmart 之前是陆军游骑兵。他会把每个开发者都折腾得够呛。他自己也像一道强化接口。文章说 Amazon 很糟、Bezos 很糟、他们很刻薄，诸如此类。

这些都只是铺垫，文章的重点是：Amazon 在很多事情上都做错了，Google 处处更强，但有一件事 Amazon 远胜 Google。

Ben：我记得这是 2010 年左右，可以作为时间参考。

David：对，2010 到 2011 年，差不多是 Google+ 发布时。Steve 写道，Jeff 和他的技术助理 Andy 曾经向全公司发了一份备忘录，发布了一项重大指令：‘第一，从现在开始，所有团队必须通过服务接口暴露自己的数据和功能。’

‘第二，团队之间必须通过这些接口沟通。’

‘第三，不允许使用其他进程间通信方式。不得直接链接，不得直接读取其他团队的数据存储，不得共享内存，也不得设置任何后门。唯一允许的通信方式，是通过网络调用服务接口。’

‘第四，使用什么技术都可以——HTTP、Cobra、PubSub 或自定义协议都行，Jeff Bezos 不在乎。’

‘第五，所有服务接口都必须从一开始就按照未来可对外开放的标准来设计。也就是说，每个团队都必须计划好并设计好接口，让外部开发者也能使用。没有例外。’

‘第六，不照做的人会被解雇。’

‘第七，谢谢，祝大家今天愉快。’作者又说，曾在 Amazon 工作的人都知道，Jeff 不会说‘谢谢，祝大家愉快’，因为他很刻薄。

Ben：当时这简直不可思议。我记得 2000 年代末写 Web 应用时，我用 PHP 和 MySQL 数据库。

如果有人告诉我：‘你不能直接查询自己公司的 MySQL 数据库，虽然你有权限，数据库也归公司所有。你必须调用另一个 API，由有权限的网络服务直接访问数据库。’我会想：‘开什么玩笑？我直接查数据库不是方便多了吗？’但答案就是：‘不照做就会被解雇。’

David：挺有意思的。我们一直在想，该怎样给不熟悉技术的听众讲这段故事，又不陷进太多技术细节。现在内容已经很技术了，但绕不开，因为它非常重要。

这件事的背景是：我们从面向服务的架构和 API 这些概念往外退一步，看看真正发生了什么。归根结底，重要的是顾客买到的啤酒是否更好。我们刚才聊的这些技术细节，对于企业真正重要的事情来说，都是技术细节。

企业真正关心的是客户体验、新功能、客户满意度、收入和利润。这些技术复杂性都在妨碍这些目标。Jeff 意识到：这些都不能让啤酒更好喝。那我们就把接口标准化，消除沟通依赖，把所有内部交互 API 化，这样每个人就能专注开发新功能，让 amazon.com 的啤酒更好喝。

Ben：没错。这里还有 Amazon 非常强调的文档文化。你知道，他们开会会先读六页纸和 PR/FAQ 文档，而不是看 PowerPoint。团队会从客户最终得到什么出发，反向推导产品需求。

API 是一种高度依赖文档的计算方式。你调用我的 API 时，可以传入什么、我会返回什么，都有严格记录。直接访问数据库则不同，你我可以聊几句，我可能告诉你：‘那个字段我们已经不再这样用，改成了另一个用途，记得注意一下。’

API 不会让你‘记得注意一下’。规则就是：调用这个接口，就会得到这个结果。它体现了一种严格、明确的信念：接口会怎样响应调用，必须清楚记录，而且文档必须始终与实际行为保持一致。

Ben：现在我们进入第三种起源说法。第一种是流传甚广的‘多余硬件’说法；第二种是 Tim O'Reilly 提出 Web 2.0 和 API 后，Amazon 开始开发 Amazon Associates API；第三种则是公司发展太慢，于是先让内部团队通过 API 沟通，以加快内部运作。

他们开始这么做后，在 Steve Yegge 把那篇吐槽发到网上之前，就发现有些东西也许应该对外开放。他们花了很长时间摸索出正确做法，发现这些工作并没有直接改善客户体验，也许外面其他公司也在经历同样的艰难，努力让基础设施持续正常运行。

David：还有一个规模虽小、但当时发展到那一步后不可避免的飞跃。到目前为止，第三种 AWS 起源说法讲的都是软件工程和 amazon.com 的代码库。

AWS 其实是把 IT 硬件基础设施抽象成服务，软件也是其中一部分。但 S3、EC2 的核心是 IT 基础设施。软件架构改变后，为什么会接着需要云 IT 基础设施？这是同一个问题，几乎必然会发生。

当你把软件架构从单体代码库改成面向服务的架构后，IT 部门也没法再像以前那样统一规划：什么时候发布功能、什么时候冻结代码、需要多少容量，全部都能集中预测。现在有很多分布式团队，彼此不沟通，IT 部门再也无法统一规划。

Amazon 意识到，他们要对 IT 做和软件工程相同的事：把它变成一个可以通过 API 访问的算力资源池，而不是‘我给你一台服务器，你就只能用这一台’。

Ben：你说的是内部使用。如果所有团队都通过 API 互相调用，那当负载突然大幅增加、而没人事先通知你的时候，你也得有办法动态增加硬件来承接流量。

David：很聪明的一点就是：那我们把 IT 也做成 API。我们可以通过 API 向 IT 部门请求算力资源，他们那里有一个资源池。

Ben：但做起来远比说起来难。

David：没错。

Ben：对，好像 IT 只要变成 API 就行了。

David：不，这项工作在 Amazon 的 IT 部门里持续了好几年。Bezos 不是发一封 Steve Yegge 描述的邮件，第二天一切就完成了。

Ben：好，那你的意思是，Bezos 对这个想法很兴奋，Jassy 开始和他一起推动。他们把你前面提到的那个小小的初始想法扩展开来：内部 API 应该设计成未来也可以让外部用户调用。但你还没讲清楚，商业化产品是怎么出现的？提供给第三方客户的究竟是什么？

David：时间来到 2003 年年中。这是 Amazon 内部持续了 18 个月的一项重大变革。Jassy 一直作为 Jeff 的技术助理参与其中。Jeff 对他说：‘Andy，你该回公司去承担新的领导工作了。你不用再当我的助理了，得去领导 Amazon 里的一个团队。’

这有点像 Jeff 当年在 D.E. Shaw 和 David Shaw 共事的情景。两人一起想：‘Andy，你接下来要做什么新项目？你要在 Amazon 里领导哪一块？’我想 Andy 当时应该很庆幸自己没有离开 Amazon。

他们想到了一个机会：把正在开发的、基于 API 的 IT 基础设施提供给第三方。传说中，Andy 写了一份六页纸的备忘录。

Ben：这是 Amazon 的官方说法。你可以在 Amazon.com 的相关材料里读到。

David：没错，官方文件也记载了。Amazon 的决策靠书面叙述和六页纸文档推进。Jassy 写了六页纸，还得调整页边距，才能把所有内容塞进去。

连财务预测都写不下，所以文档里完全没有财务预测。后来他在 S 团队和董事会的会议上，现场用白板画出财务情况，提出把 Amazon Web Services 重新推出，定位为云 IT 基础设施服务的宏大愿景。

他在文档里提出，要招聘 57 名员工推进这项计划。Jassy 说自己走进会议时非常紧张，因为这是他职业生涯中的重要时刻，竟然要一次申请 57 个人。没人会一次要 57 个员工，这需要很大勇气。他冒了很大风险。Jeff 喜欢这个提议，董事会喜欢，S 团队也喜欢，最终批准了。

我觉得大部分确实发生过，或者至少大致是这么回事。之前负责 AWS 的 Collin Brier 和 Andy 互换了位置：Andy 接手 AWS，Collin 成为 Jeff 的下一任影子助理。

Ben：哦，我之前不知道。Andy 一接手就马上开始推动 Amazon Associates API 上的图片发布服务，也就是当时还很初期的 AWS？

David：这部分可能确实发生了，也可能只是 Amazon 企业史里比较笼统的叙述。总之，他们的交接很顺利。Collin 后来成为 Jeff 的影子助理，Amazon 收购 IMDb 后，他又负责 IMDb。之后他离开 Amazon，和负责 Prime Video 的 Bill Carr 合作，一起写了《Working Backwards》。

Ben：我以前不知道。这太聪明了。他们还成立了一家咨询公司，基于《Working Backwards》帮助其他公司落实 Amazon 文化，真是绝妙。

回到 Andy。他得到批准，可以招聘 57 人。他招来了 Adam Selipsky。Adam 后来离开 AWS，成为 Tableau CEO，现在又回到 AWS 担任 CEO。

Ben：为了准备节目，我把每一届 re:Invent 主旨演讲都看了一遍，那可真是看了很多 IT 大会的演讲。最近一届的主讲人是 Adam Selipsky。连续 10 到 11 年都是 Jassy 在台上，突然换了个人，感觉有点奇怪，特别是我一口气连着看了那么多场，突然就不是 Andy Jassy 了。现在接手的是 Adam。

David：你知道最早加入 AWS 的一批外部招聘人员里，还有谁吗？

Ben：不知道。

David：Jeff Lawson。

Ben：不会吧，Twilio 的 CEO？

David：对。

Ben：哇。

David：Twilio 后来从 AWS 脱胎而出，这很合理。

Ben：当然。

David：我觉得这段历史大体属实。Andy 写了那份文档，接手了 AWS，并把它从一种完全不同的业务发展成今天的样子。但我觉得故事还不止这些。

Ben：这是个很方便的故事。但有点奇怪的是，提出这个想法的人当时并没有亲自处理基础设施问题。

David：Andy 在 2013 年上过 Harvard i-Lab 的 YouTube 访谈，讲 AWS 的起源。主题好像是企业内部创业，我觉得这是史上最难听的词之一。

Andy 在访谈里说，在构想文档和相关讨论中，他们必须决定如何发布服务。是先推出一个 IT 基础组件，还是一次性推出一整套服务？最后他们成立了一个‘突击团队’，成员是公司内部最优秀的十位技术专家。

他们拆解了当时主要的网络服务和 Web 应用，包括 amazon.com、Google、eBay 等。虽然没有点名，但我猜还研究了当时其他大型网络服务和应用。他们分析，如果要用这种新的云 IT 基础设施重新架构这些服务，需要哪些组件。最后得出结论：需要存储、计算、数据库和内容分发网络，也就是 Akamai 所提供的服务，才能重建任何大规模互联网服务。

Ben：我喜欢你说‘曾经像 Akamai 那样’，用过去时。

David：这又是另一个故事。他们当时决定：如果要兑现承诺，让开发者能在我们的基础设施上构建大规模 Web 应用，就得同时推出所有这些服务。于是他们决定全都做，这就是需要 57 名员工的原因。

Andy 后来有句名言，我觉得完全正确。他说：‘如果你相信开发者会把 Web 服务当作基本构件，从头搭建应用，那么互联网就成了操作系统。’这确实是真的，也就是 AWS 今天的样子。他们会推出构建整套操作系统所需的所有工具。但官方故事从这里开始就完全对不上了，因为事情根本不是这样发生的。

Ben：没错。我记得自己做项目时用过 Amazon S3，但当时还没有 EC2。

David：对。和第一种起源神话不一样，Amazon 不能把多余的 amazon.com IT 容量直接对外开放。所有这些东西都得重新开发成外部服务，需要几年时间。替官方版本辩护的话，也许他们确实同时启动了整套服务，只是需要时间才能全部建好。但最终 S3 是第一个单独上线的服务，在 2006 年 3 月推出。

Ben：我们来讲讲它。S3 是一项单独就有用的服务。Simple Storage Service 是一个可以通过互联网访问的存储空间。你不用操心它放在哪里，反正就在云端。你可以把图片存进去，再由自己的应用、其他应用来访问。或者不经过应用，直接用 URL 访问图片。

存进去的不只是图片，而是任何东西。这是一件奇妙得不可思议的事：我不用买服务器、配置服务器、把服务器装进机柜，也不用维护服务器，而且只按实际使用量付费。价格低得惊人。

David：对。S3 在 2006 年 3 月上线。几个月后，EC2 也在 2006 年 8 月左右以测试版推出。

Ben：EC2 是什么？

David：EC2 是 Elastic Compute Cloud，也就是弹性计算云，是 AWS 中和存储对应的计算服务。

Ben：可以这样理解 EC2：当时如果你是 Web 应用开发者，像我一样在电脑本地写代码，然后把它部署到数据中心的一台服务器上，可以通过 Telnet、ping 和 IP 地址访问。EC2 让你可以启动一个实例，把它当作那种服务器用，只是它没有持久存储。你可以把它想成一台没有硬盘、位于云端、只要不停止使用就归你使用的电脑。

David：它就是云端的处理器。CloudFront 是内容分发网络，也就是拼图里的 Akamai 部分，于 2008 年推出。第一个主要数据库服务 RDS（关系数据库服务）直到 2009 年才推出。

Ben：重要的是，RDS 不是说你用了它，就不用以前的数据库了。它运行的还是你本来就在用的数据库。我记不清最初是不是支持 Postgres。假设你以前在服务器上自行托管 Postgres，或者有一台专用数据库服务器运行 Postgres。现在你用 RDS，它继续运行 Postgres，所有查询都能照常工作，你可以把它当作自己的数据库服务器。

David：这是官方 AWS 起源故事里最明显的漏洞。接下来就是第四种说法，也就是不同意见版本。

Ben：第一种说法方向偏了 180 度，第二种偏了 90 度。我们现在逐渐修正方向。第三种大体正确，但可能没有提到所有应该写进故事里的人。

David：我觉得第四种说法也基本正确，但第三和第四种其实是同一回事。

Ben：成功背后，往往有很多人。

David：没错。与此同时，除了刚才的第三种起源故事，Andy Jassy 还在担任 Jeff 的技术助理，处理这个大问题、撰写愿景文档和商业计划、招聘 57 名员工。2003 年，Amazon 网络工程师 Benjamin Black 也在处理 IT 架构转型，他的上司 Chris Pinkham 负责 Amazon 的网络工程部门，而 Chris 向 Amazon CIO Rick Dalzell 汇报。

Benjamin 和 Chris 写了六页纸，说明如何按照公司要采用的新模式，重新设计网络工程架构。他们据说在文档末尾提到：按照这套架构，Amazon 也许可以把虚拟计算服务器当作服务提供给第三方开发者。Amazon 确实有能力做到这一点。

Ben：这里开始变得模糊，因为那份文档确实存在。大部分内容是在说如何落实整体计划，同时也提到可以把基础设施作为服务卖出去。Ben Black 在博客文章以及后来接受 Network World 等媒体采访时，坚持说他们把方案交给了 Jeff Bezos，最后确实递到了他面前。

David：对，我想先交给 Rick，再交给 Jeff。

Ben：他批准了这个项目。

David：是的，不过那和 AWS 的其他工作是分开的。

Ben：我搞不清楚，这个提案在交给 Jeff 之前，是不是已经并入了 Andy 的提案，后来作为一个整体被批准？还是说这其实是两项并行的不同工作？

David：我们继续讲故事，之后我再分享自己的看法。Chris 来自南非。差不多同一时间，他和家人想搬回南非，离开西雅图，回开普敦生活。

他去找上司 Rick，说：‘我准备离职，搬回南非。’Rick 回答：‘不行，我们现在正处于公司规模巨大的架构转型期。这是关键时刻。你是公司非常重要的人。’

‘我们能不能像在 Palo Alto 建立 A9 和 Lab126 那样，在南非开普敦设一家 Amazon 子公司，由你来领导？这样可以留住你的才能，之后再决定新子公司做什么。’Chris 说：‘好，听起来不错。’

Chris 和 Rick 开始讨论，想起刚才他和 Benjamin 写的关于向第三方销售虚拟服务器的提案。他们想：‘新子公司要不要负责做这件事？’于是就这么办了。Benjamin 没有一起搬过去，但 Chris 和一位非常优秀的工程师 Chris Brown 去了。

Ben：据我了解，Ben Black 的参与到这里就结束了。他参与提出想法，但没有参与在南非建造后来的产品。

David：对。Chris 和 Chris 去了南非，独立开发这个计算服务器项目。后来 EC2 就是这个团队做出来的。

Brad Stone 在《一网打尽》里写道：‘EC2 是在隔离状态下诞生的。至少第一年，Pinkham 和西雅图的同事几乎没有多少往来。Pinkham 后来表示，这种独处状态有好处，因为它让自己与那位干预过多的 CEO 保持了距离。’Pinkham 还说：‘我大部分时间都在躲 Bezos。他人很好，聊天很有趣，但你不想成为他的重点项目。他会喜欢你喜欢到让你无法专心。’太好笑了。

Ben：从这些公开且措辞相当温和的引述里，也能看出 Chris Pinkham 和 Bezos、Jassy 领导层之间有些紧张。甚至在 Amazon 官方发布的南非开发历史文章里，Pinkham 的名字都完全没有出现。领导层显然和 Chris 有摩擦。

David：没错。Jassy 还在 Amazon 上给《一网打尽》打过一星，书里有好几处都在批评 Brad 写错了。Andy 说：‘AWS 业务及其初始服务的愿景提案，包括计算服务 EC2，是我在 2003 年 9 月完成并提交给执行团队的。我写了这份文档，也很幸运有几个人帮我一起完成。’这比 Chris Pinkham 搬去南非、开始开发 EC2 早了一年左右。

Chris 虽然在 EC2 正式发布前就离开了，但他对 EC2 的定义、团队组建和产品开发都起了关键作用。显然双方之间有些旧怨，不过我觉得这整件事挺荒唐的，因为最后其实不重要。

更荒唐的是，我觉得实际情况是：公司里有多个团队同时在做相关项目。Amazon 一向以这种分散式创新而自豪。这正是整个练习的目的：分散权力，让团队创新。Jeff 和公司的口号是什么来着？‘发明、探索’。

我觉得实际就是这样。但现在 Amazon 的官方 AWS 历史却说，一切都是中央统一规划，都写在 2003 年那份文档里。这看起来很荒唐，也适得其反。

Ben：同意。还有一点越来越清楚：关键并不在想法本身，而在执行。这话有点老生常谈。说得具体一些，所谓想法其实可以拆成数百个小想法，构成最初的主意。但如果你说的只是用一句话表达出的想法，那几乎毫无价值。

愿景文档也一样。真正重要的是执行时作出的数千个微小决定，以及落实过程中的实际工作。历史往往由胜利者书写，这里也有这种情况。另一个很清楚的事实是，Andy Jassy 是一位非常出色的战略家和领导者。

公司里像他这样的人最终会领导 AWS，这并不奇怪。我不明白为什么大家要争论‘这个想法是谁的’。真正重要的问题是：最后是谁把它变成了改变世界的业务？

David：你在 amazon.com 那期节目里总结过一个很棒的经验，我记得你还把片段发到了 Twitter 和 LinkedIn 上，引起了很多关注。Amazon 就像一个寻路算法。

Ben：对，它会用蛮力在迷宫里不断尝试，收集数据，最后找到正确路径。推出产品、收集数据、砍掉，再重新开始。

David：没错。走进迷宫，遇到死路就后退几步，再走另一条路。我觉得 AWS 起步时也是这样。

Ben：早期确实如此。不过我想在后面的投资手册部分再讲，因为 AWS 有些方面恰恰和这个模式相反。

David：好，挺有意思。

Ben：好。最后还想强调基础构件的重要性。不知道他们当时是不是有意这样设计，但后来变成了特别重要的策略：他们真的没有对平台作太多预设。

他们说：‘我们会推出最基础的构件：最基本的计算服务、最简单的数据库托管方式、最基础的 CDN。我们迫不及待想看看开发者能用这些最简单的架构，创造出什么新东西。’这后来成了所谓‘基础设施即服务’这一类别。

我不知道他们最初推出时是不是有意这样做，但他们没有说：‘我们要造一个新操作系统，建立新的编程范式。’他们只是提供最基础的积木，让开发者自己发挥。

David：我们之前花了很多时间谈技术层面。现在来说说它在商业和市场层面是多么激进的创新。我这里有段很棒的话。‘S3 刚上线时’，可能就是你尝试使用它的那段时间，‘Microsoft 有一位非常优秀的一线工程师 James Hamilton，后来他加入了 AWS 执行团队，现在是 Amazon 高级杰出工程师。他看到 AWS 后，在个人博客上写下自己第一次用 S3 做个人项目的经历。’

他写道：‘最具颠覆性的是，只要一张信用卡就能开通存储空间。不需要提交采购审批，不需要招标，不需要供应商筛选，也不用和供应商谈判，更不用寻找数据中心机房。我只需注册就能开始工作。从决定编写应用，到应用在互联网上运行，只花了几天。’

‘在充分调试和测试之后，月底到了，我收到了 Visa 账单。我当然知道 S3 的定价有颠覆性，但看到整个应用开发和测试期间的账单只有 3.08 美元，我还是觉得不太真实。开发完成后，我继续把所有测试数据存放在 S3。下个月账单是 0.07 美元。’

Ben：David，真的。我每个月都会收到 AWS 71 美分的账单，却完全想不起这是哪个旧项目。它的定价太灵活了。如果这是个成功的大项目、存了很多数据，费用自然会很高。

不过 S3、带宽以及类似服务的毛利其实不错。只是我那个早已放弃的项目，我连该用哪个邮箱登录 AWS 都不记得了，也就不在乎那点费用。

David：想象一下，当年 2006 年的 Oracle、Microsoft、IBM、HP，或者其他厂商，能不能这么做？

Ben：他们的合同金额都是六位数、七位数、八位数。根本不可能有人投资一种信用卡付费的服务，来满足一个很小的市场。

David：然后只收你 3.08 美元。这是真正改变世界的创新。Dropbox、Instagram、Airbnb、Uber、Zynga 等公司都是这样起步的。

Ben：我记得参加各种 Startup Weekend 和黑客松时，观众、带家人来的亲友，还有来当评委的风投人，都被开发速度震惊了：48 小时就能做出一个能运行的东西。以前你得花三个月、500 万美元，研究要把东西放在哪个数据中心；现在你只要有个想法，两天就能上线。这个运动就是这么开始的。

David：我们都经历过。Rover.com 的创办过程中，有我们的好朋友兼导师 Greg Gottesman 参与。他是风投人，不懂技术，但公司是在一个周末里做出来的。

Ben：对，是 Phil Kimmey 做的。

David：我们的朋友 Phil 做出来的。Amazon 很欢迎这种模式。2007 年秋季，他们开始办 AWS 创业挑战赛，首届在 2007 年 9 月举行。他们没赢，但你知道第一届 AWS 创业挑战赛的参赛公司里有谁吗？

Ben：是 TeachStreet 吗？会不会是 Amazon 内部的熟人？

David：更棒，是 Justin.tv。

Ben：不会吧。

David：后来它转型成 Twitch。

Ben：然后 Amazon 又收购了它。

David：没错，Amazon 后来把它买下来了。

Ben：成交价接近 10 亿美元吧？

David：对。我不太清楚 Twitch 现在的经营状况，但无论如何，Amazon 当时都算捡到便宜了。我们得找合适时机再讲这段历史。

Ben：当然，这是很好的应用案例。Justin.tv 早期需要大量带宽来直播视频，也用 S3 存储数据，非常合适。Amazon 对这类创业公司特别欢迎。我觉得 AWS 成功的关键之一或投资手册之一，就是他们意识到这对创业公司非常合适。

他们也知道大型企业不可能一下子整体迁移过来，不会是第一批切入市场的客户。但对从零开始、未来有可能成为 500 亿美元以上公司的创业者来说，Amazon 想：‘一定要让他们使用 AWS。’

他们的推广行动非常出色。我记得第一次见到 Dave Chappelle，他当时在 AWS 做开发者推广，Jeff Barr 和许多人也在这个团队。那感觉像一股清新空气：每次参加创业者酒会，都会遇到 AWS 的人，他们送你大量免费额度，还会帮你认识其他创业者。

AWS 团队把自己看作创业社区的积极参与者。AWS 很快就成了显而易见的默认选择，因为它融入了创办公司的整个过程。你准备做点什么，就先开一个 AWS 账号。

Andy Jassy 在几乎每届 re:Invent 上都会讲这个著名的故事：一开始，大型企业都怀疑云服务，说它也许适合创业公司，但不适合业务应用，也不适合关键任务。也有人说：‘测试和开发环境可以放云上，但企业级应用不能放云上。’

David：我记得他说，一开始人们觉得你不能在云上运行真正的应用，只能跑 James 这种个人测试项目。后来大家说创业公司可以用 AWS，但真正的企业不会用。再后来，企业说可以把不重要、非关键的系统放 AWS，核心系统还是得放在本地。最后大家都变成：‘天哪，拿走我的钱吧。’

Ben：对。最初的切入市场显然是创业公司。但后来企业采用 AWS，如今连银行的应用都运行在 AWS 上，万物都在迁往云端。至少 Amazon、Microsoft 和 Google 三家就有 1,200 亿美元年收入来自云业务。云服务主要就是这三大供应商。

有些人把本地基础设施迁到云上，我把这叫作‘直接迁移’。云计算行业常用这个说法：你本来在本地运行数据库、存储，也有自己的数据中心，现在把这些东西搬到 Amazon 的数据中心。你没有利用任何新的技术，只是把原有系统放在 Amazon 上运行。

这样做的好处是按使用量付费，不需要提前投入巨额资本，也不用自己维护基础设施。除此之外，运行的还是同样的系统。

David：Jassy 在 2012 年第一届 re:Invent 的演讲里有一页很好的幻灯片，解释 AWS 相比传统企业基础设施有六个优势。他说的正是这些：第一，从资本支出转向运营支出，费用可以逐年计入损益表，不必资本化。第二，AWS 的规模经济让运营成本比你自己搭建要低。

Ben：他们买服务器的价格更低，也把优惠转给了客户。

David：没错。第三，不必提前猜测需要多少基础设施容量。AWS 有弹性，需要更多就扩容，需要更少就缩容。

第四，系统也可以缩小。项目失败后，你不会被一堆遗留基础设施困住。

第五，工程师能专心写代码，不必安装和维护基础设施，把精力放在让啤酒更好喝上。

第六，你用 AWS 就能立即服务全球用户；自己运营本地数据中心的话，只能在那些数据中心所在的地方提供服务。

Ben：听起来很不错，但不完全准确。云不是只有一个全球可用区。有意思的是，这正是 AWS 最初设想的方式：你可以把它想成一个全球 S3 数据中心。

后来他们发现，如果每个请求都默认复制到所有数据中心，会产生大量用户流量，消耗互联网带宽，造成不必要的数据复制。AWS 不能默认把每项服务都部署到全球所有地区。总之，大致就是这样。

第二阶段是在云上构建，这就开始利用关系数据库服务 RDS 等云服务。它不再只是把原有代码和基础设施搬到 Amazon 数据中心，而是使用原生云服务。接着是为云构建，那才是未来，比如 Lambda 和 DynamoDB。

以 Lambda 为例。没用过无服务器架构的人可以这么理解：你甚至不需要预留 EC2 实例，也不用把代码部署到服务器。你只要写好代码，需要调用时，系统就启动一个实例，运行几毫秒，再自动关闭。你从来不需要知道它的 IP 地址，也不需要知道它位于世界哪个地方，只要知道你的代码已经运行。

这就是为云构建：你要重新设计整个应用架构，以利用云提供的全新计算方式。

David：回到第二和第三种起源说法：Amazon 的单体软件问题、所有工程师和产品团队的问题，以及其他互联网公司的共同难题。大家都把时间花在不能让产品更好的基础设施工作上。那时工程团队可能有 70% 的时间用于基础设施和环境搭建，只有 30% 的时间写软件。

AWS 把它调了过来：工程师可以把 70% 的时间花在软件开发上，只用 30% 的时间操心 API 和基础设施。到了云原生、Lambda 这些阶段，这个目标是把基础设施工作降到零。

Ben：至少这是目标。我觉得这些设想在理论上听起来比实际容易得多，不过理念确实如此。

AWS 最初几年主要面向创业公司，让它们从头开始使用基础设施即服务提供的基础组件。

他们很快发现，这类基础设施也适合直接迁移。只要他们努力满足企业的合规、可用性、正常运行时间和数据复制要求……

David：还有 Vanta 提供的 SOC 2 审计。

David：没错。很快 AWS 就同时服务两种市场：创业公司和直接迁移上云的企业。另一种做法是直接跳到最远的未来：现在的 Lambda 这种服务。假设我们回到 2006 年，要不要从一开始就开发那套东西，彻底改变开发范式，直接搭建未来的平台，让它运行在云端？那个平台既不是过去的 Windows，也不是刚刚出现的 App Store。为什么不从今天开始构建云平台的新范式？

有几家大型科技公司最初走了这种路线，结果完全失败了。Microsoft 和 Google 的问题在于，它们从平台即服务开始，既没吸引到创业公司——因为平台还不成熟，没人知道怎么在上面开发；也没吸引到企业——因为不支持直接迁移。二十世纪零年代末就做平台即服务，至少早了十年，面向的是尚不存在的市场。

David：好，我们来讲后续。Amazon 可能赢下了历史上最重要的市场。

Ben：在最初五年里，几乎没有竞争对手。

David：太不可思议了。第一批服务在 2006 年上线。2007 到 2008 年，Airbnb、Uber、Instagram 等创业公司开始成立，但当时都还没发展到今天的规模。2009 年，Netflix 成为客户。

Ben：这多么夸张？Netflix 在那之前三年里，已经自己搭建了一整套内部云服务来串流视频。最初他们好像用 Microsoft 的 Silverlight 来播放，还和 Microsoft 建立了重要合作。

David：没错，天哪，那东西太糟了。

Ben：对，我记得必须用 Internet Explorer 才能播放，体验很差。他们刚投了很多钱，后来突然转向，说：‘我们之前错了，改用 AWS。’

David：他们把所有系统都迁到了 AWS。我想 Netflix 至今仍有 100% 的业务运行在 AWS 上。

Ben：我不确定是不是 100%，但他们依然是 AWS 的大客户。2012 年第一届 re:Invent 的开场访谈嘉宾就是 Reed Hastings。

David：我记得 Reed 在那次访谈或同时期的另一场访谈里说：‘大家问我，Reed，你和 amazon.com 竞争，难道不担心把业务放在 AWS 上吗？’他说：‘一点也不担心。用 AWS 确实是我们最明智的基础设施决策。’

Ben：这给 Amazon 增添了很大的光彩。还有另一个重要背书，就是 CIA 使用了 AWS。既然 CIA 都觉得安全，你也应该放心。这是几年后的事。

Netflix 的案例很重要。早期很多公司不愿用 AWS，担心自己是零售商就不该和 Amazon 做生意，或者自己做视频等业务，会和 Amazon 竞争。Reed 在台上以如此直接、坚定的方式表态，就是在说：你可以相信 AWS 和 Amazon 零售业务是分开的。

David：好，Reed 和 Netflix 为什么要这么做？为什么其他客户也跟进？先不谈 Google，Microsoft、IBM、Oracle 等老牌科技公司为什么没有抓住这个机会？因为它们的定价模式太具颠覆性。

Ben：别把它们混为一谈。每家公司错失机会的原因都值得单独分析。

先说老牌服务器公司。IBM 和数据库领域的 Oracle，毛利高得离谱，还向客户销售完整的专有解决方案。

David：对，毛利率达到 80%。

Ben：没错。他们会把系统卖给你，在你的数据中心部署，之后把某些服务包装成‘云’。

David：比如私有云。

Ben：他们可能把服务放在自己的数据中心，也可能放在你的数据中心，本质上差不多。软件通过许可证出售，还会接受审计。Amazon 则能精确计量你的用量，然后按实际用量收费。过去的模式是你买一批 Oracle 许可证，在自己的服务器上部署，之后 Oracle 偶尔会派人来检查你有没有超出许可证范围。

好，许可证卖给你了，你买了这么多份，他们就上门确认你没有违规使用。他们不会主动改变这种商业模式，因为许可证几乎就是印钞机。

David：AWS 的目标毛利率和营业利润率大概是 20% 到 40%。

Ben：对 Amazon 来说，这相当于利润率提升十到二十倍，但对于传统厂商来说，吸引力就不大了。

David：没错，关键是，amazon.com 零售业务的营业利润率只有 2%。Amazon 会觉得：‘这项新业务的利润率比我们高十到二十倍，太好了。’但它仍不到老牌厂商利润率的一半。

Ben：老牌厂商经营得很舒服。Amazon 则擅长把业务运营得精简到极致，因为他们对所有商品的销售成本都特别敏感。

David：还有一点。Oracle 或 IBM 会把软件装到你的电脑或他们自己的数据中心里，称之为私有云之类的。假设他们给你装的是 Oracle Database 19，两年后你付维护费，再花升级费用换到 Oracle Database 20；几年后升级到 21 时，还要再花一大笔钱迁移系统。

Ben：对，为什么要放弃这份持续收入呢？

David：云基础设施始终是最新的，没有所谓的版本。你用的永远是最新版本。Amazon 还可以持续迭代，而不是像 Windows XP 那样每隔四年发布一次大更新。云服务会不断改变。

Ben：没错。这就是 IBM、Oracle 这类传统厂商的情况，很有意思。我好奇，有没有人像我这样把所有 AWS 大会的主旨演讲连着看完？因为我可以近距离比较不同年份的变化。

早些年，他们会在台上用开玩笑的方式提 IBM 和 Oracle，比如说一家纽约公司，屏幕上显示 IBM 标志；又或者说一家旧金山公司，然后讲超级游艇、扬帆出海之类的故事，暗指 Oracle。

大概在 2016 或 2017 年，他们的态度发生了巨大变化，开始直接批评它们，也开始直接批评 Microsoft。早期 Amazon 更把 Microsoft 当成合作伙伴，比如很乐意让客户在 AWS 实例上运行 Microsoft 软件。后来 Azure 成了非常有力的竞争者，也卷土重来……

David：它毫无疑问是 AWS 最强的竞争对手。

Ben：现在 Amazon 会直接批评 SQL Server 许可证之类的产品。Microsoft 也会像传统厂商一样审计客户。我们先说 Microsoft。回到二十世纪零年代中期，其实这本来应该是他们的业务，他们理应最先想到。

Microsoft 当时主要有两个问题。首先 Windows 部门权力太大了。Windows Server 和 SQL Server 团队想让客户继续购买更多产品。那时候大家相信，PC 会逐渐接管数据中心，PC 操作系统会成为数据中心的操作系统。

公司目标就是卖更多 Windows Server 许可证。那是一门好生意。Microsoft 内部任何看起来会蚕食这门生意的新项目，都会在内部权力斗争中被吞掉。

David：这应该是你在 Microsoft 工作时遇到的情况，对吧？

Ben：对。我 2012 年加入时，这场争论基本已经结束了。后来他们确实意识到必须押注 Azure，还得让它和 Windows Server 完全分开。我们也该肯定 Ballmer，他确实看到了这一点。

他们把当时 Windows Server 和工具业务的负责人换成了 Satya，也就是后来成为 Microsoft CEO 的 Satya Nadella，然后全力投入云战略。他们意识到，Azure 必须保持独立、获得 CEO 的支持，才能摆脱 Windows Server 部门的影响。

第二个问题正如我们之前说过的。他们推出过 Azure Cloud Services，现在基本已经停止。那是平台即服务（PaaS）模式。Microsoft 手里本来有巨大的优势：与企业 IT 部门的关系。

他们本该对每个使用 Windows Server 的客户说：‘好消息，我们有一套数据中心基础组件，你可以像现在 Azure 那样把现有系统迁过来。你已经在用 Microsoft，也信任我们，这可以纳入你的企业协议。’但 Microsoft 自作聪明，觉得自己有 Win32 运行时和 .NET 平台，是家优秀的平台公司。

他们认为开发者想为 Microsoft 的产品开发，所以应该推出下一代 API 和平台，让开发者构建优秀的云应用。但他们没看到眼前已有的巨大优势：客户和分发渠道。在接下来的五年里，这些客户会慢慢把新项目放到 AWS 上，而 Microsoft 还在摸索战略。

Microsoft 陷入两难：想开发全新应用的人不知道怎么为他们的平台开发，也不想被平台锁定。云计算行业至今仍有这个顾虑：不想被锁定，希望能同时使用多个云平台。但 Microsoft 也没有让现有客户轻松地把业务迁移上云。

Microsoft 现在处境很好，也找到了有意思的战略——我们后面可以再聊——但他们白白错过了五年机会。

David：确实是严重失误。好，Oracle 之后再说，先聊 Microsoft。那 Google 呢？

Ben：Google 排第三。Amazon 可能占 35% 到 40%，Microsoft 占 20% 到 22%，Google 大约占 10%。

David：Microsoft 能拿到 22%，已经是巨大胜利了。

Ben：没错。我对 Google 的看法是，它们意外地变成了一家商业公司。最初只是个项目，之后才发现搜索能带来巨额现金流，而且来得特别快。

搜索业务要把所有数据直接用于改善结果，因此 Google 立刻成为一家受消费者欢迎的垄断公司。法律允许竞争，也只要点一下就能用其他搜索引擎，但 Google 的体验最好。它拥有非常强的自我强化效应，逐渐成为垄断者。

它在全球最大的市场里占据高毛利垄断地位。人们想用互联网，而 Google 是互联网的入口。它的发展并非毫不费力，但一直是个计算机科学问题。

David：而且非常学术。

Ben：他们从来不用进入困难的实体业务。我不知道 Google 广告业务的具体利润率，得看销售成本算在营业费用里还是销售成本里，但它的毛利大概有 80%。毛利率只有 30% 的业务对他们没什么吸引力，他们也不擅长销售，不过我知道他们现在做得越来越好了。

当时的说法是，他们推出了叫 Google Apps 的 G Suite，但根本卖不出去。最后几乎全都免费给消费者用了，包括 Google Docs、Gmail 等。这些服务非常好用，但他们想不出怎么卖给企业。

他们没有 Microsoft 那样的企业销售能力，也没有 Amazon 那种经营困难业务、榨出每一美元利润的本领。对他们来说，做这门生意看起来不划算。可是，他们的技术确实是最好的。

他们运营着大型数据中心，还发明了非常新颖的计算机网络方式，把大量机器连接起来，支撑搜索业务。他们早在机器学习成为热门词汇之前就已经在做相关技术。如今云计算的重要价值之一，就是所有数据都存放在云端。

这样你就能使用 Google 发明的 TensorFlow、Kubernetes 等工具，在云上运行自己的业务。这本来也是 Google 可以赢下的市场，但他们缺乏销售和市场推广能力，也不像 Amazon 那样有铁一般的意志，把艰苦的生意一点一点做出来。

David：我觉得他们也犯了你刚才说的那类错误。我一开始还以为你说的是 Google，后来你才说是 Microsoft。Google 也犯了同样的问题：把产品建得太超前。

Ben：对，确实如此。Google 最初尝试的是 Google App Engine，它完全不是基础设施即服务，也不是一套基础组件。你只能用 Python 或 Java，为 GAE 的特定 API 开发 App Engine 应用，所有底层都被抽象掉了。

这和 Microsoft 的做法类似：我们要足够聪明，直接构建未来的平台。但正如 Steve Yegge 那篇吐槽所说，Google 并不是一家平台公司，他们不知道怎么构建平台、不知道怎么销售，也不知道如何识别目标市场，更不知道如何支持开发者，所以这个项目失败了。现在 Google Cloud Platform 已经是很有竞争力的服务商，但他们起步时不是这样。

David：对。我们回过头聊聊 Oracle。做研究、和 Amazon 及 AWS 的朋友交谈时，有一点特别明显：大家低估了 Amazon 克服 Google 遇到的那个障碍的能力，那就是 Google 不知道如何做销售。Amazon 当时其实也不擅长企业销售。

Ben：这点说得好。

David：AWS 刚起步时，最明显的产品与市场契合点以及第一批客户都是创业公司。他们不需要企业销售，只想在线刷信用卡。Amazon 不必一开始就解决企业销售问题。但后来他们确实学会了如何服务企业、政府、政府部门和大型机构，也提供了直接迁移服务，把这些大型组织带到了云上。

Ben：我觉得最早是学术界。他们第一批大型合同来自大学，让研究团队使用 AWS 运行类似超级计算机的工作负载。

David：NASA 从 2009 年起就成了 AWS 的知名客户。

Ben：没错。他们用 AWS 处理数据流和火星登陆直播的视频分发，对吧？

David：没错。

Ben：AWS 通过和 NASA 及学术界合作，学会了如何服务机构客户，也锻炼出了企业销售能力。

David：这些客户可不会用信用卡付款。

Ben：对。

David：你得签合同、开账单、给折扣，还要组建销售团队，做很多事情，还得办 re:Invent 这样的大型会议。

Ben：他们肯定从 Oracle 挖来不少销售人员，因为 Amazon 的销售机器和老 Oracle 的销售机器很像。

David：没错。现在聊 Oracle。有一点是我在研究之前低估了的：大家都认为 AWS 就是 EC2、S3、基础设施即服务、计算、存储、网络，没错。不过 Amazon 不公布详细排名，但你在网上查 AWS 最受欢迎、使用最多的服务，除了 EC2 和 S3 这种巨无霸之外……

第三、第四和第五名全是数据库。AWS 是一家极大的数据库公司，它从 Oracle 手里抢走了很多市场份额。虽然云数据库和基础设施相关，但它是另一种业务。大家熟悉 AWS Redshift。它为什么叫 Redshift？

Ben：这儿有 Amazon 对外的官方说法，还有真正的说法。David，你知道官方版本吗？

David：是不是和多普勒效应有关？

Ben：对，和物理有关。我觉得 Amazon 还用 Doppler 给 Alexa 当过代号。Seattle 的一栋办公楼也叫这个名字。声波被压缩或拉长，比如警笛开过时音调变化，就是多普勒效应。Redshift 则是光线方面的现象，星体远离你时光谱会向红端偏移。

David：不过这里还有另一层故事。

Ben：名字其实是为了让 Big Red 偏移。

David：对，Big Red 指 Oracle。数据库市场巨大。它有两个大家不常想到、但非常重要的特点。第一，全球数据库软件市场规模约为 1,000 亿美元，每年增长 10%，因为计算机处理的所有事情都需要存进数据库。数据库不可或缺，市场规模大、增长也快。第二，数据库可能是所有软件里用户黏性最高的。

Ben：尤其现在人们创造的数据规模这么大。我们可以解释一下：你常会看到各种统计，说去年产生并存储的数据比之前整整十年、甚至整个世纪加起来还多。这不是准确原话，但类似说法有很多。我们直觉上知道数据越来越多，因为手机会不断存数据，但两个量都呈指数增长时，很难直观理解它们的差距。

我们都知道数据增长得很快，也知道互联网发展迅速。以前拨号上网，后来大家装上第一条有线宽带或 T1 专线；现在我在这儿录播客，David 在另一端，我的电脑直接连着千兆网络，太不可思议了。你会以为这两个领域的增长速度相似，实际速度却差得很远。

互联网速度提升得没有数据存储容量那么快。AWS 的 re:Invent 大会上曾有人说：‘很多客户想迁移到云端，但你们数据中心里有 PB 级、甚至 EB 级数据，该怎么办？’

他们最初推出了一种名叫 Snowball 的设备，容量 100 TB，非常安全，可以寄到你的办公室。插上设备，它就会自动导入全部数据，上面还带一台 Kindle，显示定制的运输信息。你能一路追踪到 Amazon 数据中心，他们还会审核设备。它防篡改、防弹，设计得很出色。

后来他们又推出了几代设备，有些还内置计算能力，可以用于现场处理。随后，数据存储继续快速增长，互联网速度只稍微快了一点。

Andy 在 2016 或 2017 年某届大会的主旨演讲中提到一种新设备，叫 Snowmobile。我们电脑里可能有 1 TB、2 TB 或 4 TB 的硬盘，觉得 100 TB 已经很多了。但 AWS 会说：‘我们会开一辆装满 Snowball 的半挂卡车到你的数据中心，帮你迁移数据。’

别低估半挂卡车在高速公路上行驶时的带宽。即使这样，用设备把数据迁到云上可能仍需六个月；如果通过广域网、也就是互联网上传，可能要好几年，甚至大半个世纪。

这很能说明你的观点：一旦企业数据都放进某个云服务商的数据库，迁移起来会很困难。切换服务商在实际操作上有很大障碍。

David：我还能举个更直接的例子。Amazon.com 刚成立时用的是 Oracle 数据库，直到 2019 年才完成迁移，改用 AWS 自己的数据库产品。

Ben：天哪。

David：那时距离 AWS 推出已经 13 年了。

Ben：太疯狂了。

David：Amazon 自己花了那么久才彻底从 Oracle 迁走。

Ben：与此同时，AWS 已经为其他公司提供了八种数据库服务，其中有三种是他们自己发明的。他们托管了一些开源数据库，也创建了 DynamoDB 等新型数据库。还有些产品兼容其他关系型数据库，但速度更快、性能更好。即使在公司内部，迁移也还是很难。

David：太不可思议了。往后看，你就会想：AWS 还有大量收入可以继续增长，而且客户黏性太高了。我们有位朋友提醒过一个最惊人的数据，我还发到了 Twitter 和 LinkedIn 上：AWS 目前年化营收约 800 亿美元。但这还不是最令人印象深刻、最难被竞争对手撼动的部分。看一下 Amazon 最新的 10-Q 财务报告，AWS 必须披露收入积压金额。

Ben：也就是已经签约，但还没确认为收入的合同金额。

David：这些大多是大型企业签下的合同收入，之后几个季度才会逐步确认。已承诺、已签约的收入积压超过 1,000 亿美元。我都不知道该说什么了。

Ben：现在还留在云外的数据存储和计算能力，远比已经迁进云里的多。

David：Amazon 可以停止所有销售活动、停止增长，甚至暂停开发新业务，但仍然有 1,000 亿美元的合同收入会陆续到账。

Ben：太不可思议了。

David：真的惊人。

Ben：David，你刚才说他们现在的年化收入是 700 亿、800 亿美元左右？

David：800 亿美元。

Ben：2014 年，Jeff Bezos 在年度股东信里写道：‘我认为 AWS 的市场规模没有上限。’那时他们在前一年才开始披露 AWS 财务数据，我想当时年化收入是 60 亿美元。

David：所谓 AWS 的‘IPO’，这个说法我记得是 Ben Thompson 先提出来的。那是在 2015 年，他们公布了 2015 年第一季度的财报。当时 AWS 年化收入达到 60 亿美元。

Ben：也许按当时的情况，它大概是个 40 亿美元的业务。Bezos 居然说：‘哇，我觉得它的市场规模没有上限。’这太疯狂了。真正的故事是，Amazon 发现了一种全新的、监管程度不高的公共事业，可以由此获得巨额利润。

David：至少对 Amazon 来说利润非常高。

Ben：不是只有利润率高，绝对利润也很高。运营这门业务可以带来数十亿美元利润，本质上就像经营一项公共事业。AWS 的市场规模，我前面说过 1,200 亿美元，可能还太保守了；市场每年增长 30%，还看不到增长结束的迹象。

David：我过去常说，我们这一代最大的趋势就是互联网，互联网已经成为现代生活的基础。AWS 为互联网提供动力，这当然没错。但我现在意识到，AWS 涉及的还不只是互联网，而是所有能由计算机处理的东西。AWS 基本上可以从中收取费用。

从这个角度看，所有能由计算机处理的东西，如今也都属于互联网。它们几乎是一回事。Jeff 这句话听起来很疯狂，但我觉得他说得对：AWS 的市场规模没有上限。

Ben：2014 年确实如此。不知道今天还能不能这么说。

David：好，AWS 在 2015 年公布财务数据，年化收入为 60 亿美元。‘IPO’时，它的年增长率是 70%。

Ben：对，那时增长速度仍然惊人。我觉得现在大约是 30% 到 35%，但当时增长快得离谱。

David：以 800 亿美元收入规模还保持 30% 到 35% 的增长，也很惊人。营业利润率是 19%。财报一公布，Amazon 股价涨了 15%。之后一年到两年里，股价应该还涨了大约 500%。

Ben：我怎么那么傻，股价当天涨完后没继续买？回头看一切时，最有意思的就是会觉得：现在股票太贵了。其实当时仍然很便宜。

David：确实非常便宜。2016 年还有个有意思的变化：严格来说，Andy Jassy 当时还不是 AWS 的 CEO。

Ben：他是 AWS 的高级副总裁。

David：没错，直到 2016 年才正式调整组织结构。Jeff Bezos 成为整个 Amazon 的 CEO，Jassy 成为 AWS 的 CEO，Jeff Wilke 则负责其余业务，也就是 Amazon 零售业务。

那一年 AWS 营收 120 亿美元，占公司营业利润的一半以上，之后它每年都贡献如此高的利润。第二年营收 170 亿美元，接着是 250 亿美元，2020 年达到 450 亿美元，去年是 620 亿美元，现在年化收入 800 亿美元。它还有 1,000 亿美元的合同收入积压，无论市场如何都会到账，简直不可思议。

2021 年 7 月 5 日，Jeff Bezos 退休。

Ben：太疯狂了，那才是一年前的事，感觉已经过去更久了。

David：我知道，确实很疯狂。公告早些时候就发了，但那天才正式交接。Andy Jassy 成为整个 Amazon 的 CEO，Adam Selipsky 则成为 AWS 的 CEO。我想这是最近一季的财报里提到的。AWS 还用 Snowmobile 在国际空间站上迁移数据。

Ben：哦，我不知道这件事，真的吗？

David：真的。我不确定他们是和 SpaceX 还是 Blue Origin 合作。他们把一些 Snowball 设备送上空间站，然后把数据从空间站迁了出来。之前说过，AWS 的云计算市场份额大约是 39%，Azure 是 21%，Alibaba 大约 10%。

他们在中国是主导云服务商，这本身也是个有意思的故事。就像 Amazon 一样，Alibaba 成了中国最大的云服务商。以后可以研究它为什么成功。Google 大约占 7%。

Ben：对。他们还通过很多方式扩大优势。2015 年他们披露财务数据的同一年，也收购了以色列公司 Annapurna Labs，开始设计自有芯片，包括训练芯片。

他们还推出自研芯片，训练芯片好像叫 Trainium，推理芯片叫 Inferentia。他们也开发了自己的机器学习芯片。

David：你知道这些芯片是谁制造的吗？

Ben：TSMC？

David：没错，他们是 TSMC 的大客户。

Ben：还有一点，他们在很多方面采用了 Microsoft 的延伸战略。最初有 RDS，客户可以在 RDS 上运行各种东西。后来他们推出了 Amazon Aurora，直接和 Oracle 竞争。Oracle 是一家自己控制专有数据库软件的公司。Amazon 会说：‘我们的数据库更快、性能更好，而且兼容。顺便说一句，我们的利润率更高。’

他们把 Oracle 曾经用过的策略也用上了。他们会说：‘现在我们有这么多客户，为什么不推出一些专有数据库呢？这些产品能带来更高利润。’比如带宽业务的毛利率就特别高，AWS 的带宽收费毛利率超过 90%。

没错，云计算客观上仍然比旧的软件许可证、本地存储和自行招聘 IT 团队更好。但 Amazon 也开始意识到自己的领先地位，开始采用一些类似旧厂商的策略。

接下来的问题是：为什么要做机器学习？计算能力显然是 AWS 的一个巨大支柱。数据库虽然没那么重要，但在客户黏性方面非常关键。每年他们上台演讲时都会发布新的数据库产品。

机器学习方面，他们推出了 SageMaker，还有专门介绍机器学习的新主旨演讲，提供很多云端机器学习服务。他们支持 Google 创建的 TensorFlow，也有自己的容器服务。

他们还有自己的弹性 Kubernetes 服务。客户需要 Kubernetes，他们必须提供，但也想让客户用自己的 Amazon Container Service。现在越来越明显的是，Amazon 的机器学习能力必须够好，但不必超过 Google。机器学习领域的策略在于……

你会在数据所在的云上使用机器学习，因为让机器学习靠近数据最重要。一旦你选择 Amazon 作为存储服务商，把装满数据的半挂卡车都开进他们的数据中心，你就不会再问：‘我应该在哪里运行机器学习？’你会直接在 AWS 上运行。

他们当然不能落后太多，但我觉得就算 Google 最有条件提供比任何人都好的机器学习服务，只要客户没有把数据存在那里，对它来说也没关系。

David：好，在进入分析之前，故事还有最后一部分。我不想把它叫作尾声，因为这件事还没解决，他们也没成功做到。

Ben：这还在发展中。

David：对，仍在发展中。我们对 AWS 赞不绝口，好像他们什么都做对了。其实也有一件事他们错过了。Ben，要不要讲讲？

Ben：数据仓库。他们为什么没做好？Snowflake 怎么会成长为一家价值 500 亿美元的独立公司？

David：不可思议。

Ben：它在 AWS 和其他公共云上存储数据，却能成为一家 500 亿美元的公司。Amazon 会说：‘我们有 Redshift，它是增长最快的 AWS 服务之一，表现很好。’但 Amazon 的数据库团队，整个部门一定很不甘心，因为 Snowflake 成功地在数据仓库市场突围了。

David：AWS 竟然没做好这件事，太奇怪了。

Ben：这可能是 AWS 最大的失误。为什么？我觉得有几个原因。首先是大公司问题。在 Amazon 这个规模上推出产品，要满足安全、运营、服务等级协议等要求。公司必须作出保证，这反而限制了它把产品做得更精简、明确、快速、直观，并真正以用户为中心。

Redshift 需要大量定制，而 Snowflake 装好就能给开发者使用。挺有意思的是，Snowflake 采用的模式和 AWS 早期的模式很像：S3、EC2 直接服务个人开发者。AWS 在这件事上有点成了自己成功的受害者。

Ben Thompson 在一篇我们会放到节目说明里的文章中指出了另一个原因。看看 Redshift 这个名字，他们在和 Oracle 正面竞争。他们复制了 Oracle 式的数据仓库，把它搬到云上。但很多 Snowflake 客户以前根本不会成为 Oracle 客户。

那是另一类客户，有另一套需求。Snowflake 的产品真的很出色，而这不是 Amazon 原本服务的客户群。现在他们换了新的领导层，正在重新整理业务，我觉得他们已经意识到问题，不过这次确实错过了机会。

David：可能还不是那种……级别的失误。

Ben：对，不像 Microsoft 和 Google 错失整个云市场那么严重。规模至少小一个数量级，可能两个。

David：好，我们现在来做分析，也该打分了。AWS 的成绩肯定会很高，但如果要挑一个污点，那就是这件事。

Ben：AWS 也像其他公司一样，成了自己成功的受害者。Amazon 的双披萨团队制度催生了很多服务，但整体产品策略并不连贯，AWS 的服务像一锅字母汤。我很久没登录 AWS 控制台了，但记得过去很难使用。界面上有太多模糊的图标，服务之间看起来很相似，很难分辨。

Amazon 现在显然意识到了这点，主题演讲开始强调面向行业的解决方案，比如：‘这是给这个行业用的服务。’还会分享其他同行的案例，不再一上来就说：‘我们有 476 项服务。’

我觉得他们也减少了主题演讲中过去反复出现的一种宣传：‘今年我们上线了 74 项重要功能，现在逐一介绍。’他们过去这样讲了很久，但客户越来越困惑。这也是 Google 的优势所在。Google 是后来者，产品策略更连贯，能帮助客户理解该怎么做，而不只是说：‘我们没有任何限制，自己看着办吧。’

AWS 现在还在推出新服务，试图帮客户设定护栏，比如：‘用这个管理工具，就不容易搞砸。’这有点像又多了一个标准制定机构。他们现在确实在努力清理产品线。不过他们已经占据市场主导地位，收入和营业利润都远超其他公司，所以很难说他们做得不成功。

David：我们该进入分析部分了吗？

Ben：好，先谈力量。我觉得 AWS 是历史上研究企业力量的最佳案例之一。老听众知道，所谓力量，是让企业获得持久的差异化回报，或者说，能持续比最接近的竞争对手更赚钱，从而创造企业价值。David，AWS 第一次披露财务数据时，营业利润率是 19% 左右吗？18% 还是 19%？

David：19%。

Ben：现在达到 30% 了。竞争环境变得更激烈，他们反而更赚钱。

David：这是怎么做到的？

Ben：这说明有某种力量在发挥作用。我能想到几个因素。摩尔定律让他们的销售成本不断大幅下降。我的猜测是，AWS 没有把成本下降和规模经济带来的全部好处都迅速转成客户折扣，结果利润率提高了。归根结底，成本确实随着摩尔定律下降了。

我觉得这又回到了一个完整的循环：Amazon 开始提供平台即服务，让客户使用它的基础组件。但要充分利用云的力量，运行 Lambda，或使用快得多的专有数据库，客户就得多支付一些利润。旧方法又变成新方法了。

现在 Amazon 已经是市场主导者，正在寻找提高利润率的方法。十几年前的想法——‘我们要打造未来的平台’——是对的，但前提是必须先通过基础设施即服务（IaaS）这一步。Amazon 做到了，营业利润率达到 18%。如今他们已经进入更偏平台即服务（PaaS）的阶段，客户黏性更高，利润率也达到 30%。

David：我看着‘七种力量’清单，给新听众解释一下：反向定位、规模经济、转换成本、网络效应、流程优势、品牌力量和稀缺资源。AWS 好像每项都能打勾。

Ben：对。早期起飞阶段，他们从各个方面都在反向定位。

David：确实。

Ben：这门生意本身就是传统厂商不会做的，因为会蚕食他们的业务。至于规模经济，AWS 可能是历史上规模经济最显著的生意。我一直在想，云计算为什么是在 2000 年代末出现的？

一个原因是移动设备。计算设备越来越小，更多计算就转移到云上，这确实加速了趋势。另一个原因是 Amazon 第一个尝试以这种规模建设数据中心，因为他们需要它来运行规模最大的 Web 应用 amazon.com。只有做到极大规模，云计算才可能盈利。

我想其他人可能在理论上评估过这种商业模式，但 Amazon 是唯一有条件在现实中实践，并真正实现规模经济的公司。

David：对，而且规模效应现在还会自我强化。Amazon 是最大的厂商，因此可以把资本支出和基础设施成本摊到更多客户身上。所以他们能以最低价格收费，同时获得与竞争者相当甚至更高的利润率。

Ben：太惊人了。然后是转换成本。客户把装满数据的半挂卡车开进你的数据中心之后，迁移成本就非常真实了。

David：Amazon.com 花了 13 年才从 Oracle 迁到 AWS。如果这还不算行业里的转换成本，我不知道什么才算。

Ben：品牌力量也很明显。现在他们是行业领导者，自然会赢。就算客户想用多云，通常也会说：‘好，那就用 Amazon，再加另一家。’毕竟 Amazon 的市场地位摆在那里。

当他们说‘这是 Amazon 历史上增长最快的服务’时，也在不断强化一个印象：他们推出的每项服务都深受客户欢迎。我确实觉得客户愿意为 AWS 付溢价，因为他们认为长期来看，这比选错技术、再花钱迁移要便宜。

David：竞争对手也有影响。现在 Microsoft 和 Google 可能让人更安心，但很长一段时间里，它们的战略变化很大。作为客户，你不知道今天押注某家公司的云战略，几年后会不会彻底变掉。

Ben：完全同意。

David：而 Amazon 一直比较稳定。

Ben：对。不过多云战略对 Microsoft 是个助推因素。人们会说：‘你不想被供应商锁定，所以最好把基础设施分散到多个云服务商。’过去五到八年，企业基本完全接受了这一说法。这也有一定道理。

这和移动应用开发有点像。我做 iPhone 开发时，有人劝我用 PhoneGap。我问为什么。他们说这样就不必再开发 Android 应用，成本更低。我说：‘但这样就用不了 iOS 的新 API 和底层硬件功能了，我做出来的应用可能没人愿意用。成本虽然低了，却做不出真正有意思的应用。’

多云也是这样。你可以用每家厂商的基础设施即服务，但云计算已经发展到这个阶段，云服务商确实能提供一些有意思的平台即服务功能，你会想利用这些功能。

这也是 Amazon 的论点。他们在最近两届主题演讲中开始谈这个问题，大概从 2021 年起意识到，多云会让本来属于 AWS 的一部分收入流向 Microsoft，也有一部分流向 Google，因为客户在分散使用不同云平台。

他们真正想说服客户的是：多云会增加复杂性，而继续使用 AWS 能省钱，也能使用他们推出的、需要紧密集成的各种功能。这就像他们刚起步时反对的做法，现在自己成了市场主导者，又开始这样说。

David：他们现在也在用这一套策略。

Ben：对。

David：这就是行业的轮回。

Ben：生命周期就是这样。

David：我想稍微岔开问一下。我们讲了其他大型科技公司如何错失云计算。Apple 有没有也错失这个机会？还是说这根本不是 Apple 会做的业务？

Ben：这是个好问题。这不像我印象中的 Apple 会做的事。我甚至觉得 iCloud 的后端是 Azure，至少有很长一段时间是这样。

David：实际上是 AWS。大概 2016 年《纽约时报》有篇报道说 Apple 使用 AWS，Apple 当时很不高兴。

Ben：我相信。Apple 基本不做企业服务。虽然它会批量向公司销售笔记本和手机，也有负责企业客户关系的经理，但这不是它的强项。不过，Tim Cook 领导下的 Apple 和我脑海中那家 Apple 很不一样。Tim Cook 专注于稳定、高利润的收入，这其实很符合他的风格。如果 Apple 有销售团队去开拓，我觉得他会做云服务。

David：我完全同意。Apple 是消费科技公司。也许它该自建 iCloud 数据中心？大概不该。但开发者对 Apple 非常重要，他们也确实应该和开发者保持紧密联系。

Apple 最近因为高利润商业模式和对开发者关系的垄断也遭遇过批评。移动设备是你说的云计算第一个切入点，Apple 当时是不是也该为开发者提供云服务？我不知道。反正它没有做，也就这样了。

Ben：他们现在做了一种可以在云里构建应用的服务，但我猜后端可能只是贴牌使用 AWS 或 Microsoft。

David：Apple 的事你永远猜不准，不过我觉得那个机会已经错过了。

Ben：对，我知道 Facebook 用 AWS。

David：有意思。

Ben：Facebook 规模太大，所以也自建并运营了一些第一方数据中心；但他们也会在某些业务上用 AWS。

David：我在想，AWS 有网络效应吗？我觉得没有。

Ben：我也觉得没有。

David：我不在乎你用不用 AWS。

Ben：对，它是间接的网络效应。你的成本会因为更多人使用 AWS 而下降，这体现在规模经济上。

David：七种力量里，除了比较特殊的流程优势和稀缺资源，我觉得网络效应是 AWS 唯一没有的那一项。反向定位、规模经济、转换成本和品牌力量都很强。

Ben：没错。

David：好。我们聊了如果 Apple 走另一条路可能会怎样，也讲了其他大型科技公司的情况。现在进入投资手册部分？

Ben：好。第一点和七种力量里的规模经济直接相关：我觉得 AWS 可能是历史上规模经济最强的生意。固定成本巨大，能分摊到极多客户身上，因此规模越大越有利。为了获得这种优势，他们第一次大规模建设新数据中心，投入了惊人的资本。

这些投资甚至让 Amazon 的现金流转负。过去 12 个月，他们的自由现金流大幅为负，因为仍在不断投入巨额资金。我觉得这门生意要达到盈利，需要极大的规模。

如今他们已经有了规模，业务会自我强化。既然已经是市场领导者，就必须继续投入。也可能因自己的错误而受伤，就像足球里的乌龙球，但规模经济形成之后，我觉得很难再把球踢丢。

David：我们在 Acquired 上聊过很多年了，也在这期里说过。AWS 是一家公用事业公司。想想公用事业公司是什么：正如你说的，它是规模经济最极致的生意。

这类生意需要极高的资本支出，所以社会通常会决定由一家集中化的供应商提供服务。大多数公用事业公司会受政府监管，限制其利润率，否则它们可能收取过高利润、剥削客户。AWS 却是互联网的一项不受监管的公用事业，而互联网可能是有史以来最大的市场。

Ben：说得好。我还想补充一点。大家常说：‘不敢相信 Amazon 从电商公司变成了云公司。’但从这个角度看，这两门生意其实非常相似。amazon.com 零售业务也需要巨额投入，在全球建设履约网络，然后把固定成本分摊给大量客户。AWS 只是把履约中心换成了数据中心。Amazon 早就具备经营这门生意所需的思维方式。

David：从规模化运营的角度看，两门生意确实很相似。

Ben：对。另一个值得强调的做法是降价。我们前面讲历史事实时没提到，但这很重要。到 2012 年，考虑到当时竞争很少，AWS 已经对所有服务全面降价 23 次。2013 年达到 40 次，2015 年达到 51 次。他们主动降价，并不是迫于竞争压力。

为什么降价？这让我想到 TSMC。在我们和 Hamilton、Chenyi 的节目里，Hamilton 指出 TSMC 主动降价吸引客户是合理的。你放弃今天的利润，换取未来的收益，这显而易见。

TSMC 还有一个不那么明显的原因：建一座新晶圆厂需要的资本支出非常大，而且是一次性投入，比如 100 亿美元。提前知道客户订单会让他们极为受益。另外，制造高端芯片的机器数量有限，比如 ASML 制造的设备。能确定自己拿到这些设备更有价值。

AWS 也有类似情况，只是 ASML 的设备比 AWS 买的服务器稀缺得多。AWS 争取市场份额非常有帮助，这样他们就能继续扩建更多数据中心。主动降价对 AWS 的作用不如 TSMC 那么大，但肯定也有收益。

David：Hamilton 这个观点说得好。战略不只是赢得订单，还要能放心地提前扩建设施，从而获得或进一步推动规模经济。

Ben：和 amazon.com 零售业务相比，AWS 还有个不利之处。零售业务里，客户下单后马上付款，Amazon 通常要过 60 天左右才付给供应商。这在云业务里正好相反。

David：对。这就是为什么 AWS 有 1,000 亿美元的收入积压，从这个角度看并不理想。

Ben：Amazon 不能提前收到这笔钱。他们的卖点之一就是客户不用先付一大笔钱来部署服务器。虽然有预留实例等方式，可以提前拿到一些现金，但总体上 Amazon 还是得先建数据中心、买地、买服务器，或者以其他方式租用服务器。

他们也得用资本租赁等方法来建设数据中心，而不是一开始全额买下来，让数据中心也变成类似收入那样的按用量付费模式。AWS 没有零售业务那种惊人的商业模式，也没有负现金转换周期。我觉得这一点很重要。AWS 的利润率虽然更高，但实际资本成本也更高。

David：我想 Amazon 的股价没跌那么多。不过上个季度他们公布了大幅负现金流，市场上的人都吓坏了。这就是原因，也说明大家其实不必太担心。但和零售业务的负现金转换周期相比，AWS 的商业模式在这方面确实不那么理想。

Ben：对。还有一点，我读了节目朋友 Tegus 的一篇很棒的访谈记录，采访对象是 AWS 以前的业务拓展人员，谈到了大家对多云的执着。这让我开始认真思考多云。

云的含义已经完全变了。早期的意思是：使用 Amazon 数据中心里的基础组件，按使用量付费。现在它更接近：使用云平台提供的服务，其中一些抽象层更高，而且是专有服务，也不一定要运行在云服务商自己的数据中心。

多云和混合云接下来的发展很有意思。多云指同时使用 Amazon 和 Microsoft；混合云指一部分基础设施在自己的数据中心，另一部分在服务商的数据中心。AWS 最近的主旨演讲里公布了不少 AWS 云服务，可以部署在客户自己的数据中心，由 Amazon 员工到现场安装和维护服务器。

David：这简直又回到 Oracle 的老商业模式了。

Ben：对。他们会说：‘这很棒，因为你在本地也能使用云端的 Lambda。’你会问：‘什么？它怎么在云端？’他们回答：‘因为这是 AWS Lambda，它是云服务，但部署在你的数据中心。’我都不知道‘云’这个词现在还有什么含义了。

我读这份访谈记录后开始认真想，现在的云究竟是什么？它可以同时存在于多个云平台和你自己的数据中心里。最后，关键变成了你用哪些专有服务来构建应用，而不再是应用实际运行在哪里。

David：也许现在的意思又回到了节目开头：云就是你的 IT 基础设施，你通过 API 调用它。我觉得这就是现在云的含义。

Ben：对。听众听完这期节目可能会想：‘我本来以为自己知道云是什么，结果 Ben 和 David 聊了三个小时，现在我又不知道了。’

David：是啊。你看到它就知道了。

Ben：没错。下一个投资手册要点是‘做出人们想要的产品’。这是 Y Combinator 的口号，而 Amazon 做的正是这件事。我觉得 Microsoft 和 Google 都想打造自己认为商业模式很高明、对技术人员很有意思的东西。Amazon 则去了解创业公司想在什么基础上构建产品，以及 IT 管理人员想把哪些系统迁到云上，然后直接做出这些东西。

听起来很普通，但你看那些主题演讲，每项服务背后都有明确的客户使用场景，那个场景直接推动了产品开发。很有意思的是，他们一直拒绝做一些东西。很多年来，人们一直问：‘你们为什么不做区块链？’

Andy Jassy 在台上说：‘我们还不太明白客户使用它的场景。’那是 2015 或 2016 年，比最近 Web3 热潮早了六年。我觉得他们非常坚持一个原则：在花一美元工程资源之前，先弄清楚客户到底需要什么。这非常了不起。

David：但同一时期，Microsoft 不是还投放过广告，宣传 Microsoft 云上的区块链吗？IBM 也在做企业区块链。

Ben：对。他们最后确实推出了某种产品，说：‘这不是区块链，但我们觉得它实现了你们这些想要区块链企业基础设施的人所要解决的问题。’

David：挺有意思。

Ben：下一个要点是不对称回报。这也是 Bezos 在 2015 年的一封股东信里写的。他说：‘如果一笔投资有 10% 的概率带来 100 倍回报，那每次都值得下注。但你仍然会有十分之九的概率判断错。我们都知道，挥棒追求全垒打就会经常三振；但商业和棒球不一样，棒球的结果分布有上限，无论你把球打得多好，一次最多得四分。在商业里，你有时一击就能得一千分。这种长尾回报分布，正是大胆下注重要的原因。少数大赢家能支付很多次试验的成本。’

David：市场规模没有上限。

Ben：市场规模没有上限。

David：这句话应该成为 Acquired 的口号，也许还能写进周边。

Ben：当然。可以印在商品上。

David：好。

Ben：这是他发表‘AWS 的市场规模没有上限’那番话的第二年。我觉得这是个完美例子。很多人会嘲笑某些风投投资项目，而我只对那些被人嘲笑的投资感兴趣，因为风投的核心就是寻找这种极端不对称的长尾回报。

我觉得 Jeff Bezos 比大多数风投人都更懂这一点。他是位非常优秀、敢于冒险的资本配置者。经营公司时，他也是很出色的运营型 CEO，而且确实是个天才。

关于 Bezos 有很多可以说的：他绝对是天才，也是杰出的运营者。但也许比这些更重要的是，他懂得如何配置资本。因此我觉得 Amazon 创造了风投史上最好的回报之一。AWS 是 Amazon 投资组合里一个完全由它拥有的风投项目。

David：他那句关于棒球的话是什么来着？他说‘棒球的结果分布有上限’？

Ben：对，结果分布有上限。

David：‘结果分布有上限’。这句太有 Jeff Bezos 的风格了。

Ben：没错。

David：我敢说 Aaron Judge 也在想：‘要是棒球的结果分布没有上限就好了。’太有意思了。说到这里又想起另一个题外话：我看了 re:Invent 上 Reed Hastings 的主题演讲。我们已经很久没做 Netflix 系列节目了。

Ben：对，我们该做第三期了。

David：那是什么时候的事？已经好几年了，不过我觉得节目内容依然很好。回头再听一遍应该很有意思。Reed Hastings 真是个极客。

Ben：当然。他最早创办的是一家数据存储公司。

David：对。我现在一提 Reed Hastings，就会想到 Netflix 的 CEO 和创始人，觉得他是个商业人士，和 Bezos 一样。其实他真的是个技术极客。

Ben：他是工程师，他的工程项目就是他经营的公司。

David：对，这绝对是最高级别的赞美。

Ben：像这样的人，你可以一直听他们讲话，因为他们谈战略时非常精确，想得比常见的空话深一层。

David：没错。

Ben：好，这是我最后一个要点。你在节目之前提到过，我把它留到投资手册的最后，因为这和我对上一期的总结形成了对比。

我曾用迷宫寻路作比喻：Amazon 会迅速推出东西、从中学习；如果发现方向不对，就停掉项目，带着经验开始下一件事。我把它称作‘暴力穷举式地寻找路径’。

AWS 的做法不同。他们没有很多像 Fire Phone 或 zShops 这样的失败项目。主要原因是，面向企业客户推出服务之后，要停掉它非常困难，这会损害客户信任。想想看，哪种代价更大：失去客户及其未来收入，还是继续维护一个不好用的服务？你通常只能继续维护它。

David：对，说得太好了。

Ben：他们确实有些产品没有发挥全部潜力，比如做过的各种办公应用，WorkMail……

David：还有 Chime。

Ben：他们的物联网服务 Greengrass 也是。物联网没有像所有人期待的那样发展。2013 年他们还推出过 AppStream，让移动应用可以在云里运行。但在 AWS，维护这些产品的承诺和消费业务完全不同。最好的例子是 SimpleDB。

后来推出的 DynamoDB 性能好得多，但用途相似。SimpleDB 给 Amazon 带来各种成本问题，不过仍有客户在用，所以他们一直保留着。我记得 Netflix 甚至也是它的客户之一。他们不愿意停掉客户还在使用的服务。

David：是啊，所以 AWS 产品页面上才会有 200 多项服务。这观点很好。他们停掉任何服务都不划算。

Ben：没错。好，要打分吗？

David：我们真的还需要讨论评分吗？

Ben：我们可以直接说：A+，结束。其实我想把讨论范围从 AWS 扩大到整个 Amazon。

David：好啊。

Ben：以后再评估。市值是什么？

David：市值没有上限。

Ben：价值是什么？金钱是什么？市值是什么？市值是所有未来现金流折算到今天的总和，折现率由市场决定。正如 Warren Buffett 所说，短期市场像投票机，长期市场像称重机。

Amazon 的市值是 1.5 万亿美元。他们经历了五年的增长，创造了一些现金，之后疫情爆发，他们又进行了大量再投资。现在他们肯定没有在创造现金。直到 2015 年左右，Amazon 都处于盈亏平衡状态。他们最擅长的事就是把每一美元重新投资，推动业务增长。

我很好奇，当他们不再这样做时，业务会是什么样子。总有一天，他们会发现可服务市场已经趋于饱和，放慢增长，开始每年赚取可能高达数千亿美元的利润，来支撑现在的市值吗？

一家市值 1.5 万亿美元的公司，理论上应该每年产生大约 1,000 亿美元现金或类似规模的现金流，但 Amazon 从来没做到，甚至也没接近过。要么他们继续现在的经营方式，不断寻找新的 AWS；要么总有一天他们得意识到：‘市场规模到头了，我们开始大规模创造现金吧。’尽管我们从来没见过他们这么做。

David：上一期我说过，如果有机会采访 Jeff Bezos，我最想问他：‘现在还是第一天吗？已经到第二天了吗？你为什么退休？’等等。

你刚才提出了一个有意思的观点。Amazon 整家公司在架构上都是为了始终保持‘第一天’状态。Jeff 一直会说，公司必须持续增长。

Ben：没错。但总有一天，这会碰到全球 GDP 的上限。除非全球 GDP 的增长速度超过 Amazon，否则公司不可能永远这样增长。但 Amazon 的增长速度显然比全球 GDP 快得多。

总有一天，也许十亿年后，我们都不在了，地球最终也会被太阳吞噬，所以不用把预测做得那么远。但我很好奇，如果你一直持有 Amazon 的股票，直到公司有一天不存在了，你最终真的能拿到 1.5 万亿美元的价值吗？

David：对，这个问题很好。也许这就是 Jeff 退下来、Andy Jassy 成为 Amazon 整体 CEO 的原因之一。

Ben：他要负责解决这个问题。

David：对。我在猜 Jeff Bezos 的想法，这当然有风险，因为他的想法可能比任何人猜测的都更广阔。但我觉得，这可能不是他个人最感兴趣的事。

Ben：有道理。我记得 2020 年 6 月之前的 12 个月里，Amazon 产生了 270 亿美元自由现金流。他们知道怎么创造现金。

我原以为从 2015 或 2016 年起，他们真的开始产生自由现金流，并且逐年增加。但疫情爆发后，这种情况就停止了。也许现在只是暂时异常，他们很快会回到 2019 年的状态；也许 Covid 前五年才是异常情况。

David：我记得 Andy 最近在财报电话会上说，他们会重新朝盈利方向发展，大家别担心，他们知道该怎么做。

Ben：对。这和 Jeff Bezos 在 2020 年疫情爆发时给股东的信完全相反。

David：他是不是说‘系好安全带’？

Ben：对。他说：‘如果你持有 Amazon 股票，最好坐下来。’

David：真棒。

Ben：没错。

David：他就像个牛仔。我们之前也聊过，他总穿牛仔靴。

Ben：确实如此。总之，这只是个思考练习。要给它打分，Amazon 创造了一个全新的市场，做出了历史上最大市场之一的业务，随后成为市场领导者，并且前五年都没有竞争对手，还成功抵挡住后来所有竞争者。它占云计算市场的份额刚好不至于引发监管问题。如果占到 80%，从长期来看可能反而不利。

David：还有个问题：Amazon 是不是有意让 Microsoft 重新回到竞争中？

Ben：我不这么认为。提前预见这种长期影响、主动蚕食当前业务，太难了。

Ben：不，我不这么认为。要预见这种复杂的未来、主动蚕食眼下的业务，实在太难了。

David：他们肯定会担心反垄断和监管问题。

Ben：没错，这就像 Google 看待 Bing 一样：‘谢天谢地，还有 Bing 存在。’

David：好，你给这家公司打几分？

Ben：A+，不过评分本身挺愚蠢的。对这种节目，我几乎想把评分环节删掉。我真正想继续思考的问题是：如果你永远持有 Amazon，拥有公司 100% 股权，花 1.5 万亿美元买下来之后，最终能不能靠业务利润收回这笔钱？

David：这就是 Warren Buffett 和 Ben Graham 的观点：股票代表企业的一部分。如果你能以 1.5 万亿美元买下整个 amazon.com，这笔资本配置划算吗？

Ben：对，这是个好问题。

David：我觉得应该划算。

Ben：我就知道你会这么说。

David：我可能有点偏心，但当然划算。别闹了，A+。AWS 这个部门有 1,000 亿美元的合同收入积压。A+，结束。

Ben：David 觉得 Amazon 股票便宜。

David：对。好了，你们有什么推荐？

Ben：对，我推荐一部自己在 Disney+ 上看得很开心的漫威剧：《月光骑士》。它可能不是我在 Disney+ 上看过最好的剧，但绝对是漫威电影宇宙电视剧里演技最好的一部。

David：哦，不错。

Ben：我觉得《洛基》的剧本可能最好，还有一部有 Scarlet Witch 的叫什么来着？

David：《旺达幻视》。

Ben：《旺达幻视》也很好。

David：是不错。

Ben：剧本写得太好了。我觉得《月光骑士》稍微差一点，但也接近那个水平。Oscar Isaac 饰演主角，他的表演是我在任何电影或电视剧里见过最好的之一。剧本也足够有趣，让你能坐下来欣赏他的表演，有种百老汇舞台剧的感觉。在这之前，我没意识到他是这么出色的演员。

David：等等，他是……

Ben：Poe Dameron。

David：对，我正要说呢。他还演过其他 Disney《星球大战》的内容。

Ben：他还演过其他很棒的角色。我记得他也出演了《机械姬》。

David：你看过新的《星球大战》作品吗？

Ben：我刚看完《欧比旺·克诺比》，感觉很失望。

David：可惜了。

Ben：作为《星球大战》粉丝，我还是挺喜欢多看一点《星球大战》，也喜欢看到不同年龄阶段的欧比旺。但我觉得这部剧削弱了角色的分量。下面要剧透了。如果你还没看《欧比旺·克诺比》，可以先停下来。不会告诉你结局，但会讲讲剧情内容。

故事发生在第三集结尾欧比旺抵达 Tatooine 之后、第一集《新希望》之前。《新希望》里有一种很强的历史感：他来到这里后，一直住在山洞里，和外界隔绝，直到我们再次见到他。

David：对，他就是那个隐居的老 Ben，对吧？

Ben：没错。他把 Luke 带到 Tatooine，之后就得负责保护他。这部剧却安排了他离开……去参加一场银河系冒险。

David：他就像 Han Solo 一样。

Ben：他离开 Tatooine 又回来——我不想剧透太多——还和许多重要角色互动，打了几场重要的仗。这些情节会彻底改变角色关系，让欧比旺在 Tatooine 的处境变得重要得多，感觉有点贬低了之前建立的正史。

David：我没看过任何新作品，不过感觉 Lucasfilm 得重新开始了，现在的方向好像不太对。

Ben：《星球大战》这个知识产权也不太适合做连续剧。我不知道，也许我错了。我确实很喜欢《曼达洛人》。我也喜欢《波巴·费特之书》里那段：‘波巴·费特没那么好看，不如我们再回去拍《曼达洛人》吧。’

David：这个话题可以改天再聊。

Ben：总之，《月光骑士》里 Oscar Isaac 的表演很棒，大家去看吧。

David：好。我的推荐很适合现在收听节目的大家。我非常确信，正在听这期节目的观众大多也会喜欢这项推荐：Lex Fridman 对 John Carmack 的五个半小时访谈。太精彩了。

Ben：确实太棒了。

David：Carmack 是传奇人物。

Ben：我听了一个小时，很精彩。

David：真的非常棒。我最近刚听完《Masters of Doom》有声书，没想到紧接着就看到这期访谈。

Ben：这太适合你了，简直完美。

David：我太满足了。读完《Masters of Doom》，再听 Lex 采访 Carmack，让我很想去找 John Romero 聊聊，或者至少多了解他对事情的看法，以及他在 id Software 的经历。

Carmack 在和 Lex 的访谈开头说，John Romero 比自己更擅长讲 id Software 的历史、也更像这段历史的守护者。他们之间有段很温馨的对话。我只听到一半，听到他谈自己和 Romero 的关系曾经非常紧张，后来彻底破裂。id Software 发生巨变后，我想他们现在和解了，这挺好的。

总之，Carmack 就是那种在技术领域远超常人的人。他后来做 VR，加入 Oculus，之后进入 Facebook 和 Meta。现在他在研究 AI，尤其是通用人工智能。这期访谈真的很棒。

Ben：太好了，我等不及要听完。好，听众朋友们，

听完本期后，欢迎到 acquired.fm/slack，和我们以及 Acquired 社群里 13,000 位成员一起讨论。也可以到 acquired.fm/store 购买 T 恤、背心、连帽衫、圆领衫或连体衣。

你也可以成为 Acquired LP，提前收听 LP 专属节目，网址是 acquired.fm/lp；或者等节目公开后，在你常用的播客播放器里搜索 Acquired LP Show。

我们的最新一期很快会上线，嘉宾是 Kindergarten Ventures 的 Nat Manning，也是 Kettle 的创始人。老实说，再保险非常有意思，我以前没想到自己会这么说。

David：企业 IT 基础设施也一样有意思。

Ben：完全同意。听众朋友们，祝大家一切顺利，下次再见。

David：下次再见。