转：SteveY对Amazon和Google平台的长篇大论
Steve Yegge， Amazon的前員工，現任Google員工，其本來想在Google+上和Google的員工討論一些關于平臺的東西，結果不小心把圈子設成了Public，結果這篇文章就公開給了全世界，引起了劇烈的反應。發布后很快他就馬上把這篇文章刪了，不過，互聯網上早備份了下來——SteveY’s Google Platforms Rant。后來，Steve在其Google+上作了一些解釋，大體是說他喝多了，而且又是在凌晨，所以大腦不清，文章中的觀點很主觀，極端且不完整，還有Google的PR對他很好，等等，等等 。
幾個星期前看到時就一直都想翻譯一下這篇文章，不過因為最近事情太多，文章又很長，所以現在才翻譯完成，翻譯的不好，還請大家指正。
導讀
在你閱讀正文以前，我想說明幾點，希望你注意一下：
- Steve這個人非常喜歡寫長篇大論的東西。而且比較喜歡辛辣調侃和惡搞的文風，這點大家要注意！
- 文中先“罵”Amazon公司，再通過“罵”Amazon的創始人貝索斯Bezos并烘托出他的的悟性和雄心，最后教育了一下Google。
- 我把文章分成了三個部分，這樣方便大家閱讀和討論。第一部分只是個人情緒化的抱怨，第二部分是說Amazon的成長，第三部分是教育Google，我覺得第二部和第三部分是重點。
- 對于我們來說，我們應該獲取Steve那些關于平臺（Platform）相關的那些有價值的觀點。尤其是他說的Amazon如何進化成一個平臺性的公司，以及闡述Google應該怎么做的那些觀點。
- 關于對Amazon的那些指責，我想說，6年，對于一個世界級的互聯網公司，已經很不一樣了。
正文
第一部分
我曾在Amazon工作了六年半，現在，我在Google的日子也差沒不多這么長了。對于這兩家公司，有一件事總是縈繞著我——這種感覺一天比一天強烈──那就是，Amazon每件事都做錯了，而Google每件事都做對了。當然啦，這是很籠統的話，但卻是驚人的準確，相當的瘋狂吧。大概有一百甚至兩百種不同的地方可以讓我們去比較這兩個公司，而Google可能在每一項都能勝出，如果我記的沒錯，除了其中3項以外。因為，我曾用電子表格把這些項都列出來了，只是法務部門不會讓我給任何人看，即使人事招募部門很喜歡這個報表。
?
這里，讓我先給你個例子讓你稍微體會一下：Amazon的人事雇用流程有根本上的缺陷，因為各個團隊各招各的人，以至于，各團隊之間的招聘標準相當的不一致性，即使他們通過各種努力來統一標準，但是實際操作上卻是一團糟；他們沒有真正的SRE（陳皓注：Site Reliability Engineer?），工程師們什么事都要做（陳皓注：所謂SDE – Someone Do Everything）、幾乎沒時間編碼。當然，不同的部門有不同的情形，不過，這取決于你的運氣。他們不搞慈善，也不幫扶貧困人群，也不搞社區貢獻，或是其它相似的活動。在那里，他們從來不談這些，或許只有在說笑話的時候才會提到。他們的辦公環境是個灰塵及污跡四處的像農場一樣的隔間，他們在公共區域連一分錢裝修的都不會花，而且，他們的薪水和福利相當差，只是近來與Google和Facebook競爭人才，這個差距才變得非常地小。不過，他們沒有我們有的津貼或額外獎金——他們只是給你錄用信上的那個數字，就這么多。他們的程序代碼完全就是災難，無論什么都沒有任何的工程標準，除了各別團隊有一些。
公平起見，他們的確有套非常非常不錯的版本控制管理系統，而這是我們（Google）需要盡力趕上他們的地方，他們還有一個漂亮的發布/訂閱系統，我們也沒有相對應的東西。不過，就大體而言，他們有的不過是一堆蹩腳的工具，用關系數據庫來讀取或寫入狀態機里的信息中罷了。我們不應該這么搞就算這樣做是可以。
這就是我所所說的那3件事中的兩件事Amazon比Google強的，那就是的他們的發布/訂閱系統以及版本控制和管理系統。
我猜你也許會為他們爭辯到——他們要更快更早地推出服務并通過狂熱地迭代來不斷地改進和完善。他們把服務發布的優先級看得比任何事都重，包括工程紀律或是其它一堆可能會讓其花時間的事務。所以，即使這么做讓他們在市場上有了某種程度的競爭優勢，但也造成其他足夠多的問題，總之，這樣的做法算不上是個漂亮的扣籃。
但是，他們有一件事做的非常非常好，其好到可以把其他政治，理念，技術上的消耗和混亂完全彌補回來。
第二部分
Jeff Bezos是個臭名昭彰的微管理經理人，他的微管理都管理到了Amazon零售網站上的每一個顯示像素。他雇傭了Larry Tesler——Apple的首席科學家，他可能是全世界最有名也最受尊敬的人機交互接口專家，然而，Bezos忽略了Larry三年來提出的每一個建議，直到Larry最后——明智地——終于離開了公司。Larry本應做一些大型可用性（Usability）研究，并可以系統地了解那個根本就沒有人能夠搞懂、使用那該死的網站，可是，Bezos對于那些像素不放手，這些頁面上的那幾百萬個顯示像素就像是他的孩子一樣。所以，他的這些孩子還留著，而Larry沒有。
當然，微管理不是第3項Amazon做的比我們好的事。我的意思是，沒錯，他們微控管理做地非常地好，但我不會把這項列在他們的強項清單上。我這樣說只不過是為了我下文做鋪墊，幫助你了解我后面要說的事兒。我們現在要說的這個人，是在多個嚴肅的公開場合說要來Amazon工作就應該付他錢才對的人。當有人跟他意見不同時，他會遞出寫有他名字的黃色即時貼以提醒那個人“誰是公司的老大”。這家伙是……，Steve Jobs，我想，除了沒有品味和設計能力，他們很相似。千萬別誤解我，Bezos是個絕頂聰明的人，只不過他把那些正常的管控搞得像嗑了藥的嬉皮士一樣罷了。
所以，有一天，Jeff Bezos下了一份命令。當然，他總是這么干，這些命令對人們的影響來說就像用橡皮槌敲擊螞蟻一樣。這個命令大概是2002年，我想誤差應該是在正負1年內 —— 這個命令發布的范圍非常地廣，設想很大，讓人眼珠子鼓出來的那種，這種驚訝程度和其他的命令相比，就好像你突然收到公司給你的獎金一樣讓人驚訝。
這份大命令大概有如下幾個要點：（陳皓注：這里是本篇文章的要點！如果這真是Bezos發出來的，那么太贊了，Bezos完全就是一個系統架構大師啊，那可是2002年左右啊。作者調侃Bezos完全是正話反說啊）
- 1) 所有團隊的程序模塊都要以通過Service Interface 方式將其數據與功能開放出來。（陳皓注：Service Interface也就是Web Service）
- 2) 團隊間的程序模塊的信息通信，都要通過這些接口。
- 3) 除此之外沒有其它的通信方式。其他形式一概不允許：不能使用直接鏈結程序、不能直接讀取其他團隊的數據庫、不能使用共享內存模式、不能使用別人模塊的后門、等等，等等，唯一允許的通信方式只能是能過調用 Service Interface。
- 4) 任何技術都可以使用。比如：HTTP、Corba、Pubsub、自定義的網絡協議、等等，都可以，Bezos不管這些。（陳皓注：Bezos不是微控經理嗎？呵呵。）
- 5) 所有的Service Interface，毫無例外，都必須從骨子里到表面上設計成能對外界開放的。也就是說，團隊必須做好規劃與設計，以便未來把接口開放給全世界的程序員，沒有任何例外。
- 6) 不這樣的做的人會被炒魷魚。
- 7) 謝謝，祝你有個愉快的一天！
哈哈！你們這150個前Amazon的員工，當然能馬上看出第7點是我開玩笑加上的，因為Bezos絕不會關心你的每一天。
不過第6點是很真實的，于是，所以人們都去工作。Bezos并派出了幾位首席牛頭犬來監督并確保進度，領頭的是和熊一樣大的牛頭犬：Rick Dalzell，Rick是以前是陸軍突擊隊隊員，西點軍校畢業生，拳擊手，和沃爾瑪的首席虐刑官 / CIO，而且他也是個高大、和藹、令人敬畏的人，還是經常使用”hardened interface”詞的人，Rick 本來的走路和說話都比較hardened interface，所以不用多說，每個人都得干 出有重大的進展，這樣Rick才能看得見。
在接下來的幾年，Amazon內部轉變成面向服務架構SOA(Service-Oriented Architecture)，在這華麗轉身的過程中，他們學到了相當巨多巨多的東西。我在的那個時候，世界上就有很多很多的關于SOA的學術文檔，但在Amazon的那種超大規模的面前，世間的這些文檔就好像告訴印第安納瓊斯（陳皓注：電影奪寶奇兵男主角）過馬路前要先看看兩邊有沒有來車一樣沒用，Amazon的研發工程師們在這個過程中發現了很多很多的問題，并從中學到了很多。下面只是他們這些問題中的滄海一粟：
- pager escalation（陳皓注：生產線上問題的尋呼系統）變得比較困難，因為ticket可能會轉過來轉過去（陳皓注：ticket就是處理問題的工單），只到轉了20次，都找到真正能解決問題的團隊和人。如果每一個呼叫都花去團隊的15分鐘的響應時間，那在找到真正的團隊之前，幾小時就已經過去了，除非，你能建造出很多很多的腳手架，測量標準和報告。
- 每一個和你的相關團隊突然間都可能成為一個潛在性的DOS攻擊者。沒人可以讓事情有進展，直到在每一個Service里放上配額（quota）與節流閥（throttling）的機制。
- 監控與QA是被統一了。如果你不進行一個大規模的SOA，你就不會這么去想。但是，等到你的Service說，“是的，我還好！”，但實際情況可能是，服務器里唯一能正常運作的功能就是一個快樂的機器聲音在呼叫你：“我很好，收到，收到”。為了要確認整個服務能正常運作，你需要對Service的每一個部分都去Call一下。這個問題會以遞歸的形式地出現，直到你的監控系統能夠全面性地系統地檢查所有的Services和數據，此時，監控系統就跟自動化測試QA沒什么兩樣了，所以兩者完美的統一了。
- 如果你有上百個Services，而且你的程序只能通過由這些Services來跟其他團隊的程序做溝通，那么，沒有一套Service發現機制的話，你就不能找到這些Service。所以，你得先有一套Service的注冊機制，這也是一個Service。所以，Amazon有一套全體適用的Service注冊機制，以例可以通過反射機制來找到Service，并知道Service的API，以及是否可用，在哪兒。
- 調試其他人的代碼以調查問題變得非常的難，幾乎都不可能，除非有一套全面性的標準的方式，他可以在可被調試的沙盒里運行所有的Services。
當我在2005年中期離開Amazon加入Google時，這個努力進化的過程還在進行時中，但那時已經相當的先進了。從Bezos頒布法令的時間到我離開的時候，Amazon已經把文化轉變成了“一切以Service第一”為系統架構的公司，今天，這已經成為他們進行所有設計時的基礎，包括那些絕不會被外界所知的僅在內部使用的功能。
那時，如果沒有被解雇的的恐懼他們一定不會去做。我是說，他們今天仍然怕被解雇，因為這基本上是那兒每天的生活，為那恐怖的海盜頭子Bezos工作。不過，他們這么做的確是因為他們已經相信Service這就是正確的方向。他們對于SOA的優點和缺點沒有疑問，某些缺點還很大，也不疑問。但總的來說，這是正確的，因為，SOA驅動出來的設計會產生出平臺（Platform）。
是的，這就是Bezos的法令要達成的目標。他以前（現在也是）一點不關心各團隊是否好，也不關心他們使用什么樣的技術，實際也不去管他們如何運作他們的業務，除非團隊開始把事搞砸。但是，Bezos比絕大多數的亞馬遜人都很早很早就領悟到，Amazon必須成為一個平臺。
如果是你，你會想到要把一個在線賣書的網站設計成為一個有擴展性，可程序化的平臺？你真的會這樣想嗎？
嗯，第一件Bezos領悟到的大事是，為了銷售書籍和各種商品需要的基礎架構，這個基礎架構可以被轉變成為絕佳計算平臺（Computing Platform）。所以，現在他們有了Amazon Elastic Compute Cloud（亞馬遜彈性運算云平臺EC2），Amazon Elastic MapReduce，Amazon Relational Database Service（亞馬遜關系數據庫服務），以及其他可到AWS?aws.amazon.com查得到的一堆Service。這些服務是某些相當成功的公司的后臺架構，比如 我個人喜歡的 reddit 是這一堆成功公司的其中一個。
另一大領悟是，他知道他們不可能永遠都創造出對的東西。我認為，當Larry Tesler說他媽媽完全搞不懂怎么使用那個該死的網站時，Bezos的某根筋被觸動了，當然，我也不清楚到底是誰家母親，這無關緊要，因為沒有人的母親能夠會用那個該死的網站。事實上，連我這個在那工作超過5年的人都覺得Amazon網站的接口令人膽戰驚心。
我并不是很確定Bezos是如何領悟到的——領悟到他不能創造 出一個產品能適用于所有的人。不過，怎么來的這不重要，重要的是他的確領悟了。這種事有一個正式的術語，叫Accessibility，這是計算機世界中最最重要的事情了。
最！重！要！的！事！
如果你在心里面在想“哼？你是說，像盲人和聾人那種Accessibility嗎？”，那么，你不是唯一這樣想的人，因為我已經知道有很多很多像你這樣的人：這種東西對你們這種人來說是不可能有正確的Accessibility，所以這事你還不能理解。當然，不能理解也不是你的錯，就像眼盲，耳聾，或是其他行動不便的殘疾人，這些也不是他們的錯。當Software——或ideal-ware——如果因為某些原因不能被存取或使用，那么，這就是軟件或是那想法的錯了。這就是Accessibility failure。
就如同生命中那些重大的事一樣， 每個事都有一個邪惡的雙胞胎姊妹，它在幼年都受到父母的溺愛，現在它已經成長為同等強大的復仇女神（是的，Accessibility有不只一個復仇女神），這個復仇女神叫安全性（Security），他們在一起總是爭執不休，冤家一對。
不過，我會和你爭論Accessibility要比安全性來的重要多了，因為零Accessibility就意為著你根本沒有做出產品來，而如果安全性為零，你仍然還是可以有一個某個程度上成功的產品，譬如說Playstation Network。
對了，也許你還沒注意到，我其實可以為這篇文章寫出一整本書，很厚的一本，其中填滿了那家我曾工作過的公司里關于螞蟻與橡皮槌的事。但是，我可能也就永遠無法在這發表這短篇的夸夸其談了，而你也就無法讀到除非我現在開始結尾。
第三部分
那三件Amazon比Google強的中的最后一件事是，Google很不會做平臺（Platform）。我們就不懂什么是平臺。我們就根本不知道平臺的內涵。你們其中一些人明白，但是你們是少數派。在Google過去這六年來，越清楚這一點就越讓我痛苦。我曾有一線希望，來自Microsoft和Amazon，以及近來Facebook的競爭壓力，會讓我們全體人都清醒過來，并開始打造我們公司的Service。不是那種特制的或半生不熟的，而是多少和Amazon的類似的那種：一次到位，真正的，沒有作弊或是欺騙，并且把它放在最高優先級的位置。
但實際上卻不是，這個事被放在了好像是第10還是第11位，或是第15位，我不知道，反正是相當低。只有少數幾個團隊嚴肅地看待這個事，但大多數的團隊不是從沒有思考過這個事，就是只有一很少的人很鼠目寸光地在看待這個事。
對大多數的團隊來說，只要是讓他們以提供給別人那種可程序化的方式存取他們的數據與運算的方式來開發軟件，就算幾個小小的粗糙的Service，對他們來說也是翻天覆地。他們大部分人都認為他們在做產品，但他們只是在提供那些凄慘粗糙的Service。回去看看前面我所列的那些部分的Amazon學到的東西，然后告訴我，哪一個粗糙的Service能讓你有超凡脫俗的產品。迄今為止，就我所知，一個也沒有。就算是這些粗糙的東西很不錯，不過這就好像要汽車的時候，你卻只有汽車的零件。
沒有平臺的產品是沒用的，再精確一點，去平臺化的產品總是被平臺化的產品所取代。
Google+是我們完全失敗的不懂Platform最明顯的例子，從最高層的管理層（嗨，Larry、Sergey、Eric、Vic，你們好）一直到最最底層的員工（嘿，你）都不懂。我們全部統統都不懂。平臺Platform的黃金守則是Eat Your Own Dogfood（吃你自己的狗食——自己都要用自己的平臺）。Google+這個平臺是個杯具的事后抄襲者。我們在發布它的時候完全沒有任何API。我查了一下，目前也只有少得可憐的API。Google+的一個團隊的成員在發布API時告訴我這個事，我問：“這是Stalker API（用來偷窺內部數據的API）嗎？”，她郁悶地說，“是啊”。我的意思是，我那只是個玩笑話，但是，不，我們提供的唯一的API就是取得某人的信息流，所以，我想我把玩笑開到自己頭上了。
Microsoft知道“狗食守則”至少有20年了。這已經成為他們世世代代文化的一部分了。不能是你吃人類的食物而給你的開發人員們喂狗食。那樣做只會是為了短期的成功而掠奪了平臺長期價值。平臺就是要你考慮得長遠。
Google+就像膝跳反射，一種短視的的東西，是基于以為Facebook其偉大產品的成功作出的錯誤判斷。但那不是為什么他們能成功的東西。Facebook的成功是因為他們建立了一個可以讓外界在其上上面開發的產品群。所以對Facebook對每個人來都不一樣。有些人把全部時間花在“Mafia Wars”上，有些人則是花在“Farmville”（開心農場）。那里還有成百上千個不同的高質量的時間消耗類的游戲，所以，人們總是可以在那里找到他們想要的。
我們的Google+團隊看了看說：“哎呀，看來我們需要一些游戲，讓我們去找一些人來為我們寫些游戲吧”。你是否開始看到這樣的的思考有多么不靠譜了嗎？問題在于我們試圖在預測人們想要什么，然后推出產品給他們。
你不能這么做。真的不能。也不可靠。在這個世上，甚至在整個計算機的歷史上，只有極少數幾個人能夠這么干，Steve Jobs是其中一個。但是我們沒有Steve Jobs。對不起，我們真的沒有。
Larry Tesler有可能說服了Bezos相信他并不是Steve Jobs，但Bezos意識到他不需要成為Steve Jobs也能提供給所有人好的產品：大家感到容易使用的接口與工作流。Bezos明白他只要有讓第三方開發人員來做的平臺，這些東西自然就會有的。
我要向一些人道歉，這些人會覺得我所說的是再明顯不過的了。是的，的確是巨明顯的。只是我們沒有去做。我們沒有領會平臺，我們也無法領會到Accessibility。這兩者本來就是同一件事，因為平臺會解決Accessibility。而平臺就是Accessibility。
- 是的，Microsoft領會到了。而且你們也像我一樣知道Microsoft他們對這些東西一知半解。那是因為他們能夠了解平臺完全是他們商業上意外性的副產品，是他們一開始的業務就是提供平臺。所以他們在這個領域有著三十多年的經驗。如果你去看看?msdn.com，并多花點時間瀏覽一下，假設你以前從沒去看過，你等著被嚇到吧，因為那里面的東西可是多得不能再多。他們擁有成千成千成千個API。他們擁有一個超巨大的平臺。說實話，太巨大了，因為他們要霸占一切，但至少他們做了。
- Amazon也領會了到了。Amazon的AWS(aws.amazon.com)相當的驚人。去看看吧，四處點一下。令人羞恥吧。我們今天什么都還沒有。
- 很明顯Apple也領會到了。他們做了在基礎上不開放的選擇，具體來說是移動平臺。但是他們明白什么是Accessibility，并且他們知道如何燃起第三方開發團體的力量，而且他們吃自己的狗食。你知道嗎？他們的狗食做得很好吃啊。他們的APIs比Microsoft的要干凈不知道多少倍，而且是遠古的時候就這樣了。
- Facebook也領會到了。這正是讓我所擔心的。這使得我不得我抬起懶惰屁股寫下這些東西。我恨寫Blog。我恨……Plus（指Google Plus）不管怎么稱呼它，反正在Google+上發表長篇大論，就算這是個糟糕的地方，但是你還是希望Google能成功.我真希望！我的意思是，Facebook想挖我，而且很容易就去了。但Google是我的家，所以我堅持我這個小小的家庭干涉，就算你不舒服。
等到你為Microsoft與Amazon提供的平臺感到神奇后，當然，我想也你可能會被Facebook嚇到（我不敢去看，因為我不想讓我太沮喪），讓我們回頭看看?developers.google.com?。是不是有很大的差別？我們的這個平臺看起來像是你家小學五年級的侄子搞出來的東西一樣——讓一個小學五年級的學生，試著為一個強大的的平臺公司去設計平臺，就像像我們問這個小學生：“如果這家公司什么資源都有，那你會做出個什么東西來？” 一樣。
這里請不要誤解我——我知道一個事實，dev-rel 團隊為了發布這些API曾經不得不去“搏斗”。據我所知，這個團隊很不錯，因為他們知道什么是平臺，并且他們如英雄般努力掙扎地要做出來，然而遇到的卻是“平臺冷漠”的環境，難聽點還是那種有敵意的環境。
我只是在直白地描述出一下?developers.google.com?在外人眼里是什么樣子。它看起來很幼稚。Maps APIs在哪呢，老天啊？其中有些東西還是實驗性的項目，我點進去看的APIs……他們都毫無價值。他們很明顯都是些真正的狗食。甚至都稱不上是好的有機食品。跟我們內部APIs比起來，他們全部簡直就是豬屎馬糞。
當然，也不要錯誤地理解我對Google+的看法。他們還不算是最差的。這是文化氛圍的事。我們現在做的簡單來說就是要進行一場戰爭，是一場失敗很多的少數的平臺派和那些強大的信心堅持的產品派的戰爭。
那些從頭到尾明白理解供外部可程序化的平臺概念的團隊都是受壓迫的人——Maps跟Docs團隊浮現在我腦海中，而且我也知道GMail是這個方向的先頭部隊，但是他們很難得到資金注入，因為這不是我們文化的一部分。Maestro的資金完全沒法和Microsoft Office開發平臺的資金相比：就像小白兔和暴龍相比一樣。Docs團隊知道自己永遠無法和Office競爭，除非他們能趕上Office的腳本能力，而且他們得不到他們相要的資源。我的意思是我假定他們沒有，現在應用的腳本能力只在電子表格中有，而且沒有為API設置鍵盤快捷鍵。在我看來，這個團隊完全沒有被重視。
具有諷刺意的是，Wave是個偉大的平臺，愿他能安靜地長眠。我們需要知道，做一個平臺并不會馬上給帶來成功。平臺需要殺手級應用。Facebook——他們供應了的涂鴉墻和朋友關系網等其他東西——則是Facebook平臺的殺手級應用。但是，如果你說沒有Facebook平臺，僅有Facebook應用也能像今天這樣成功，那么，這會是一個非常嚴重的錯誤。
你知道嗎？人們總是在說Google的傲慢自大。我是個Google人，所以我和你一樣當聽到那些話都會覺得很憤怒。但總體而言，我們并不傲慢。我們大約99%不自大。我在文章開頭時就寫到——如果你回去看看—— 我是這樣描述Google的“所有的事都做對了”。我們知道人們為什么要這么說我們自大，因為我們沒有雇用他們，或是因為他們對我們的政策不爽，或是那一類的事情。他們推斷出我們自大是因為這樣會讓他們心理平衡一些。（陳皓注：作者在這里的反話正說）
但是，當我們擺出那種我們知道怎么給用戶設計出完美的產品的姿態時，你最好相信我，我們就是笨蛋。你可以說是自大，天真，或是別的什么，無所謂，但最終的結果就是我們干的很愚蠢。因為，這世界不可能有一個產品對所有人都是完美的。
你看，我們的瀏覽器居然不能讓人設定默認的字號。這就是我們對Accessibility的公然冒犯。我的意思是，我總有一天會老的，我也會得老花眼，并會變瞎的。我的意思是我不會變瞎，但是如果你到了40歲，你的老花眼讓你看不清近的東西。那么，字號的選擇會成為生和死的問題：某用戶就會被完全排除在產品之外。但是Chrome團隊就是這么NB傲慢：他們想要開發出無需配置的產品，他們對此相當自豪，去你TMD是瞎子還聾子，管你是誰，在你剩下的日子每訪問一個頁面都按一下Ctrl-+吧。
并不僅是他們是第一個。問題是，我們是一家“產品”公司，一直一直都是。我們開發的最成功最有吸引力的產品——搜索引擎，那樣巨大的成功讓我們產生了很多定式和偏見。
- Amazon過去也是家產品公司，一道神秘的力量使得Bezos領悟到他們需要平臺。那道神秘力量來源于，他們被 逐漸蒸發的市值逼到墻角了，不得不想方設法突圍出來。但他當時所擁有的只有一群工程師和他們的一堆計算機……除非他們能變成印鈔機……你可以看到他們是怎么搞出來AWS的，而不是像我們Google+一樣事后諸葛亮。
- Microsoft從一開始就是個平臺，所以他們有很多很多的實踐。
- Facebook：我有些沒看透。我不是專家，不過我很肯定他們一開始也是一個產品，并且成功了很長時間。所以我不知道他們什么時候開始轉變成為平臺的。應該是很久以前的事了，因為他們要成為平臺后，Mafia Wars這玩意才會出現（而Mafia Wars也很老了）。
也許，Facebook只是看一眼我們，就問到：“我們如何擊敗Google？他們少了什么？”
我們面對的問題非常的龐大，因為我們需要經過劇烈的文化轉變后，我們才能迎頭趕上。我們沒有內部的SOA平臺，所以我們外部也沒有。這就是說，我們整個公司都“沒有領會到”：產品經理沒有，工程師沒有，產品團隊沒有，沒人領會到。就算是個別人有，比如你你有，那也相當于沒有，除非我們在生死存亡的時候。我們不能這樣不斷推出產品，并裝作我們以后會把這些產品轉變成迷人美麗的可擴展式的平臺。我們試過了，不行。
平臺的黃金守則，“Eat Your Own Dogfood?吃自己的狗食”，換句話說，“先打造出自己使用平臺，然后把它用在所有的地方”。你不能事后再做，那樣做就太困難了——你去問問那些把MS Office平臺化、把Amazon平臺化的人。如果你放在后面做，那么你比一開始要花十倍的精力才能做對。你不能作弊，你不能讓內部軟件走秘密通道以取得特定的優先權限，不為什么，你必需從一開始就要解決這個問題。
我不是說現在做已經太遲了，但我們等的越長，我們就會越接近——“太遲了”。
老實說，我不知道這篇文章怎么收尾。我今天在這里說得太多了。因為這篇文章花了我6年時間。請包涵我言語冒犯之處，包涵我可能誤解了一些產品，團隊，或某個人。也許我們真的在開始做了很多平臺方面的東西，只是我沒看到。我只想說聲對不起。
但是，我們現在開始必需把事做對了！
轉載于:https://www.cnblogs.com/jackyzzy/archive/2012/05/09/2491302.html
總結
以上是生活随笔為你收集整理的转：SteveY对Amazon和Google平台的长篇大论的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于SSM的供应商管理系统
- 下一篇： 如何在github上搭建自己的个人主页