亚马逊什么都做错了，谷歌什么都做对了

（图片来源：摄图网）

作者|icefighter  来源|天玑情报局（ID：qiqilibrary）

今天的文章标题很吸引人，对吧？

其实这是一个在亚马逊和谷歌都任职多年的内部人士说的原话。

“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.”

过去，我们经常说，很多行业专家和公司内部人士更喜欢拿着“放大镜”看公司和行业的缺陷。

因此他们往往是灯下黑，不投资自己熟悉的行业和公司，喜欢投资别的行业和公司。

那么是否外行投资更有优势呢？

那也不一定。

外行过于关注诗和远方，忽略了至关重要的细节，把一个行业和公司想的太美好，最后惨遭暴雷。

如何平衡“望远镜”和“放大镜”？

这是投资时始终要面临的一个难题。

说出标题中这番让人震惊的话的人叫做 Steve Yegge。

我们来看一下他的简历。

根据Wikipedia百科资料，他是著名的计算机专家和博主blogger。

从1998年到2005年，他在亚马逊公司担任Senior Manager of Software Development，从2005年到2018年，他在谷歌担任Senior Staff Software Engineer 。

他离开谷歌时，电视台CNBC采访他，问他离职原因，他说谷歌过于保守，已经不再有创新no longer innovative。

下面我就摘录他的文章中比较有意思的精华部分。

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.

亚马逊的特色之一是launching early and iterating like mad。

也就是说，他们的企业文化把先发优势作为第一目标，prioritize launching early over everything else。

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 Tesler在亚马逊工作三年期间提出的关于亚马逊网站的每个建议，贝索斯都否决了，最后Larry Tesler被迫辞职。

亚马逊网站首页还是保持原样，贝索斯就像自己的孩子一样对待亚马逊网站页面。

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.

贝索斯就像是苹果的乔布斯，一样都是控制狂，除了缺乏乔布斯的时尚和设计感觉。

当然，贝索斯也是顶级聪明的。

他喜欢在公司内部发布各种强制性的要求和规范。

下面是2001年前后他发布的非常出名的一个要求：

图片

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:

接下来的几年，亚马逊把自己打造出了service oriented的架构。

对于如何打造这样的架构，他们获得了很多独特的发现。

下面是一些发现的示例。

这些发现涉及DOS攻击，配额，限流，监控和QA，服务发现，服务注册，调试沙箱等。

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.

一个ticket在找到真正的owner之前可能要来回传递20次服务调用。如果每次踢皮球花费相关团队15分钟的反应时间，那么在把这个ticket踢到正确的团队之前，已经浪费了数个小时时间。

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是一回事。当你的服务说，”oh yes, I’m fine”的时候，你知道这个服务可用了吗？

也许只有说这句话的那个组件是有用的，其它组件却失效了。

只有当你全面的检测你的所有业务和数据，你才能确信服务的可用性。

所以监控和自动化的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.

如果你有数百个服务，如果没有服务发现机制，你没有办法发现所有服务。

如果要做到服务发现机制，你要有统一的服务注册机制。

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.

调试代码也会成为问题，需要一个统一的沙盒调试器。

Organizing into services taught teams not to trust each other in most of the same ways they’re not supposed to trust external developers.

面向服务的架构让亚马逊学到了一个经验教训，不要相信外部的第三方开发者，也不要相信亚马逊内部的其它人。

（icefighter说明，前面列举的几条经验教训告诉我们，公司内部的开发者不能特殊对待。所以这段话和前面列举的几条发现之间是有逻辑关系的。）

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面向服务架构是平台必须的。

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.

贝索斯在很多人明白之前已经明白，亚马逊需要成为面对外界提供服务的云计算平台。

The other big realization he had was that he can’t always build the right thing.

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.

The. Most. Important. Thing.

贝索斯另外一个重要的发现是他无法打造一个适用于所有人的产品。

软件最重要的是用户友好性(Accessibility)。

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.

谷歌做的最不好的地方是平台化。

谷歌内部的人大部分不懂平台化。

谷歌需要向亚马逊学习，把平台化作为首要目标。

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.

Google Plus这个产品证明了，谷歌从最高层到最底层都不懂平台化。

平台的黄金标准是you Eat Your Own Dogfood，你吃自己做的狗粮。

Google PLus上市时，没有提供任何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.

微软已经懂得狗粮定律至少超过20年。

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.

贝索斯意识到，他无需成为乔布斯，以便为所有人提供适合的产品。

亚马逊只需要提供第三方接口。

第三方开发者会提供客户需要的产品。

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.

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.

谷歌不懂平台，也不懂可用性accessibility。两者是一回事，因为平台提供可用性。

微软做操作系统30年了，所以微软很多事情不懂，但是懂平台。

去微软的网站msdn.com看看API接口的资料就明白了。

亚马逊也懂平台，去aws.amazon.com看看就明白了。

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 APIs在哪里？

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 flatout 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岁，视力就开始不好，对这样的人来说，字体大小设置变成了生死攸关的事情。

谷歌浏览器团队却想开发一款零配置的产品。

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.

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

谷歌一直是产品型公司，谷歌的搜索产品太成功，以至于让自己有了偏见。

亚马逊开始也是产品型公司（他的电商业务是产品），但是贝索斯意识到需要平台化。

微软一开始就是平台公司。

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.

吃你自己的狗粮，意思是说，开发一个平台，然后用它做任何事情。

必须一开始就平台化，否则越拖延，你的工作量就会增加10倍。

你不能给内部开发者留下秘密的后门，获得特殊的权限。

你必须一开始就做最难的事情（一开始就设计好平台化）。

我们总结一下，这篇文章主要面向谷歌内部人员，所以它会让我们更加深刻的了解软件行业的一些秘密。

例如这篇文章很好的阐释了产品型软件公司和平台型软件公司的区别。

真正的平台型软件公司是怎么样的？

就是Eat Your Own Dogfood，一开始就要设计好平台，然后用这个平台做任何事情，自己内部员工用这个平台，外部客户和第三方开发者用这个平台，内部外部一视同仁。

为什么内部外部要一视同仁呢？

文章里有列举了亚马逊开发平台SOA架构时的小部分经验教训。

其中包括内部开发者也可能踢皮球，也可能发起DOS攻击等。

所以，开发平台时不能相信外部的第三方开发者，也不能相信平台内部的其它开发人员，必须要做好对应的预防工作（配额，限流等）。

在看完这篇文章之前，我对微软，谷歌，亚马逊的认识可能没有这么深刻。

我会认为微软是操作系统公司，谷歌是搜索引擎，而亚马逊是电商。

但是，其实他们三者的基因是不同的。

操作系统天生就是平台。

而搜索引擎和电商只是产品。

当然这些产品后来也可以扩展功能成为平台，但是他们的性质和操作系统的平台性还是有天壤之别。

看了这篇文章，以后研究软件公司的投资基本面时，我就会从更多的维度思考问题。

譬如我之前研究酒店行业SAAS，提到了oracle和石基信息的酒店PMS软件的区别。

酒店管理SAAS软件未来是怎样的？

从全球酒店巨头最新IT战略看石基信息的投资价值

GE解体了，多元化公司都不值得投资了？

oracle的云PMS号称提供了业界最多的API接口，数量达到3000多条。

石基信息的API接口数量不详。

但我可以判断一点，石基信息想打造一站式封闭系统，自己一个人全部搞定。

那么这其实是今天文章说的产品型思维。

而oracle则是平台型思维。

这两种思维有高低之分吗？

那倒没有，但是这两种思维是截然不同的。

而且，前面文中提到，相同条件下，平台型产品可以替代非平台型产品。

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.

那么，oracle和石基信息的酒店PMS产品，石基信息号称自己云原生，这点强于oracle，但是平台化方面，哪个更强呢？

所以，这个行业的研究难度是很大的。我把它列为“七英尺栏”而不是“一英尺栏”。

聪明的你可能有最后一个疑问，标题和文章内容似乎不符啊？

文章说的都是亚马逊做对了，谷歌做错了，为什么标题的意思相反呢？

其实， Steve Yegge说的这个话算是反话。

他认为亚马逊的软件开发能力和公司管理制度很烂，远远比不上谷歌。

但是亚马逊做对了一件事，平台化。

谷歌的软件开发能力和公司管理制度比亚马逊强多了，开发的很多产品其实方向也是对的，但是为什么搞砸了？

因为缺乏平台化思维。

当然，2005年谷歌收购了移动操作系统安卓。而安卓天然是平台化产品。

所以，现在的谷歌应该已经具备平台化思维了。

最后这一点也给我们一个启发，有时候不要过于相信行业专家和公司内部人士的话。

他们可能看到了太多细节缺陷，例如亚马逊的软件开发能力和管理制度很差，因此看空亚马逊。

但是他们忽略了主要矛盾，亚马逊的平台化思维才是它最强的地方。

所以不要一叶障目，再好的公司用放大镜看都有很多缺点。

编者按：本文转载自微信公众号：天玑情报局（ID：qiqilibrary），作者：icefighter