2011-10-11 Steve Yegge.Google Platforms Rant

Refer To：《Stevey's Google Platforms Rant》。

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

我在 Amazon 工作了大约六年半，现在在 Google 也差不多这么久了。刚到 Google 时，有一件事立刻让我大开眼界——而且几乎每天都在被不断强化：Amazon 把所有事情都做错了，而 Google 把所有事情都做对了。当然，这是一句非常笼统的话，但意外地准确。简直疯狂。你大概可以从一百甚至两百个不同维度来比较这两家公司，而如果我记得没错的话，除了三个维度以外，Google 在其余所有方面都更胜一筹。我甚至专门做过一个表格，但法务不让我给任何人看，尽管招聘那边特别喜欢。

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't really have SREs and they make engineers pretty much do everything, which leaves almost no time for coding - though again this varies by group, so it's luck of the draw. They don't give a single shit about charity or helping the needy or community contributions or anything like that. Never comes up there, except maybe to laugh about it. Their facilities are dirt-smeared cube farms without a dime spent on decor or common meeting areas. Their pay and benefits suck, although much less so lately due to local competition from Google and Facebook. But they don't have any of our perks or extras -- they just try to match the offer-letter numbers, and that's the end of it. Their code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place.

打个很小的比方感受一下：Amazon 的招聘流程在根子上就是错的——让每个团队自己招人，结果就是不同团队之间的招聘标准极度不一致，尽管他们也试过各种办法想把标准“拉平”。他们的运维一团糟；基本没有真正意义上的 SRE，让工程师几乎什么都要自己干，结果几乎没什么时间写代码——当然，这也因团队而异，全看你抽到哪一签。他们对慈善、帮助弱势群体、社区贡献之类的事情一点都不关心，这些话题从来不会被提起，除非是拿来当笑料。他们的办公环境就是一片沾满灰土的格子间农场，连一分钱都舍不得花在装修或公共会议空间上。薪酬福利也很差，只是最近因为有 Google 和 Facebook 在本地抢人，情况才没那么糟。但他们完全没有我们这些额外福利——他们只会努力把 offer 上的数字对齐，然后就完事了。他们的代码库是一场灾难，根本没有任何全公司层面的工程规范，只有各团队各玩各的。

To be fair, they do have a nice versioned-library system that we really ought to emulate, and a nice publish-subscribe system that we also have no equivalent for. But for the most part they just have a bunch of crappy tools that read and write state machine information into relational databases. We wouldn't take most of it even if it were free.

公平地说，他们确实有一个做得不错的版本化库系统，这点我们确实应该学习，还有一个很不错的发布–订阅系统，这方面我们也没有同等的东西。但除此之外，他们大多数就是一堆破工具，在关系型数据库里读写状态机信息而已。就算这些工具免费送给我们，我们大概率也不会要。

I think the pubsub system and their library-shelf system were two out of the grand total of three things Amazon does better than google.

在我印象里，这个 pubsub 系统和那个“库货架”系统，是 Amazon 在大概“总共三件”做得比 Google 好的事情里，占了两件。

I guess you could make an argument that their bias for launching early and iterating like mad is also something they do well, but you can argue it either way. They prioritize launching early over everything else, including retention and engineering discipline and a bunch of other stuff that turns out to matter in the long run. So even though it's given them some competitive advantages in the marketplace, it's created enough other problems to make it something less than a slam-dunk.

你也可以勉强算上他们“疯狂偏爱快速上线并狂热迭代”这一条，说这是他们做得不错的地方，但这个可以从两面争。对 Amazon 来说，“早点上线”比所有其他事情都优先：包括员工留存、工程规范，以及一堆从长期看其实非常重要的东西。所以，虽然这种风格在市场上给了他们一些竞争优势，但同时也制造了足够多的其他问题，让这件事根本称不上完完全全的“绝对优势”。

But there's one thing they do really really well that pretty much makes up for ALL of their political, philosophical and technical screw-ups.

但有一件事他们做得真的、真的非常好，几乎抵消了他们在政治上、哲学上、技术上的所有乱七八糟。

Jeff Bezos is an infamous micro-manager. He micro-manages every single pixel of Amazon's retail site. He hired Larry Tesler, Apple's Chief Scientist and probably the very most famous and respected human-computer interaction expert in the entire world, and then ignored every goddamn thing Larry said for three years until Larry finally -- wisely -- left the company. Larry would do these big usability studies and demonstrate beyond any shred of doubt that nobody can understand that frigging website, but Bezos just couldn't let go of those pixels, all those millions of semantics-packed pixels on the landing page. They were like millions of his own precious children. So they're all still there, and Larry is not.

Jeff Bezos 是个臭名昭著的微观管理狂。他会对 Amazon 零售网站上的每一个像素进行微观管理。他曾经挖来了 Larry Tesler——Apple 的首席科学家，也可能是全世界最有名、最受尊敬的人机交互专家之一——然后整整三年把 Larry 说的每一句话都当空气，直到 Larry 最终——也算明智地——离开了公司。Larry 做了一堆大型可用性研究，用铁证如山的数据证明“根本没人看得懂那鬼网站”，但 Bezos 就是放不下那些像素，那些挤满了语义信息的落地页像素，在他眼里就像几百万个亲生孩子一样宝贝。于是，现在那些像素还统统留在那里，而 Larry 已经不在了。

比较形象的性格刻画，情绪函数出问题了，对简洁优雅缺少偏好。

Micro-managing isn't that third thing that Amazon does better than us, by the way. I mean, yeah, they micro-manage really well, but I wouldn't list it as a strength or anything. I'm just trying to set the context here, to help you understand what happened. We're talking about a guy who in all seriousness has said on many public occasions that people should be paying him to work at Amazon. He hands out little yellow stickies with his name on them, reminding people "who runs the company" when they disagree with him. The guy is a regular... well, Steve Jobs, I guess. Except without the fashion or design sense. Bezos is super smart; don't get me wrong. He just makes ordinary control freaks look like stoned hippies.

顺便说一句，微观管理并不是 Amazon 做得比我们好的“第三件事”。我的意思是，是的，他们在微观管理上确实很“强”，但我绝不会把这算作一种优点。我只是想先把背景交代清楚，好让你明白后来发生的事。我们说的是这么一个人：他在许多公开场合一本正经地表示，别人应该倒贴钱才能有机会在 Amazon 工作。只要有人跟他意见不合，他就会掏出印着自己名字的小黄便签，递过去，提醒对方“谁才是这家公司说了算的人”。这家伙简直是一个……呃，Steve Jobs 吧。只是没有品味和设计感而已。Bezos 非常聪明，这点没话说。他的问题是，把普通的控制狂都衬托得像嗑嗨了的嬉皮士。

So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.

于是有一天，Jeff Bezos 下了一道命令。当然，他老是在下各种命令，每次一发布，底下人就像被橡皮槌砸中的蚂蚁一样四处乱窜。但有那么一次——大概是在 2002 年前后，上下差个一年的样子——他发出了一条命令，离谱到什么程度呢？大到匪夷所思、大到让人瞪大眼睛、觉得沉重到不合逻辑，以至于把他以前所有的命令都衬托得像是“同事之间没缘由送你的绩效奖金”那么小儿科。

His Big Mandate went something along these lines:

他的这道“超级命令”大致是这么说的：

1.All teams will henceforth expose their data and functionality through service interfaces.

从今以后，所有团队都必须通过服务接口对外暴露自己的数据和功能。

2.Teams must communicate with each other through these interfaces.

各团队之间必须通过这些接口进行沟通和调用。

3.There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

不允许存在任何其他形式的进程间通信：不允许直接链接调用，不允许直接读取其他团队的数据存储，不允许共享内存模型，不允许有任何后门。唯一被允许的通信方式，就是通过网络进行服务接口调用。

4.It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

用什么技术无所谓。HTTP 也行，Corba 也行，Pubsub 也行，自定义协议也行——统统一样。Bezos 根本不在乎这些细节。

5.All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

所有服务接口，无一例外，都必须从第一天起就按“可对外开放”的标准来设计。也就是说，每个团队在规划和设计时，都必须假定将来要把这些接口开放给公司外部的开发者使用。绝对不允许有例外。

6.Anyone who doesn't do this will be fired.

任何不按这套做的人，都会被开除。

7.Thank you; have a nice day!

谢谢大家，祝你今天愉快！

Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.

哈哈！在座的一百五十多位前 Amazon 同事当然会立刻意识到，第 7 条是我自己加的一个小玩笑，因为 Bezos 绝对不会在乎你今天过得开不开心。

#6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Armgy Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word "hardened interface" a lot. Rick was a walking, talking hardened interface himself, so needless to say, everyone made LOTS of forward progress and made sure Rick knew about it.

不过，第 6 条却是货真价实的，所以大家立刻开始干活。Bezos 指派了几位“首席斗牛犬”来统筹这件事、保证事情不断推进，领头的是“超级灰熊斗牛犬” Rick Dalzell。Rick 以前是 Armgy Ranger，毕业于 West Point Academy，当过拳击手，当过 Wal*Mart 的“首席拷问官 slash CIO”，人高马大，表面和气，实际上气场强到吓人，他特别爱说的一个词叫“硬化接口”。Rick 本人就是一个行走的、会说话的“硬化接口”本尊，所以不用说，所有人都疯狂往前冲，进度条往死里拉，并且确保 Rick 随时知道他们“进展巨大”。

Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount while effecting this transformation.

在接下来的两三年里，Amazon 在内部完成了一次向面向服务架构的大转型。在这个过程中，他们学到了海量的东西。

There was lots of existing documentation and lore about SOAs, but at Amazon's vast scale it was about as useful as telling Indiana Jones to look both ways before crossing the street.

当时关于 SOA 的文档和“江湖秘笈”已经很多了，但在 Amazon 那种体量面前，这些东西的实际作用，大概也就相当于：有人郑重其事地叮嘱 Indiana Jones 过马路要“注意左右来车”。

Amazon's dev staff made a lot of discoveries along the way. A teeny tiny sampling of these discoveries included:

Amazon 的开发团队一路踩坑一路摸索，过程中有很多新发现。下面只是他们那些发现里极小的一小部分：

1.pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting.

值班报警的升级流程会变得困难得多，因为一个工单在真正的责任团队被识别出来之前，可能要在 20 个服务调用之间来回弹跳。如果每次“弹跳”都会经过一个响应时间是 15 分钟的团队，那么在正确的团队最终得知之前，可能已经过去好几个小时了——除非你额外搭建大量支撑系统、监控指标和报表机制。

2.every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service.

你身边的每一个兄弟团队，瞬间都变成了潜在的 DOS 攻击者。在没有在每一个服务上都设置非常严肃的配额和限流之前，谁都别想真正往前推进什么工作。

3.monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum.

监控和 QA 实际上是一回事。如果你不去做一次大型 SOA，你大概永远想不到这一点。当你的服务说“哦没事，我一切都好”时，很可能服务器里唯一还活着的组件，就是那个用愉快的机器人语气不断重复：“我没事，一切正常，收到完毕，断开”的小模块。要判断服务到底是不是正常响应，你必须真的对它发起一次次实际调用。这个问题会递归蔓延，直到你的监控系统对全部服务和数据做全面的语义级检查，这时它已经和自动化 QA 没什么区别了。所以，这两者本质上是一条连续体上的不同点而已。

4.if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where.

如果你有上百个服务，而且你的代码必须通过这些服务去和其他团队的代码交互，那么如果没有一个服务发现机制，你根本找不到它们。而要有服务发现，就离不开服务注册机制，而这个注册机制本身又是一个服务。所以 Amazon 搞了一个通用的服务注册中心，你可以通过反射式（以编程方式）查询到每一个服务、它的 API 是什么、它现在是不是存活着、部署在什么地方。

5.debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.

调试别人的代码问题会难得多得多，如果没有一个统一标准的方式，让每个服务都能跑在一个可调试的沙箱里，那基本是不可能完成的任务。

That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers.

上面只是一个很小的样本。像这样的经验教训，Amazon 是靠自己一点点“长出来”的，总共有几十条，甚至可能上百条。和服务对外开放相关的那些古怪问题也很多，但没有你想象得那么夸张。把系统拆分成服务这种方式，有一个副作用：它会在很多方面教育各团队不要轻易互信——就像他们本来就不应该轻信外部开发者那样。

This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally.

当我在 2005 年年中离开去 Google 的时候，这项工作还在进行中，但已经推进得相当深入了。从 Bezos 发布那道“圣旨”到我离开这段时间里，Amazon 在文化层面已经完成了一次转变，变成了一家“遇事先想到服务化”的公司。这已经变成他们处理一切设计问题时的基础方式，甚至包括那些也许永远不会对外发布的内部系统设计。

At this point they don't even do it out of fear of being fired. I mean, they're still afraid of that; it's pretty much part of daily life there, working for the Dread Pirate Bezos and all. But they do services because they've come to understand that it's the Right Thing.

到了这一步，他们做这些事已经不完全是因为“怕被炒鱿鱼”了。我的意思是，他们还是怕的——在 Dread Pirate Bezos 手下干活，这种恐惧算是日常生活的一部分。但他们之所以持续做服务化，是因为他们已经明白：这是“正确的做法”。

一个个独立的、明确分工的、提供差异化服务的组件=世界的本质。

There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it's the right thing because SOA-driven design enables Platforms.

SOA 这种路线毫无疑问有利有弊，而且有些弊端清单可以罗列得非常长。但总体来说，它依然是正确方向，因为以 SOA 为驱动的设计，才能真正催生 Platforms。

That's what Bezos was up to with his edict, of course. He didn't (and doesn't) care even a tiny bit about the well-being of the teams, nor about what technologies they use, nor in fact any detail whatsoever about how they go about their business unless they happen to be screwing up. But Bezos realized long before the vast majority of Amazonians that Amazon needs to be a platform.

当然了，这正是 Bezos 发布那道“圣旨”背后的真正目的。他过去并不（而且现在也不）在乎各个团队过得好不好，更不在乎他们用什么技术，事实上，只要事情没有出大差，他对他们具体怎么干活、用什么手段，一点兴趣都没有。但 Bezos 比绝大多数 Amazonians 更早意识到：Amazon 必须变成一个平台。

You wouldn't really think that an online bookstore needs to be an extensible, programmable platform. Would you?

你大概不会一开始就觉得，一个在线书店居然需要成为一个可扩展、可编程的平台，对吧？

Well, the first big thing Bezos realized is that the infrastructure they'd built for selling and shipping books and sundry could be transformed an excellent repurposable computing platform. So now they have the Amazon Elastic Compute Cloud, and the Amazon Elastic MapReduce, and the Amazon Relational Database Service, and a whole passel' o' other services browsable at aws.amazon.com. These services host the backends for some pretty successful companies, reddit being my personal favorite of the bunch.

Bezos 第一个重要的认识是：他们为了卖书、发货、处理杂项而搭出来的那一整套基础设施，其实完全可以“翻新用途”，变成一个极好的通用计算平台。于是，现在他们有了 Amazon Elastic Compute Cloud、Amazon Elastic MapReduce、Amazon Relational Database Service，还有一大串其他服务，都可以在 aws.amazon.com 上翻到。这些服务承载了不少非常成功公司的后台系统，其中我个人最喜欢的是 reddit。

The other big realization he had was that he can't always build the right thing. I think Larry Tesler might have struck some kind of chord in Bezos when he said his mom couldn't use the goddamn website. It's not even super clear whose mom he was talking about, and doesn't really matter, because nobody's mom can use the goddamn website. In fact I myself find the website disturbingly daunting, and I worked there for over half a decade. I've just learned to kinda defocus my eyes and concentrate on the million or so pixels near the center of the page above the fold.

他的另一个重大认知是：他不可能总是自己做出“那个正确的东西”。我猜，当 Larry Tesler 说“他妈都用不了那个该死的网站”的时候，可能在 Bezos 心里敲响了某根弦。我们甚至都不太清楚 Larry 说的是谁的妈，但其实这根本不重要，因为压根没有谁的妈能用得了那个网站。事实上，就连我自己都觉得那个网站让人望而生畏，而我在那儿干了五年多。我只是学会了把眼睛微微虚焦，只盯着首屏中心附近那大概一百万个像素看。

I'm not really sure how Bezos came to this realization -- the insight that he can't build one product and have it be right for everyone. But it doesn't matter, because he gets it. There's actually a formal name for this phenomenon. It's called Accessibility, and it's the most important thing in the computing world.

我并不确切知道 Bezos 是怎么走到这个认知的——也就是：他不可能做出一个产品，让它对所有人都刚刚好。但这并不重要，因为关键在于他现在已经明白了。这种现象其实有一个正式的名字，叫做 Accessibility，而它是整个计算机世界里最重要的东西。

The. Most. Important. Thing.

最。重。要。的。东。西。

If you're sorta thinking, "huh? You mean like, blind and deaf people Accessibility?" then you're not alone, because I've come to understand that there are lots and LOTS of people just like you: people for whom this idea does not have the right Accessibility, so it hasn't been able to get through to you yet. It's not your fault for not understanding, any more than it would be your fault for being blind or deaf or motion-restricted or living with any other disability. When software -- or idea-ware for that matter -- fails to be accessible to anyone for any reason, it is the fault of the software or of the messaging of the idea. It is an Accessibility failure.

如果你此刻有点纳闷：“啊？你是说那种给盲人、聋人用的 Accessibility 吗？”——那你绝对不是一个人，因为我渐渐发现，有很多很多人和你一样：对于他们来说，这个观念本身就缺乏足够的 Accessibility，所以它一直没真正传达到他们那里。这并不是你不理解的错，就像如果你是盲人、聋人、行动受限，或者有任何其他残障，这也不是你的错一样。当一款软件——或者更广义的“理念软件”——因为任何原因没能对某些人变得可达、可用，那就是软件本身或者理念传递方式的过失。这就是一次 Accessibility failure。

Like anything else big and important in life, Accessibility has an evil twin who, jilted by the unbalanced affection displayed by their parents in their youth, has grown into an equally powerful Arch-Nemesis (yes, there's more than one nemesis to accessibility) named Security. And boy howdy are the two ever at odds.

就像人生中其他所有又大又重要的东西一样，Accessibility 也有一个“邪恶的孪生兄弟”，在童年时代因为父母偏心受了冷落，长大后摇身一变，成了同样强大的死对头（是的，对 Accessibility 来说，死敌不止一个），它的名字叫 Security。而这两位之间的对立，那真是精彩绝伦。

But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.

但我想争论的是，Accessibility 实际上比 Security 更重要，因为如果你把 Accessibility 调到 0，你就根本没有产品可言；而如果你把 Security 调到 0，你仍然有可能得到一个“还算成功”的产品，比如 Playstation Network。

这一段是关于语言的，Accessibility、Security的用词一般，语言本身是对世界知识的压缩，压缩的越好在现实的使用中也越好，更早、更本质的说法是分工促进繁荣，可以推到人类的起源，雄性和雌性的分工。

So yeah. In case you hadn't noticed, I could actually write a book on this topic. A fat one, filled with amusing anecdotes about ants and rubber mallets at companies I've worked at. But I will never get this little rant published, and you'll never get it read, unless I start to wrap up.

所以，是的——如果你还没意识到的话，其实我完全可以就这个话题写一本书，一本很厚的书，里边塞满了我待过的那些公司里关于蚂蚁和橡皮锤的趣事轶闻。不过如果我不开始收尾，这篇小小的吐槽永远不会有发表的机会，而你也永远没有机会读到它。

That one last thing that Google doesn't do well is Platforms. We don't understand platforms. We don't "get" platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.

Google 做得不好的最后一件事，就是 Platforms。我们不理解平台，我们并不真正“get”平台。你们当中是有少数人懂的，但真的是少数。这一点在过去六年里让我越来越痛切。我本来有点指望来自 Microsoft、Amazon，以及最近的 Facebook 的竞争压力，能把我们整个公司给“打醒”，然后开始认真做通用服务——不是那种临时拼凑、半吊子的那种，而是像 Amazon 那样：一口气上，玩真的，不作弊，从此把这件事当成头等大事。

But no. No, it's like our tenth or eleventh priority. Or fifteenth, I don't know. It's pretty low. There are a few teams who treat the idea very seriously, but most teams either don't think about it all, ever, or only a small percentage of them think about it in a very small way.

但并没有。并没有。平台大概只是我们排在第十、第十一个的优先级。也可能是第十五个，我也说不清，反正很靠后。确实有少数团队把这个理念当回事，但大多数团队要么根本从来没想过这件事，要么只有极少数人、用极其有限的方式在想一丢丢。

It's a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they're building products. And a stubby service is a pretty pathetic service. Go back and look at that partial list of learnings from Amazon, and tell me which ones Stubby gives you out of the box. As far as I'm concerned, it's none of them. Stubby's great, but it's like parts when you need a car.

就算只是让大多数团队提供一个基于 Stubby 的小服务，好让别人能以编程方式访问他们的数据和计算，这都已经是个巨大跨越了。大部分人根本认为自己是在“做产品”。而一个 Stubby 小服务，本身是一个非常可怜的服务。回头看看我们之前提到的 Amazon 那些学习清单，告诉我 Stubby 能“自带”哪几条？在我看来，一条都没有。Stubby 本身是很棒，但当你需要的是一辆车时，它更像是一堆散件。

A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.

没有平台，产品就是废物。更精确一点说，一个没有平台支撑的产品，最终一定会被一个“带平台版本的等价产品”取而代之。

Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don't get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: "So is it the Stalker API?" She got all glum and said "Yeah." I mean, I was joking, but no... the only API call we offer is to get someone's stream. So I guess the joke was on me.

Google+ 是一个最典型的例子，证明我们从最高层管理者（hi Larry, Sergey, Eric, Vic, howdy howdy）到最底层的叶子员工（hey yo），在“平台”这件事上是彻底失败的。我们全都没 get 到。关于平台有一条黄金法则：Eat Your Own Dogfood。Google+ 的 platform 完全是事后想起来随手补的一块，悲惨得不忍直视。上线时我们根本没有任何 API，而据我最后一次了解的情况，我们只有一个可怜兮兮的 API 调用。当时团队里有人跑来兴冲冲地告诉我“我们上线 API 了！”，我问她：“所以，这是 Stalker API 吗？”她一下子蔫了，说：“是的。”我的意思本来是开玩笑的，但并不是……我们唯一提供的 API 调用，就是获取某个人的 stream。所以最后被打脸的，其实是我自己。

Microsoft has known about the Dogfood rule for at least twenty years. It's been part of their culture for a whole generation now. You don't eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.

Microsoft 至少在二十年前就已经懂得 Dogfood 这条规则了。对他们来说，这已经是整整一代人文化的一部分。你不能自己吃 People Food，却只给开发者 Dog Food。那样做，只是用平台的长期价值去换取短期的一点点成功而已。平台这件事，从头到尾讲的都是长期思维。

Google+ is a knee-jerk reaction, a study in short-term thinking, predicated on the incorrect notion that Facebook is successful because they built a great product. But that's not why they are successful. Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone. Some people spend all their time on Mafia Wars. Some spend all their time on Farmville. There are hundreds or maybe thousands of different high-quality time sinks available, so there's something there for everyone.

Google+ 则是一种条件反射式的产物，是短期思维的教科书级案例，建立在一个错误前提之上：认为 Facebook 之所以成功，是因为他们做出了一个伟大的产品。但这根本不是 Facebook 成功的原因。Facebook 成功，是因为他们通过让其他人来干活，构建出了一整片“产品星座”。所以，Facebook 对每个人来说都不一样。有人把所有时间都砸在 Mafia Wars 上，有人把所有时间都砸在 Farmville 上，还有成百上千个高质量的“时间黑洞”可供选择，总之，每个人都能找到适合自己的东西。

Our Google+ team took a look at the aftermarket and said: "Gosh, it looks like we need some games. Let's go contract someone to, um, write some games for us." Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.

我们的 Google+ 团队看了一眼“后市场”，然后说：“天哪，看起来我们需要一些游戏。那就去找人，嗯，给我们做几款游戏吧。”你现在是不是开始意识到这种思路有多离谱了？问题在于：我们试图去预测用户想要什么，然后替他们“包办”交付。

You can't do that. Not really. Not reliably. There have been precious few people in the world, over the entire history of computing, who have been able to do it reliably. Steve Jobs was one of them. We don't have a Steve Jobs here. I'm sorry, but we don't.

你做不到这一点。至少做不到稳定、可靠地做到这一点。整个计算机史上，真正能较为可靠地做到这一点的人少之又少。Steve Jobs 是其中之一。而我们这里并没有 Steve Jobs。很抱歉，但事实就是如此。

Larry Tesler may have convinced Bezos that he was no Steve Jobs, but Bezos realized that he didn't need to be a Steve Jobs in order to provide everyone with the right products: interfaces and workflows that they liked and felt at ease with. He just needed to enable third-party developers to do it, and it would happen automatically.

Larry Tesler 或许曾经让 Bezos 意识到自己不是 Steve Jobs，但 Bezos 也随之意识到：他并不需要成为 Steve Jobs，才能给所有人提供“正确的产品”——那些他们喜欢、用着顺手的界面和工作流。他要做的，只是让第三方开发者有能力去完成这件事，然后这一切就会“自动发生”。

I apologize to those (many) of you for whom all this stuff I'm saying is incredibly obvious, because yeah. It's incredibly frigging obvious. Except we're not doing it. We don't get Platforms, and we don't get Accessibility. The two are basically the same thing, because platforms solve accessibility. A platform is accessibility.

对于那些觉得我说的这一切“显而易见”的（众多）同事，我得先说声抱歉，因为没错——这些东西确实明显得要命。除了有一个小问题：我们并没有在做这些事。我们不懂 Platforms，我们也不懂 Accessibility。而这两者本质上几乎是一回事，因为平台就是用来解决可达性问题的。平台本身，就等于 Accessibility。

So yeah, Microsoft gets it. And you know as well as I do how surprising that is, because they don't "get" much of anything, really. But they understand platforms as a purely accidental outgrowth of having started life in the business of providing platforms. So they have thirty-plus years of learning in this space. And if you go to msdn.com, and spend some time browsing, and you've never seen it before, prepare to be amazed. Because it's staggeringly huge. They have thousands, and thousands, and THOUSANDS of API calls. They have a HUGE platform. Too big in fact, because they can't design for squat, but at least they're doing it.

所以，是的，Microsoft 是懂平台的。而你我都很清楚，这件事本身有多让人意外，因为他们在很多事情上其实都“不太 get 得到”。但他们之所以理解平台，只是一个“历史偶然”：他们从一开始就是做平台起家的。所以在这个领域，他们已经积累了三十多年。如果你去 msdn.com 上逛一圈，而且是第一次去，看完之后你要有被震住的心理准备——因为它实在是大得惊人。他们有成千、成千、成千上万的 API 调用。他们有一个庞大的平台。大到甚至有点过头了——因为他们的设计能力实在配不上这么大一摊东西——但至少，他们真的在做平台。

Amazon gets it. Amazon's AWS (aws.amazon.com) is incredible. Just go look at it. Click around. It's embarrassing. We don't have any of that stuff.

Amazon 是懂平台的。Amazon 的 AWS（aws.amazon.com）简直令人难以置信。你只要点进去看看，到处点点点，就会有一种“尴尬到脚趾抠地”的感觉——因为我们根本没有那些东西。

Apple gets it, obviously. They've made some fundamentally non-open choices, particularly around their mobile platform. But they understand accessibility and they understand the power of third-party development and they eat their dogfood. And you know what? They make pretty good dogfood. Their APIs are a hell of a lot cleaner than Microsoft's, and have been since time immemorial.

Apple 也很显然是懂平台的。它们在一些根本性问题上做了“不开放”的选择，尤其是在移动平台上。但他们懂 Accessibility，也懂第三方开发的力量，而且他们自己吃自己的 dogfood。你知道吗？他们做的 dogfood 质量还挺高。他们的 API 比 Microsoft 的干净利落太多了，而且一直以来都是如此，几乎从远古时代就是这样。

泛化能力体现在方方面面，很多噪音会掩盖这个最本质的东西。

Facebook gets it. That's what really worries me. That's what got me off my lazy butt to write this thing. I hate blogging. I hate... plussing, or whatever it's called when you do a massive rant in Google+ even though it's a terrible venue for it but you do it anyway because in the end you really do want Google to be successful. And I do! I mean, Facebook wants me there, and it'd be pretty easy to just go. But Google is home, so I'm insisting that we have this little family intervention, uncomfortable as it might be.

Facebook 也懂平台。而这恰恰是最让我担心的地方，也是把我从懒沙发上拽起来写这篇东西的原因。我讨厌 blogging，我讨厌在 Google+ 上长篇大论地抱怨——或者不管你们现在给这事起了个什么新名字——明明这是个极其糟糕的发牢骚场所，但我还是在这儿写，因为归根到底我是真的希望 Google 能成功。而且我真心是这样想的！Facebook 想让我过去，对我来说跳过去其实也不难。但 Google 是家，所以即便这场“家庭干预”让人非常不舒服，我还是坚持要把这话说出来。

Google能吸引人才的地方。

After you've marveled at the platform offerings of Microsoft and Amazon, and Facebook I guess (I didn't look because I didn't want to get too depressed), head over to developers.google.com and browse a little. Pretty big difference, eh? It's like what your fifth-grade nephew might mock up if he were doing an assignment to demonstrate what a big powerful platform company might be building if all they had, resource-wise, was one fifth grader.

当你对 Microsoft 和 Amazon 的平台体系，以及大概还有 Facebook（我没去细看，因为怕自己心情太抑郁）感到惊叹之后，再顺道去 developers.google.com 上逛一圈。差距很大，对吧？那感觉就像你五年级的侄子，为了完成一份“假装自己是一个强大平台公司”的课堂作业，靠他一个小学五年级生的资源随手拼出的一点东西。

Please don't get me wrong here -- I know for a fact that the dev-rel team has had to FIGHT to get even this much available externally. They're kicking ass as far as I'm concerned, because they DO get platforms, and they are struggling heroically to try to create one in an environment that is at best platform-apathetic, and at worst often openly hostile to the idea.

请别误会我的意思——我非常清楚，dev-rel 团队为了把哪怕这么一点点东西开放到外部，都得“拼命厮杀”一番。在我看来，他们干得非常棒，因为他们是真正懂 Platforms 的，而且他们在一个对平台充其量是冷漠、在更糟情况下甚至公开敌视“平台理念”的环境里，依然在英勇挣扎、试图搭出一套平台来。

I'm just frankly describing what developers.google.com looks like to an outsider. It looks childish. Where's the Maps APIs in there for Christ's sake? Some of the things in there are labs projects. And the APIs for everything I clicked were... they were paltry. They were obviously dog food. Not even good organic stuff. Compared to our internal APIs it's all snouts and horse hooves.

我只是坦率地描述一下 developers.google.com 在一个局外人眼里是什么样子而已：它看起来很小儿科。拜托，Maps 的 API 都去哪儿了？里面有些东西还是 labs 项目。我点开的那些东西对应的 API……简直寒酸。显然是一堆 dog food，连“有机狗粮”都算不上。和我们内部使用的 API 相比，简直全是“猪鼻子加马蹄子”级别的下脚料。

And also don't get me wrong about Google+. They're far from the only offenders. This is a cultural thing. What we have going on internally is basically a war, with the underdog minority Platformers fighting a more or less losing battle against the Mighty Funded Confident Producters.

另外别误会我对 Google+ 的态度。它绝不是唯一的问题小孩。这是一种文化层面的问题。我们内部现在基本是一场战争：少数处于弱势的“平台派”，在和那些资金雄厚、底气十足的“做产品派”进行一场或多或少注定要输的战斗。

Any teams that have successfully internalized the notion that they should be externally programmable platforms from the ground up are underdogs -- Maps and Docs come to mind, and I know GMail is making overtures in that direction. But it's hard for them to get funding for it because it's not part of our culture. Maestro's funding is a feeble thing compared to the gargantuan Microsoft Office programming platform: it's a fluffy rabbit versus a T-Rex. The Docs team knows they'll never be competitive with Office until they can match its scripting facilities, but they're not getting any resource love. I mean, I assume they're not, given that Apps Script only works in Spreadsheet right now, and it doesn't even have keyboard shortcuts as part of its API. That team looks pretty unloved to me.

任何那些真正从底层就把“自己应该是对外可编程的平台”这个观念内化进去的团队，统统都是弱势一方——Maps 和 Docs 是两个典型例子，我也知道 GMail 现在正试图往这个方向靠。但他们要为此争取到预算非常困难，因为这根本不在我们的文化里。和庞然大物般的 Microsoft Office 编程平台相比，Maestro 拿到的那点资金弱得可怜：简直就是一只毛茸茸的小兔子要去对抗一头霸王龙。Docs 团队心里很清楚：在脚本能力上没追平 Office 之前，他们就永远不可能真正具有竞争力，但他们就是得不到资源上的偏爱。我的意思是，从 Apps Script 现在还只在 Spreadsheet 里能用、而且它的 API 里甚至连键盘快捷键都没有这一点来看，我只能假定他们的确没什么资源。这团队在我眼里，看起来就是不怎么被爱。

Ironically enough, Wave was a great platform, may they rest in peace. But making something a platform is not going to make you an instant success. A platform needs a killer app. Facebook -- that is, the stock service they offer with walls and friends and such -- is the killer app for the Facebook Platform. And it is a very serious mistake to conclude that the Facebook App could have been anywhere near as successful without the Facebook Platform.

讽刺的是，Wave 本身就是一个很棒的平台，愿它安息。但把某样东西做成一个平台，并不会立刻让你成功。一个平台需要一款 killer app。Facebook——也就是他们提供的那个带墙、带好友之类的“标配服务”——就是 Facebook Platform 的 killer app。而如果得出这样的结论：“即便没有 Facebook Platform，Facebook 这个 App 也能取得差不多的成功”，那就犯了非常严重的错误。

You know how people are always saying Google is arrogant? I'm a Googler, so I get as irritated as you do when people say that. We're not arrogant, by and large. We're, like, 99% Arrogance-Free. I did start this post -- if you'll reach back into distant memory -- by describing Google as "doing everything right". We do mean well, and for the most part when people say we're arrogant it's because we didn't hire them, or they're unhappy with our policies, or something along those lines. They're inferring arrogance because it makes them feel better.

你知道外面的人总爱说 Google 很傲慢吧？我是 Googler，所以每当听到这种话，我和你一样烦。总体上说，我们并不傲慢。我们大概有 99% 是 Arrogance-Free（无傲慢）的。如果你还记得这篇长文一开始的话，我曾经把 Google 描述成“把所有事情都做对了”的公司。我们的出发点确实是好的，而大多数人在骂我们傲慢的时候，往往是因为我们没录用他们，或者他们对我们的某些政策不满意，诸如此类。所谓的“傲慢”更多是他们推断出来、用来让自己心里舒服一点的。

But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we're being fools. You can attribute it to arrogance, or naivete, or whatever -- it doesn't matter in the end, because it's foolishness. There IS no perfect product for everyone.

但当我们摆出一副姿态，仿佛“我们知道如何为所有人设计出完美产品”，而且，相信我，我太经常听到这种说法了，这时候我们就是在装傻。你可以把它归因于傲慢，或者天真，或者别的什么——但归根到底，这就是愚蠢。根本不存在一个对所有人都完美的产品。

And so we wind up with a browser that doesn't let you set the default font size. Talk about an affront to Accessibility.

于是，我们最后搞出了一款不允许你设置默认字体大小的浏览器。要说这对 Accessibility 有多大的冒犯，再形容也不为过。

I mean, as I get older I'm actually going blind. For real. I've been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they're quite brazen about it, and Fuck You if you're blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.

我是说，随着年纪变大，我是真的在一点点变得看不清东西。真事。我一辈子都近视，而一旦你过了 40 岁，你就开始看不清近处的东西。所以字体选择就成了一件生死攸关的事：它完全可以把你彻底挡在产品之外。但在这里，Chrome 团队的态度就赤裸裸地傲慢：他们要做的是一款零配置产品，对此他们理直气壮，而如果你是盲的、聋的，或者有什么其他障碍，那就 Fuck You——你这辈子每打开一个新页面，都自己去按 Ctrl-+ 吧。

It's not just them. It's everyone. The problem is that we're a Product Company through and through. We built a successful product with broad appeal -- our search, that is -- and that wild success has biased us.

问题不只是出在他们身上，而是出在“所有人”身上。症结在于，我们从头到脚都是一家 Product Company。我们打造出了一款广受欢迎的成功产品——也就是搜索——而这次疯狂的成功在潜移默化中给我们带来了偏见。

巨大的成功带来巨大的偏见，改变已经存在的想法非常困难。

Amazon was a product company too, so it took an out-of-band force to make Bezos understand the need for a platform. That force was their evaporating margins; he was cornered and had to think of a way out. But all he had was a bunch of engineers and all these computers... if only they could be monetized somehow... you can see how he arrived at AWS, in hindsight.

Amazon 过去也是一家产品公司，所以要让 Bezos 意识到“平台”的必要性，需要一股体系外的力量来倒逼。这股力量就是他们日益蒸发的利润率；他被逼到墙角，不得不去思考一条出路。但他手上只有一堆工程师和一大堆计算机……如果这些东西能被变现就好了……事后再回头看，你就能理解他是怎么一路推导出 AWS 这条路的。

Microsoft started out as a platform, so they've just had lots of practice at it.

Microsoft 一开始就是做平台起家的，所以在这方面他们只是“练得久、经验多”而已。

Facebook, though: they worry me. I'm no expert, but I'm pretty sure they started off as a Product and they rode that success pretty far. So I'm not sure exactly how they made the transition to a platform. It was a relatively long time ago, since they had to be a platform before (now very old) things like Mafia Wars could come along.

不过 Facebook 让我非常担心。我不敢说自己是这方面的专家，但我几乎可以肯定，他们一开始是以产品起步的，而且凭借这款产品一路狂飙了很远。所以我并不确切知道，他们究竟是如何完成平台化转身的。这事发生得相当早，因为在像 Mafia Wars 这种（现在看起来非常“上古”的）东西出现之前，他们就已经必须是一个平台了。

Maybe they just looked at us and asked: "How can we beat Google? What are they missing?"

也许他们只是看了我们一眼，然后问自己：“我们怎么才能打败 Google？他们少了什么？”

The problem we face is pretty huge, because it will take a dramatic cultural change in order for us to start catching up. We don't do internal service-oriented platforms, and we just as equally don't do external ones. This means that the "not getting it" is endemic across the company: the PMs don't get it, the engineers don't get it, the product teams don't get it, nobody gets it. Even if individuals do, even if YOU do, it doesn't matter one bit unless we're treating it as an all-hands-on-deck emergency. We can't keep launching products and pretending we'll turn them into magical beautiful extensible platforms later. We've tried that and it's not working.

我们面对的问题非常巨大，因为要想开始追上去，必然需要一场极为剧烈的文化变革。我们不做内部的服务化平台，同样也不做对外的平台。这意味着“没 get 到平台这件事”是整个公司范围内的流行病：PM 不懂，工程师不懂，产品团队不懂，谁都不懂。就算有个别人懂，就算是“你”懂，如果我们不把这件事当成一次“全员战备级别的紧急情况”，那也毫无意义。我们不能再继续一轮又一轮地上线产品，同时假装以后可以神奇地把它们变成优雅、漂亮、可扩展的平台。我们试过这种做法，而事实是：根本行不通。

The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.

关于平台的黄金法则“Eat Your Own Dogfood”，可以换一种说法来表达：“从平台开始，然后用它承载一切。”你不能寄希望于事后再把平台“焊”上去。至少不会轻松——去问问那些给 MS Office 做平台化的人，或者问问那些给 Amazon 做平台化的人就知道了。如果你选择延后这件事，所需投入的工作量会是“起步时就做对它”的十倍。你不能作弊。你不能给内部应用开什么秘密后门，去获得特殊优先级访问，不管理由看起来多冠冕堂皇。你必须在前期就把那些硬骨头啃下来。

产品优先？平台优先？平台的最终趋势是碎片化，即便“Eat Your Own Dogfood”的本质是为了提高整合的效率，产品优先兼具一些平台的思路可能是更好的选择，大方向上必须是收敛的而不是相反。

I'm not saying it's too late for us, but the longer we wait, the closer we get to being Too Late.

我并不是在说，对我们来说已经太晚了。但我们拖得越久，离“真的太晚了”就越近。

I honestly don't know how to wrap this up. I've said pretty much everything I came here to say today. This post has been six years in the making. I'm sorry if I wasn't gentle enough, or if I misrepresented some product or team or person, or if we're actually doing LOTS of platform stuff and it just so happens that I and everyone I ever talk to has just never heard about it. I'm sorry.

老实讲，我也不知道该怎么给这篇东西收尾。我今天想说的话，基本都说完了。这篇长文酝酿了整整六年。如果我说得不够温和，或者我误解、误伤了某些产品、团队或个人，或者其实我们在平台方面已经做了很多工作，只是恰好我以及我接触到的所有人都从未听说过——那我在此提前道歉。

But we've gotta start doing this right.

但无论如何，我们得开始把这件事“做对”才行。

2011-10-11 Steve Yegge.Google Platforms Rant

2011-10-11 Steve Yegge.Google Platforms Rant

热门主题

Recent Articles

2011-10-11 Steve Yegge.Google Platforms Rant

2025-11-26 Ilya Sutskever.We're moving from the age of scaling to the age of research

2025-11-24 ChatGPT.Reward+Compression

2025-11-25 ChatGPT.评价Geico的商业模式

2025-11-23 ChatGPT.精准执行的能力层是原创性的假设