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.
我在亚马逊工作了大约六年半,现在在谷歌也差不多这么久。两家公司给我最初、而且几乎每天都在加深的印象是:亚马逊什么都做错了,谷歌什么都做对了。当然,这么说有点一刀切,但惊人地准确。真的挺疯狂的。你可以从一百甚至两百个角度去比较这两家公司,谷歌几乎在所有方面都更胜一筹,只有大概三个方面是亚马逊更好。我甚至做过一个对比表格,但法务部不让我给别人看,尽管招聘团队很喜欢它。
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.
比如说个小例子:亚马逊的招聘流程从根本上就有缺陷——是由各个团队自己来招人,所以招聘标准非常不一致,尽管公司也试图统一标准。他们的运维一团糟,基本没有 SRE(站点可靠性工程师),让工程师什么都干,几乎没有时间写代码——不过这也因组而异,全凭运气。他们对慈善、帮助弱势群体或社区贡献毫不关心,这些话题根本不会在公司出现,最多是被拿来当笑话。他们的办公环境是一堆脏兮兮的格子间,连一分钱都不愿意花在装饰或公共会议区上。薪酬和福利也很差,虽然近几年因为谷歌和 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.
我认为发布订阅系统和版本库系统就是亚马逊在总共三个比谷歌做得更好的方面中的两个。
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.
你也可以说他们“快速上线、疯狂迭代”的倾向是一种优势,但这个观点也可以反过来说。他们把尽快上线放在一切之上,包括用户留存、工程规范以及其他一些长期看很重要的东西。所以尽管这种策略在市场上带来了一些竞争优势,但它也造成了足够多的问题,使得这种优势难称完美无瑕。
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.
杰夫·贝索斯是出了名的微观管理者。他亲自管理亚马逊零售网站上的每一个像素。他曾经聘请了 Larry Tesler——苹果的首席科学家,也是全球最知名、最受尊敬的人机交互专家之一——然后整整三年里无视 Larry 所说的一切,直到 Larry 明智地选择离开公司。Larry 做了很多可用性研究,毫无疑问地证明用户根本无法理解那个混乱的网站界面,但贝索斯就是舍不得放手那些像素——那些着满语义的、无数像素堆起来的首页。在他眼里,每一个像素都是他珍贵的孩子。结果呢,那些像素还在,而 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.
顺便说一句,“微观管理”并不是亚马逊做得比我们好的第三件事。是的,他们确实很擅长微观管理,但我不会把它列为优势。我只是想帮你理解整个背景,明白发生了什么事。我们说的是一个在很多公开场合都认真地表示“人们应该付钱才能有资格在亚马逊工作”的人。他会发放印有自己名字的小黄纸条,提醒那些与他意见不合的人“谁才是公司老板”。这家伙简直就是……嗯,斯蒂夫·乔布斯吧?只不过没时尚感,也没有设计品味。别误会,贝索斯确实非常聪明,只不过他让普通的控制狂看起来像抽了大麻的嬉皮士。
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.
有一天,杰夫·贝索斯发布了一条指令。当然,他经常这么干,每次都让员工像被橡胶锤砸中的蚂蚁一样乱成一团。但在某次——我记得大概是在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、自定义协议——无所谓。贝索斯一点也不在意。
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.
不按此执行者,一律开除。
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.
哈哈!在场的一百五十多位亚马逊前员工当然会立刻意识到,第七条只是我开的小玩笑,因为贝索斯才不在乎你今天过得怎么样呢。
#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.
但第六条可是真的,所以大家都开始行动起来。贝索斯指派了几位“首席猛犬”来监督这项工作、确保推进顺利,带头的是“终极猛犬”Rick Dalzell。他是前陆军游骑兵,西点军校毕业,曾是拳击手,还担任过沃尔玛的“首席酷刑官/首席信息官”(CIO),是个又高大又和善、但令人畏惧的大块头,经常挂在嘴边的是“强化接口”这个词。实际上,他本人就是个行走的强化接口。所以不用说,大家都拼命推进工作,确保 Rick 随时知道他们的“进展”。
Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount while effecting this transformation. 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. Amazon's dev staff made a lot of discoveries along the way. A teeny tiny sampling of these discoveries included:
在接下来的几年里,亚马逊在内部完成了向面向服务架构(SOA)的转型。在这个过程中,他们学到了非常多的东西。尽管关于 SOA 的文档和传闻早已有之,但在亚马逊如此庞大的规模下,它们的实用价值就像是告诉印第安纳·琼斯过马路前要先看两边一样——几乎没什么帮助。亚马逊的开发团队一路上做出了许多发现。以下是他们发现中的冰山一角:
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.
寻呼升级变得更困难了,因为一个故障单可能要在二十个服务调用之间反复跳转,才能最终找到真正负责的团队。如果每次跳转都需要一个响应时间为15分钟的团队来处理,那么可能要几个小时后,问题才会到达正确的团队,除非你事先构建了大量的监控、指标体系和报告机制来支撑整个流程。
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)攻击者。在每个服务都设置严格的配额和限流机制之前,根本无法取得任何实质性的进展。
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 已经无法区分。二者形成了一个连续体。
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.
如果你有数百个服务,而且你的代码**必须**通过这些服务与其他团队的代码通信,那么如果没有服务发现机制,你根本找不到任何服务。而服务发现机制的前提是有服务注册机制,而这本身又是一个新的服务。因此,亚马逊建立了一个通用的服务注册中心,你可以通过程序方式反射式地了解每个服务的存在、其 API 接口,以及它目前是否可用、在哪里运行。
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.
这只是一个非常小的缩影。像这样的教训和经验,亚马逊是通过实际探索有机获得的,足有几十甚至上百条。关于服务外部化,还有很多稀奇古怪的问题,但可能并没有你想象中那么多。转向服务化架构教会了团队在大多数方面不要彼此信任,就像他们本来也不该轻易信任外部开发者一样。

让每个模块更加独立(每个模块都能“吃自己的饭”)有助于整合,并提升整个系统的效率。
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年中离开去谷歌时,这项工作仍在继续,但已经取得了相当大的进展。从贝索斯发布命令那一刻起,到我离开的那一天,亚马逊在文化上已经转型成一家“服务优先”的公司。现在,这种思维方式已经成为他们设计一切事物的基本方式,包括那些可能永远不会对外发布的内部系统。
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. 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 的设计能够孕育出“平台”。
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.
贝索斯发布那个命令,当然就是为了这个。他完全不在意各个团队的幸福感、不在意他们使用什么技术、甚至对他们如何开展业务的细节也毫无兴趣——除非他们哪儿搞砸了。但贝索斯比绝大多数亚马逊员工早得多地意识到,亚马逊需要成为一个“平台”。

人类和鸡的关系。
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.
但贝索斯首先意识到的一件大事就是,他们为销售和配送书籍与杂项产品所构建的基础设施,其实可以被转化为一个极其出色、可重用的计算平台。所以现在他们有了 Amazon Elastic Compute Cloud(EC2)、Amazon Elastic MapReduce、Amazon Relational Database Service(RDS),还有一大堆其他可以在 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.
贝索斯的另一个重大领悟是:他不可能总是做出“正确的产品”。我想,当拉里·特斯勒说他妈妈都用不了那该死的网站时,这也许在贝索斯心中触发了一些什么。其实我们也搞不清楚他说的是谁的妈妈——但这根本不重要,因为没有哪个妈妈能顺利使用那该死的网站。事实上,连我自己都觉得那个网站令人不安地让人望而生畏,而我可是在那里干了五年多。我只好学会让眼睛稍微虚焦,然后专注于网页上方可见区域中心的那一百万个像素左右。
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.
我不太确定贝索斯是如何意识到这个问题的——也就是他无法打造出一个“适用于所有人”的单一产品。但这并不重要,关键是他明白了。事实上,这种现象有一个正式的名字,叫做“可及性(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.
如果你现在在想,“啊?你是说那种‘盲人和聋人也能用’的可及性?”那么你并不孤单,因为我慢慢意识到,有很多很多人和你一样:他们无法接收到这个概念,是因为这个理念本身对他们而言缺乏“可及性”。你没理解不是你的错,就像你不是故意失明、失聪、行动不便或患有其他残疾一样。当软件——或者说是“思想产品”——因为任何原因而无法为某些人所用,那就是这个软件或这个思想的传达方式失败了。这是一种“可及性失败”。
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.
就像生活中所有伟大且重要的事情一样,“可及性”也有一个邪恶的孪生兄弟——由于童年时期父母偏心的冷落而走向极端,最终成长为一个同样强大的死对头(没错,“可及性”有不止一个死敌),那就是:**安全性(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.
但我想说,“可及性”实际上比“安全性”更重要,因为如果你把可及性调成零,那你根本就没有产品可言;而如果你把安全性调成零,你还是有可能获得一个相当成功的产品,比如 PlayStation Network。
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.
谷歌真正做不好的那件事就是“平台”。我们不理解平台。我们“get 不到”平台。你们当中有些人明白,但你们是少数。这一点,在过去六年里对我变得痛彻心扉。我本来希望来自微软、亚马逊,甚至最近来自 Facebook 的竞争压力,能够让我们整体觉醒,开始构建通用服务。不是那种临时拼凑、敷衍了事的方式,而是像亚马逊那样:一次性、动真格、没有作弊,把它当成我们的头号优先事项。
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(谷歌内部 RPC 框架)服务以便程序化访问他们的数据和计算内容,这都已经是个巨大的挑战。因为他们中的大多数都认为自己是在构建“产品”。而 stubby 服务嘛,其实是个挺可怜的服务。你回头看看亚马逊总结的那一小部分经验清单,告诉我 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+ 就是我们从高层领导(嗨 Larry、Sergey、Eric、Vic,你们好啊)到最基层员工(嘿 yo)整体对“平台”完全理解失败的典型例子。我们根本没 get 到。平台的金科玉律是:**自己吃自己的狗粮(Eat Your Own Dogfood)**。而 Google+ 的“平台”只是个可怜兮兮的事后补丁。上线时连 API 都没有,后来我去查了一下,好像只有一个 API 调用。那时有个团队成员跑来跟我说他们终于上线了 API,我就问她:“所以这是个‘跟踪者 API’?”她垮下脸说:“是的。”我当时是在开玩笑,但不……我们唯一提供的 API 调用,就是用来获取某人的动态流。所以最终被开玩笑的,是我自己。
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.
微软至少在二十年前就知道“狗粮规则”了。这已经是他们整整一代工程文化的一部分了。你不能自己吃人吃的食物,然后把“狗粮”扔给开发者。那等于是牺牲了你平台的长期价值去换取短期的成绩。而平台——本质上——就是一种**长期思维**。
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 都是不同的。有些人整天泡在 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.
对于你们当中那些觉得我说的这些东西太显而易见的人,我表示歉意。因为……确实,这些道理真是显而易见得要命。除了,我们**自己并没有在做这些事**。我们没搞懂“平台”,也没搞懂“可及性”。但这两个概念其实是一码事,因为**平台本身就是解决可及性问题的方案**。**一个平台,就是一种可及性**。
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.
所以,是的,**微软是懂的**。而你我都知道,这个事实多么令人惊讶,因为他们其实并不怎么“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.
亚马逊也懂。他们的 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.
苹果当然也是懂的。他们在某些方面,尤其是移动平台上,做出了一些**根本不开放**的选择。但他们理解“可及性”,也理解第三方开发的力量,而且他们自己吃自己做的“狗粮”。你知道吗?他们做的“狗粮”还真的挺好吃的。他们的 API 清晰得多,比微软的干净得多,而且几乎自古以来就是如此。

洞察力的体现。
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 懂得这一点。这才是真正让我担忧的地方。这才是让我从懒散状态中爬起来写下这篇文章的原因。我讨厌写博客。我也讨厌……“plussing”,或者不管你怎么称呼在 Google+ 上发一通又臭又长的牢骚——尽管那是个糟糕的发布平台,但你还是发了,因为归根结底你真的希望 Google 成功。而我确实希望如此!我是说,Facebook 很想要我加入,而且过去去那儿也挺容易的。但 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.
请不要误会我的意思——我很清楚,开发者关系团队为了让这些对外开放的资源上线,已经付出了巨大的努力。他们的表现非常棒,因为他们**确实理解平台的意义**,而且他们正英勇地试图在一个最多只是对平台“冷漠”、但通常对这个概念是公开敌视的环境中,建立起真正的平台。
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.
我只是在坦率地描述 outsiders 看 developers.google.com 时的感受。它看起来很幼稚。拜托,Maps API 到底在哪?有些内容还是实验室项目。我点开的每个 API……都显得很寒酸。显然是“狗粮”。还是那种劣质狗粮。跟我们内部使用的 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 也在朝这个方向尝试。但他们很难拿到资源支持,因为这不符合我们的文化。Maestro 项目的资源相比 Microsoft Office 的宏编程平台简直是小巫见大巫:一个绒毛兔子对战一只霸王龙。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 曾是一个很棒的平台,愿它安息。但仅仅把某样东西做成平台**并不会立刻带来成功**。一个平台需要一个“杀手级应用”。Facebook——即他们那套包含墙、朋友等功能的标准服务——就是 Facebook 平台的“杀手级应用”。而如果有人认为没有 Facebook 平台的支撑,Facebook 应用本身还能如此成功,那就是个非常严重的误判。
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% 无傲慢”的公司。我在这篇文章开头——如果你还能回忆起最初那段——就说过 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. 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.
于是我们搞出了一个浏览器,**竟然不能设置默认字体大小**。这简直是对可访问性(Accessibility)的侮辱。我是说,随着年龄增长,我真的快瞎了。真的。我一辈子都近视,而一旦你年过四十,就看不清近处的东西。所以字体选择就成了关乎生死的问题:字体不对等于完全无法使用这个产品。但 Chrome 团队在这方面简直就是傲慢到了极点:他们想要构建一个“零配置”产品,而且对此毫不掩饰,完全是一副“你瞎了、聋了之类的关我屁事”的态度。你以后每打开一个页面,就自己按 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.
这不仅仅是他们的问题,而是我们所有人的问题。我们彻头彻尾就是一家**产品公司**。我们靠一个广受欢迎的成功产品——也就是搜索——起家,而这种爆炸性的成功让我们形成了**偏见**。
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?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.
我们面临的问题非常严重,因为我们必须经历一次**剧烈的文化变革**才能迎头赶上。我们内部没有做面向服务的平台,外部也没有。这意味着“不懂平台”已经是全公司的普遍现象:产品经理不懂,工程师不懂,产品团队不懂,谁都不懂。哪怕有些人懂,哪怕**你**懂,只要我们没有把这件事当成“全员警报”的紧急任务,那就毫无意义。我们不能再继续推出一堆产品,然后自欺欺人地假设以后能把它们魔法般地转变为美丽且可扩展的平台。我们试过了——这条路**行不通**。
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 做平台化的人。如果你拖延,后面就要付出**十倍的努力**去补救。你不能作弊。你不能给内部应用留后门,让它们获得特殊的优先访问权限,**无论理由多么正当**。你必须一开始就把难题解决掉。
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.
但我们**必须开始正确地做这件事**了。