# Microsoft Stack 是否殺死了 MySpace?
> 原文: [http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html](http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html)

羅伯特·斯科布爾(Robert Scoble)撰寫了一個引人入勝的案例研究, [MySpace 的死亡螺旋:內部人說,這是賭在洛杉磯和微軟](http://scobleizer.com/2011/03/24/myspaces-death-spiral-due-to-bets-on-los-angeles-and-microsoft)上的,他在報告中說 MySpace 內部人將微軟[丟掉了很棒的社交網絡的原因歸咎于微軟 種族](http://www.intelligentspeculator.net/investment-talking/why-facebook-is-succeeding-where-myspace-has-failed/)到 Facebook。
有沒有人知道這是不是真的? 真實的故事是什么?
我在想,因為它似乎與我在 2009 年所做的 [MySpace Architecture](http://highscalability.com/blog/2009/2/12/myspace-architecture.html) 帖子不一致,他們似乎對他們的選擇感到滿意,并提供支持其改進的統計數據。 這很重要的原因是,這是初學者可以借鑒的迷人模型。 成功真正需要什么? 是人員還是堆棧? 是組織還是技術? 是過程還是競爭? 網站的質量還是用戶的喜愛? 有太多需要考慮和學習的地方。
本文中的一些猜想:
1. Myspace 沒有編程人才能夠擴展網站以與 Facebook 競爭。
2. 選擇微軟的體系使其很難聘請能夠與 Facebook 競爭的人。 .Net 程序員主要是企業程序員,他們的組織結構并非以啟動速度創建大型可擴展網站。
3. 他們的系統具有““數百個駭客,使其規模擴大到沒人想碰”,這損害了他們真正競爭的能力。
4. 由于 MySpace 的基礎架構,他們無法更改其技術以使新功能正常工作或帶來新的體驗。
5. 激怒了很多人,鼓舞士氣,使招聘變得艱難。 (du)
6. 洛杉磯沒有能夠產生可擴展社交網絡系統的創業人才。
7. Facebook 選擇的 LAMP 堆棧使他們可以更快地招聘并找到知道如何擴展的人。
評論中的一些非常有趣的觀點(來自文章,電子郵件, [Hacker News](http://apps.ycombinator.com/item?id=2369343) , [Hacker News](http://news.ycombinator.com/item?id=2369271) ):
1. **Nick Kwiatkowski** :我能夠與一些在 MySpace 工作的程序員一起工作,但問題不是引擎(無論是在 ColdFusion 還是.NET 上) ,這是他們選擇為其開發人員孕育的環境。 管理層會說“我們現在需要 X 功能才能保持競爭力”。 然后,他們將選擇一組開發人員來實現該功能。 最大的問題是他們不允許開發人員進行登臺或測試服務器-他們是在第一次嘗試時將其部署在生產服務器上的。 有時,這些開發人員只能在很少的時間內獲得 5 或 10 個項目的部署。 而這一切都沒有變更管理或控制。 也沒有版本控制。 MySpace 管理層從不希望回頭查看代碼或提高代碼效率。 他們的解決方案是“更多服務器”。 他們最終雇用了一個唯一的工作就是安裝更多服務器的工作人員。 同時,他們讓開發人員簽入錯誤代碼,并且以驚人的速度累積技術債務。 當時,MySpace 正在運行其應用程序服務器的兩個主要版本,而不是建議使用的版本。 微軟(HTG8)新亞特蘭大市(New Atlanta)問世時,他們跳槽了從本質上出售其技術債務(例如抵押給金融公司的抵押品)的想法,并請其他人來解決他們的問題。 當時的問題是微軟沒有更新他們的舊代碼,他們只是在.NET 上添加了新功能。 這并不能解決他們的問題,而使他們處于仍然需要修復舊內容,同時又要更新新代碼的情況。MySpace 的問題是:它們是當您不聽并且積累了過多技術債務時的經典示例。 修復舊內容應該是優先事項,并且必須執行諸如變更管理,版本控制,測試和開發服務器等工作。 這就是為什么 Facebook 能夠部署幾乎沒有影響的新更改的原因-他們在讓實際用戶使用之前對其進行了測試和驗證。
2. **u_fail** :聽起來這一切都是對技術歸咎于技術的了解很少甚至根本不了解的商人,而一直以來都是缺乏創新并且高層缺乏決策者。 MySpace 始終像一家娛樂公司一樣運作。
3. **Eric** :這與技術無關,而與實施技術的人員有關。
4. **Robert Scoble** :MySpace 的體系結構使得很難發布新功能和“樞軸”,一旦他們清楚地知道他們正在努力。
5. MySpace 的核心競爭力依賴于其他人,并且從未在內部擴展過,而且似乎完全無法發揮作用。
6. **Robert Scoble:**都是關于人才和獲得技術幫助的創新。 這些人沒有使用微軟的系統。
7. **編碼為**:MySpace 在 Microsoft 的堆棧上押注不是問題。 問題在于他們在 Telligent 的社交媒體平臺上下注。 MySpace 并未開發自己的平臺并向自己擁有和開發的平臺添加功能,而是決定讓另一家公司的產品為其核心功能集提供創新。
8. **Hack** :我記得在某人的頁面上瀏覽了 100 張.gif 文件,并在 25 秒后加載了頁面。 Facebook 無疑獲得了冠軍。
9. **Marcelo Calbucci** :這是一個錯誤的分析。 如果使用 RoR 或 PHP,他們將遭受完全相同的信念。 實際上,一旦 Facebook 改變了社交網絡應提供和外觀的標準,他們的命運就已經定下來了。
10. **Sriram Krishnan** :您對任何堆棧的使用與您所擁有的專業知識成正比。
11. **S Jain** :把責任歸咎于微軟是完全錯誤的。 我認為這是 MySpace 的一種文化。 我在洛杉磯的一家初創公司工作,在 Myspace 有很多朋友。 我常常會遲到,他們會說向一家大公司求職,為什么遲到了。
12. **Gregg Le Blanc** :當 MySpace 在 MIX06 上發表他們為何轉用 Microsoft 的主題演講時,他引用了一個事實,即他們可以在基本上 2/3 的服務器上處理相同的用戶負載(246-> 150),將平均 CPU 負載從 85%降低到 27%,以便為 6500 萬用戶負載的頁面提供服務。 因此,我認為這更多地與人員,體系結構和業務計劃有關。 他們的戰略決策是忘記創新。 那是技術獨立的。
13. Robert Scoble :馬克·扎克伯格(Mark Zuckerberg)表示,要在其他地方建立網絡規模的公司要困難得多,因此他從波士頓搬到了硅谷。
14. **Jebb Dykstra** :MySpace 在出售給新聞集團的那一刻就迷失了。真正的死亡螺旋就在那一刻開始。 如果像 Richard Rosenblatt 這樣的人才留下來,而他們并沒有以 670 毫米的價格賣掉自己,那么這些問題中的許多可能就是借口。
15. **Omar Shahine** :讓我們不要忘記 Twitter 根本無法擴展,并且基本上被破壞了。 它不是建立在 Microsoft 技術之上的,但是他們設法對其進行了修復。
16. **Sean Scott** :即使技術和人才匱乏是問題的一部分,而且 MySpace 無法響應 Facebook,最終用戶體驗還是為此付出了代價。
17. **DavidNo?l**:當他們說這將花費一些點擊和頁面重載,但會增加用戶體驗和長期參與度時,NewsCorp 會拒絕,因為擔心失去可貨幣化的指標。
18. **史蒂夫·史密斯**:MySpace 的代碼顯然有很多技術上的欠缺,從事物的聲音來看,其體系結構是教科書“泥漿大球”。 他們將核心業務押在第三方軟件上。
19. **Scott Stocker** :愿意為 MySpace 工作的開發人員的可用性是最大的問題。
20. **琳達·尼古拉**:用戶沒有因為技術投訴而離開現場,這是因為新來的孩子騎著一輛更加光亮的自行車...缺乏創新,缺乏競爭性, 產品推出有限,高層動蕩不安,技術問題,但不要將其歸咎于洛杉磯缺乏技術人才
21. **Dan Bartow** :閱讀本文后的最初印象是,我完全同意 Scoble 所說的有關洛杉磯和人才問題的一切。 MySpace 處于獨特的狀況,因為它們專注于娛樂行業,主要是音樂行業和相關內容。 由于這種關注,洛杉磯確實是他們所做工作的“理想之地”。 要插入現場并進行藝術家活動,與唱片公司建立聯系……還有什么更好的地方? 如果您是一家金融公司...新英格蘭。 娛樂...洛杉磯。 另一方面,它們也是流量最高的網站之一,因此,他們確實需要站在技術的最前沿。 的確,洛杉磯不一定具有像舊金山灣區在尖端網絡規模架構方面的工程人才類型。 但是,請認為 MySpace 的問題與其所選擇的技術平臺選擇(微軟與其他產品)相比要少得多,而與工程領導力,市場定位和響應時間等有關的更多。我個人對其性能和可伸縮性印象非常深刻 。 他們快速的自動配置和重新配置功能非常出色。 他們能夠進行 100 萬個并發用戶測試,就像沒有發生那樣,因此非常棒。 我實際上不知道這是微軟技術,并且可能永遠不會根據他們在其架構中所做的事情來猜測。 作為工程師,您和我倆都知道正確的心態以及強大的領導才能使幾乎任何技術都達到最高水平。 PHP 是可擴展性最低,性能最差的語言之一,直到 Facebook 一直將其推向頂峰。 領導。 Microsoft 網站上有很多高流量的站點,所以我認為技術選擇不像 Scoble 聽起來那么重要,并且基于我在 MySpace 上的工程領導地位,實際上是很糟糕的事情。 人才...當然,洛杉磯不是硅谷,但是相信我,有很多理由選擇使用 SoCal。 就我個人而言,我認為 MySpace 的問題一直存在于業務領導地位以及對競爭對手的反應時間較慢。
22. **Scott Seely** :MySpace 死亡螺旋上升的原因與技術無關。 是與人類問題有關的一切。 克里斯·德沃爾夫(Chris DeWolfe)和湯姆·安德森(Tom Anderson)離開后,隨之而來的是許多重要領導。 此外,許多創意人員(產品經理,開發人員,藝術家等)都看到高管離職,并決定現在是嘗試其他方法的好時機。 太多的機構知識留下得太快了,這破壞了 MySpace。
23. **jdavid** :MySpace 擁有的是文化債務,并且擔心破壞他們的財產。 Facebook 之所以獲勝,是因為他們是核心的蘇格拉底。 Fox 是一家封閉源代碼的公司,因此當我們像 Oauth 和 OpenSocial 小工具服務器這樣的開放技術公司工作時,我們必須將其作為封閉源代碼軟件來進行。 我們沒有同行評審。 當您沒有 Linkedin,google,bebo 和 twitter 來檢查代碼時,這真的很難發貨和測試。 最重要的是,當這些公司發現錯誤時,我們必須在.Net 中重新實現該代碼。 最重要的是,MySpace 和.Net 是針對強類型化而精心設計的,這些類型與 Java 有點不同。 移植并不需要花費很多時間,所以我們一直這樣做,但是您必須考慮一下,您正在與像 Facebook 這樣的公司競爭,當時該公司的利潤動機為零,并擁有數十億美元的資金和 地面堆棧。 同時,MySpace 只是在清除冷融合,而我們有真正的舊博客平臺,不能僅僅將其刪除。 我們還擁有不想激怒用戶的管理,因此我們將擁有 2 或 3 個版本的站點,并且我們要求用戶升級到新版本。
24. **jdavid** :與 Google 的交易失敗了,因為這些條款涉及的是瀏覽量和點擊次數。 MySpace 和 Fox 決定以這些條款為目標,以最大限度地提高收入。 結果是 MySpace 幾乎為每個用戶操作都添加了不必要的頁面流。 它摧毀了用戶體驗并激怒了谷歌。 我們的團隊一直在與管理人員開玩笑,說我們將通過 REST API 創建一個 MySpace-Lite 作為輔助項目,并擺脫所有的廢話。 我們應該做的。 我們應該創建 MYSPACE-LITE。 與 Google 的交易每年價值 3 億美元,每年總收入 7.5 億美元。 MySpace Music 失去了公司的瘋狂資金,過去是而且是有缺陷的模型。 我們的團隊想創建一個 API,游戲和網站可以訪問音樂,并創建開放的播放列表。 我們想將音樂打開,然后進行許可。 有人告訴我們這是不可能的。
25. **lemmsjid** :Web 層與可伸縮性幾乎沒有關系(不要誤會我,它與成本有很大關系,只是與可伸縮性沒有關系,除非采用諸如數據庫連接池這樣的更巧妙的方式) 這都是關于數據的。 當 MySpace 達到指數級增長曲線時,幾乎沒有用于擴展 Web 2.0 stype 公司的解決方案(OSS 或非 OSS)(大量讀取,大量寫入,大量熱數據超過了商品緩存硬件的內存,當時為 32 位) ,并擁有非常昂貴的內存)。 沒有 Hadoop,沒有 Redis,Memcached 剛剛被釋放并且存在現存的問題。 這很有趣,因為今天人們問我:“為什么不使用 Technology X?” 我回答:“好吧,那時還沒想到呢:)”。 當時,只有如此規模的地方才出現,例如 Yahoo,Google,EBay,Amazon 等,而且由于它們都在專有堆棧中,因此我們會盡可能多地閱讀白皮書,并盡可能多地獲得白皮書。 -一起收集信息。 最后,我們編寫了一個分布式數據層,消息傳遞系統等,以處理跨多個數據中心的大量負載。 我們對數據庫進行了分區,并編寫了一個 etl 層,以將數據從 A 點傳送到 B 點,并將索引定位到所需的工作負載。 所有這些都是在每秒數十萬次命中的巨大負載下完成的,其中大多數都需要訪問多對多數據結構。 我們與之合作的許多初創公司,無論是硅谷還是硅谷,都無法想象將他們的東西擴展到那種負載-許多數據系統供應商在使用它們之前(如果有的話)需要對其東西進行許多修補。 時代已經改變了-現在想象擴展到 MySpace 的初始負載要容易得多(幾乎可以接受)。 關鍵分區數據庫層,分布式異步隊列,用于聊天會話的大型 64 位服務器等。但是,您要考慮到該系統永遠不會脫機-您需要持續 24 小時訪問。 當整個系統出現故障時,您將損失大量資金,因為數據庫緩存消失了,中間層緩存消失了,等等。這就是操作故事的來歷,在此我可以為系統專門介紹其他幾段 用于監視,調試和映像服務器。 當然,還有數據故事和 Web 代碼故事。 MySpace 是一個非常難以在 Web 端進行進化的平臺。 其中一部分是整個站點上用戶體驗的碎片化,而很大一部分是用戶提供的 HTML。 不以微妙或不微妙的方式破壞人們的經歷是很難做的。 許多配置文件主題都將圖像放置在圖像之上,并且 CSS 讀取了“ table table table table ...”。 當您不得不處理數百萬個 html 變體時,請嘗試更改體驗。 在這方面,談到靈活性時,我們挖了自己的墳墓。 不要誤會我的意思,系統存在的缺陷多于我所能估計的。 總有事情要做。 但是,作為喜歡在 Microsoft 和 OSS 堆棧上花費時間的人,我可以告訴您問題不是問題在于 MS 技術,也不是缺乏工程技術人才。 我為建立這些系統而工作的人們的素質感到驚訝和謙卑。
26. n_ar??e_q 的**:對于在公司工作并關心環顧四周并了解正在發生的事情的任何人來說,MySpace 垮臺的原因都是顯而易見的-這是災難性的,缺乏管理和產品的領導力和遠見, 癱瘓了政治內斗,以及公司管理層高層普遍缺乏能力。 因此,做出決定的人會不斷改變主意和要求。 有許多完整的功能在完成后并沒有啟動或放棄,因為管理層無法就如何“定位”它們達成共識(它們是很棒的功能)。 高管層一直處于政治內斗狀態,這很可能來自狐貍和他們的狗屎行為。 沒有人可以在這個級別上判斷和獎勵能力,這僅僅是關于誰可以更好地掩蓋自己的屁股或看起來更好地表現出來。 MySpace 很大,每個人都只想吃一塊。 由此產生的問題之一是缺乏對技術的尊重,即更高層次的人都沒有將該公司視為技術公司。 他們將其視為娛樂或媒體公司。 這造成了文化上的問題,最終導致不良產品和偽劣實施。 現在,該組織的核心技術部分實際上非常勝任。 在鼎盛時期,MySpace 吸引的流量超過了 Google,那時該網站的規模還算不錯。 那不是偶然的,我和那里的一些業內最聰明的人一起工作過。 但是因為技術不是高管的重點,所以這些人受到非技術管理人員的嚴格控制,因此產品遭受損失。 MySpace 可以(而且仍然)可以擴展任何東西,也就是說,到了達到頂峰時,他們已經遇到了擴展問題,這完全是亂碼。 多年來,他們開發了非常成熟的技術堆棧。 沒有人知道,因為它是完全專有的。 問題是管理和產品基本上...無能為力,并且缺少適當水平的任何人來照顧和修復它。**
27. **mhewett** :我不確定這些基于技術的分析是否正確。 當時我有四個少年,他們都從 MySpace 切換到 Facebook,因為 MySpace 的頁面上充斥著耀眼的廣告。 Facebook 布局更整潔,并且沒有廣告(當時)。 網站速度沒有問題。
28. **暈眩**:這表明技術和位置的選擇不是原因,它們是公司管理層的癥狀,他們不了解構建簡單的 Internet 應用程序(最佳的技術堆棧是什么; 在何處,何時何地聘用開發人員來構建),并保留進行所有技術決策的權限。 與此形成鮮明對比的是,與 Google 等人的 Facebook 相比,在這里設計每個流程(從公司 IT 到生產運營再到人力資源和招聘)時,都必須考慮到工程組織的需求:“想要兩個 24”顯示器嗎? 沒問題。 想要在筆記本電腦上使用 Linux 嗎? 沒問題。 想要 ssh 進入生產環境嗎? 沒問題。 想參加候選人面試嗎? 沒問題。”
29. **sriramk** :我有來自 MySpace 的一堆朋友,我聽到的一個共同主題是,他們認為更好的架構(未連接到堆棧)會讓他們更快地發貨。 看來您可以忍受的技術債務是有限的。 如果您重寫得太快,您會被一家通過大量重寫/重新設計工作而殺死其產品的公司取笑。 花了太長時間,像 FB 這樣的人很快就發布了功能并躍居您的前面。
30. **ChuckMcM** :我認為企業家的見解是“網絡”不是“企業”。 微軟已經花費了數十億美元來瞄準“企業”(與 SAP,Oracle,Salesforce 等大型軟件公司競爭),其結構和部署與“網絡”(大型用戶是 Google,Facebook 等)截然不同。 當我在 NetApp 工作時,我們在世界各地都有客戶,我們發現**“企業”家伙經常有節奏,例如成長,發現挑戰,努力,升級,重復** 。 這個周期是圍繞著獲取最新版本的“大型播放器”軟件,對其進行鑒定,然后使其投入生產,進行一些擴展,確定問題出在哪里,與他們的供應商交談,等待,獲取新版本然后重復來進行的。 周期。 但是“網絡”玩家的節奏最好是零星的,并且常常是瘋狂的,功能請求,測試,迭代,功能,迭代,測試,海岸,海岸,海岸,功能,功能,功能,測試,海岸等。 他們會立即實現某種原型或測試用例的“網絡”基礎架構人員,然后迅速提出支持該功能以最大化該功能所需的基礎架構功能。 但是有時它們會花費很長時間,幾個月,而不會發生任何變化(在基礎架構方面,網頁,UX 等方面肯定會發生變化,但是服務器和存儲資產相同)。 我從中學到的東西是,雖然在運營費用方面擁有其他公司來承擔“基礎基礎架構”的負擔真是太好了(但是,如果您不更改該級別的內容,那么您就不需要 Linux 黑客了,所以 節省員工等),這對變更衍生產品施加了硬性限制。 如果您嘗試更改的速度快于基礎架構的更改速度,結果是您最終會受到限制,并且會積聚技術疤痕組織,隨著時間的流逝,這會進一步降低您的移動性。 因此,最重要的是,您將無法繼續以比基礎架構更快的速度進行樞紐工作,如果您正在圍繞基礎架構進行變更,那么您的變更能力將因一千次黑客攻擊而消失。 如果您發現自己需要思考一下您的基礎架構,請聽從該警告,并開始規劃一個更加敏捷的基礎,以便從現在開始工作,而不是當我們在開發一個全新的系統時仍在努力保持舊系統正常運行時。
31. **phlux** :確實可以做出一種基礎架構選擇,即政策,它將為您提供整個公司基礎架構生命周期內的最佳可用路徑:全面虛擬化
32. **akshat** :硅谷的人才也許很棒,但我敢打賭,任何大都會都有足夠的優秀開發人員來使任何網絡公司成功。 您需要成為一個能夠吸引此類人的地方。
33. **Lukeas14** :您可以嘗試指責 Myspace 的“死亡螺旋式增長”是由于他們的技術堆棧轉移到了洛杉磯,但根本原因是他們無法創新。 實際上,2010 年的網站與 2002 年的網站相同。請考慮一下 Facebook 當時發布并重新推出了多少新功能。 曾經有一段時間,許多人喜歡他們自定義設計的個人資料頁面。 但是后來他們長大了,而 MySpace 卻沒有。
我的一些觀察:
* 堆棧不是真正的問題。 那簡直太傻了。 查看 Windows,.Net 等,如果使用正確,它們都具有相當的伸縮能力。 Facebook 從 LAMP 開始,但是在此過程中,他們改變了一切,因此很難說他們最終仍在使用 LAMP。 Twitter 與 RoR 經歷了類似的階段。 如果沒有改變您要觸摸的所有東西來滿足您的特定需求,您就無法以如此規模生存。 Facbook 還使用非常小的團隊,因此您實際上并不需要大量的人才。 您需要一些才華橫溢的人才,這些人才應有正確的愿景,支持和支持,讓他們自由解決問題。
* 問題是為什么技術沒有正確使用? 這些評論指出了許多不同的原因,但最終都歸結為人們。 他們被不重視技術的管理團隊收購了嗎? 如果可以相信某些開發,發布和設計決策,則可能會出現這種情況。 核心競爭力似乎已經轉移給了第三方。 像 SAN 這樣的技術被引入來解決問題,而不是直接解決問題。 兩者都是致命的。 無論使您獲得成功,都必須完全擁有。 也許作為“娛樂”公司而不是技術公司會促進這種方法。 但這又會回到所有權和管理上。 人們似乎忘記了,除非他們是魔術師,否則天賦就不能在直筒夾克中發揮作用。
* 創新問題很有趣。 我們看到 Facebook,Amazon,Google 和 Apple 等公司不斷創新。 這對 MySpace 的命運有多重要? 為什么創新對他們不重要?
所以發生了什么事? 更重要的是,公司中的新創業公司和集團如何避免這種命運? 我們一直都在看。 這讓所有參與其中的人感到沮喪。 我們現在不應該過去這種事情嗎?
## 相關文章
* [StackOverflow](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) 和 [PlentyOfFish](http://highscalability.com/plentyoffish-architecture) 是成功使用 Microsoft 技術的公司的著名示例。 但請注意,他們利用了它,這與將王國的鑰匙交給沒有與您一致的目標的公司不同。 僅將農場押在您身上。 LAMP 堆棧是獨立的組件,易于更換和修改。 當您購買完整的堆疊時,遇到問題時就會陷入困境。 您永遠不想被困住。
* 關于[黑客新聞主題](http://apps.ycombinator.com/item?id=2369343)的好的評論
* [MySpace 如何測試 100 萬個并發用戶的實時站點](http://highscalability.com/blog/2010/3/4/how-myspace-tested-their-live-site-with-1-million-concurrent.html)
我不知道要捍衛.NET 作為初創企業的可行平臺有多少次,我自己的初創企業 [SocialDeal.net](http://www.socialdeal.net) 是建立在.NET 上并由 Azure 托管的。 我已經到了這樣的地步:我再也很少和平臺迷們一起參加火焰戰了,這簡直是無利可圖,我的時間最好花在其他事情上。 只要我看到 Microsoft 像他們使用 MVC 框架和 Azure 所做的那樣繼續發展它,我就會對.NET 作為啟動平臺充滿信心。 如果我只是嘗試在 RoR 或 Python 中構建 SD 只是為了時髦或者試圖解決一些虛構的問題以擴展數百萬個用戶,我根本就不會啟動該站點,因為總的時間投入和架構應用程序意味著 它從未完成過,而從未啟動過的應用程序所帶來的失敗遠大于后來嘗試擴展的問題。
我認為您是對的,技術堆棧并不是殺死他們的工程文化的原因。
這是我的全部觀點。 Myspace 腫。 到處都是垃圾郵件發送者和騙子。 他們允許人們無限使用 HTML 和 Java 來自定義其頁面的事實,這意味著沒有一致的用戶體驗,而且某些自定義頁面需要花費幾分鐘才能加載或掛起 Web 瀏覽器。 然后是 Facebook。 一切都很干凈有光澤,并且很容易找到所有的朋友(新老)。 另外,Facebook 提供了與 Myspace 的騙子和垃圾郵件發送者不同的步伐(是的,Facebook 擁有其中的一些功能,但與 Myspace 的體驗完全不同)。
不要責怪這里的幕后技術(最終用戶只要獲得想要的用戶體驗就可以少在乎幕后的東西),也不要責怪洛杉磯。 洛杉磯有很多非常有才華的開發商。
技術堆棧吸引或排斥工程師。 實際上,這確實很重要,最好的工程師想要使用他們認為是最好的工具。
我想認為.NET 可以根據我們的經驗進行擴展,這只是做對的事情。 我們在 Flash / iOS UI,.NET 服務層以及 MySQL(XtraDB)數據庫和 MySQL Cluster 數據庫的混合堆棧上運行了成功的世界教育游戲。 它可能沒有看到像 Facebook 這樣龐大的規模,但是它在不到 4 天的時間里成功處理了將近 10 億個服務器請求,有 250 萬孩子參加了舞會,而我們背后的那些人則設法獲得了愉快的體驗 我們自己,只有 40%的基礎架構得到了利用。
MySpace 失敗,因為用戶離開了。 用戶(包括我自己)沒有離開,因為它運行在 Microsoft 堆棧上。 我們離開是因為所有 MySpace 都對成為一家媒體公司感興趣。 人們想要一個社交網絡,而今天,Facebook 或多或少都是這樣。
MySpace 的問題是系統性的,而不是系統性的。 非專業的開發組織。 政治內斗。 訴訟。 他們從不曾是硅谷公司,而是一家以色情,垃圾郵件和惡意軟件而誕生的洛杉磯公司,后來想成為好萊塢公司-他們貪婪地追求浮華與魅力,卻擁有爛透了的技術核心。
Myspace 進行了有毒技術管理。 這是我唯一一次接受采訪。 他們為才華橫溢而不是因為缺乏才華,而是因為 CTO(缺乏個性)和他的兄弟般的小伙子使周圍的環境變得可怕。 在洛杉磯,這里有很多偉大的才華,他們根本不愿意成為“好萊塢”。
我同意新聞集團殺死 MySpace 的想法。 沒有互聯網的人不應該管理互聯網公司。 并不是后端服務器上正在運行的內容,而是當您訪問首頁時,它們讓您頭疼的大型恐怖視頻廣告/橫幅廣告。 這是設計不足的用戶體驗。 這是他們基于 Flash 的聊天應用程序從未起作用的事實。
有許多與 Microsoft 堆棧一起工作的人才。 如果您的眼光正確,MS 技術可以使您更快地執行。
簡單而失敗的原因是用戶界面被大量吸引。 您需要登錄頁面,然后是實際頁面,并且必須剪切并粘貼 javascript 代碼段和 html 代碼段等以使其正常工作。 然后,您必須去尋找其他東西來使這個或那個工作。
然后出現了 facebook,您登錄時只有一個簡單而簡單的用戶界面,其中包含一小套有效的工具來查找您的朋友。 然后,facebook 將游戲放入其 API 中,這可以讓人們了解在何處以及為什么人們真正使用 facebook。 拿走游戲,您可能會失去一半以上的 facebook 人口。 但是總體的關鍵部分和前進的關鍵是一個輕巧的用戶界面,它不需要您在網上搜索 javascript 小程序或 html 代碼來創建 myspace 頁面。 您有在 Facebook 中自定義或唯一的自由嗎? 并非完全不一樣,對于 Twitter 一樣,是的,您可以添加一個后擋板并用顏色標記一些內容,但總體來說,它鎖定在用戶剛剛使用的 UI 中。
那是主要的區別,干凈,易于使用的 UI 與糟糕的 UI 甚至使我成為 Web 開發人員的瘋狂嘗試。 如果真能說出我的妻子,更不用說我的母親使用 myspace 了。 Facebook,盡管嘿,單擊此信息選項卡,單擊鉛筆并填寫一些內容,然后單擊此查找朋友并享受。
@ fatal.error,各個領域都有出色的工程師.... NET,LAMP,JAVA 等...
摘自文章:“這就是為什么 Facebook 能夠部署幾乎沒有影響的新更改的原因-他們在讓實際用戶使用之前對其進行了所有測試和驗證。”
真?! 您是否曾經開發過 FB 應用程序? 您是否曾經聽過全球開發人員大喊大叫的聲音,是因為 FB 的男孩天才編碼員將錯誤的代碼投入了生產,并且破壞了所有人的應用程序? 您是否曾經需要處理過時,不準確的文檔以及不斷變化的 API? 以及如何神奇地實現 oauth。
那篇文章真是太棒了。 我想我現在要去尋找一個著名的基于 Java 的失敗...
哈哈,我同意 FredTheKAt
Facebook 在提供良好的開發人員體驗方面毫無用處。
然而,盡管應用程序在移動平臺上是屈膝的(是的,我曾經使用過),但 Facebook 的抽獎卡是最終用戶,可以跟上他們所有的朋友。 如果用戶體驗始終如一,那將是成功的。 MySpace 失敗。
我確實覺得很有趣,盡管認為自己鎖定了 FB 個人資料的人現在已經以某種方式神奇地擦除了第三方在鎖定之前(實際上是在他們授予游戲/應用訪問權限之后)關于他們的所有數據。 數據卻沒有真正實現! 如果人們真的了解 FB 的工作原理,我認為它不會那么受歡迎。
除了所有的技術故障(是的,我認為他們的代碼很糟糕)之外,MySpace 的主題始終總是令人感到惡心-允許未成年的孩子不受監督地訪問網絡。 這些孩子(和我的孩子)長大了,獲得了一定的品味,并發現 MySpace 俗氣。 當年齡較大的孩子轉向 Facebook 時,年齡較小的孩子們緊隨其后。
MySpace 俗氣。 孩子們(年齡較大和較小)不再認為 MySpace 很酷-這是有充分理由的。
新聞集團買了一些黏糊糊的東西,現在賠本了。 好。
MySpace 很棒,但是當他們想成為 Facebook 的時候,他們就完全失去了可愛的功能。 這以及對用戶的完全不尊重使我停止了回來。 并非所有事情都與競爭相同……要獨樹一幟,這是我的建議……技術應促進一個目的,而不是目的。
由于放棄了其功能集和可用性,MySpace“丟失了”。
如果您無法像 Facebook 一樣快增長,那又如何呢? MySpace 擁有自己的利基市場,并在自己的領域處于領先地位-年輕人的音樂和社交網絡。
此故障與 Microsoft 技術無關。
技術人員不會創新或設計,他們會實施
成功的網站是由用戶體驗驅動的。 Facebook 和 Twitter 是示例。 因為他們真正關心最終用戶,所以他們所做的事情可以提供良好的體驗。 設計師和建筑師的工作是否能夠提供良好的用戶體驗,而不是“老板”會感到高興。
因此,這是關于文化和人員(主要是關于大老板,他必須關心最終用戶),而不是技術。
但是,另一方面,最佳用戶體驗驅動的網站通常不是基于 MSFT,IBM 或 ORACLE 的 COTS 產品構建的。 那也可以說。
“技術不是創新或設計,而是實施”
@另一個聲音:醒來的人.....
說.NET 是 MySpace 失敗的原因,就像說 MySQL 是 Facebook 成功的原因。 兩種說法都是荒謬的。
沒有 1.)任何內幕知識 2.)有很多事實或實質可以支持,但這里有很多觀點。 這是一個完全愚蠢的陳述,它既顯示了對技術的嚴重誤解,也顯示了使業務成功或失敗的根本過分簡化。
我向所有神圣的事情祈禱,我自己不必再在.NET 中工作。 這不是我的最愛,嚴格來說,由于許可證成本,它可能不是小型初創公司的好選擇,但這只是純粹的精英 BS 所說的,僅僅是因為您的技術堆棧是.NET,所以您不是創新者或 與競爭對手相比,您在技術上有殘障。
如果您足夠愚蠢以至于無法讓這些話從您的嘴里溜走,我建議您更好地隱藏內心的障礙。 它正在顯示,每個人都可以看到。
我在看著你 Scoble。 堅持您所了解的主題。
不是技術,也不是城市。 是福克斯。
被 Fox 收購后,Myspace 的命運得以終結。 購買后,我們的目標是通過各種方式使網站獲利,并嘗試為可想象的每種廣告資源建立少量的垂直市場... myspace 天氣 myspace 汽車 myspace 等等。 他們對用戶沒有真正的構想,方向或價值主張。
一旦來自 Facebook 的威脅得以實現,缺乏真正領導才能的痛苦就變得顯而易見。 他們開始復制并關注 Facebook 所做的事情-反應而不是創新。 游戲結束。
這太糟糕了。 一次 MySpace 是年輕人去表達自己并分享音樂品味的地方。 MySpace 應該完全擁有音樂產業。
我將不得不同意 MySp Fox 的購買,但沒有做任何其他事情,只是錯過了管理其資產的工作,也沒有采取任何措施來改善它。 也許他們需要寫一些稅款。 但是除非您確定自己知道如何使它更好地工作以便可以提高利潤,否則您不會購買任何東西。 直到交易完成約 30 天,它的表現都不錯。 在[閃光燈](http://www.arcflashstudynow.com)中,您幾乎可以看到它開始爆炸。 只是我的想法希望沒有人會被他們冒犯。 :)很棒的信息。
在研究(針對單篇論文)關于社交網站的技術含義以及為什么其中一些失敗如此之快而另一些卻沒有這樣時,我遇到了這篇文章。 關于它的技術,這種技術是您經常聽到的技術,因此這篇文章對我來說是一本好書。
但是,如果它們達到 Facebook 的大小會怎樣? 這樣可以達到這樣的規模嗎?
這是一個有趣的(研究)問題-也許可以解決技術問題,在這種情況下,更大的問題是“如何向 MS 支付許可費?” -我保證:如果像彼得·泰爾這樣的投資者走上原來的道路,他們不會給他們錢?
MySpace 允許用戶在其頁面上放置無限數量的應用之后,立即開始令人垂涎。 它導致頁面加載和 Web 服務器無法正常運行。 他們通常不會使 CPU 或內存最大化,但會引發無數錯誤。 每天都會將網絡中斷帶到一個大房間里,以責罵失敗者(員工)。 糟透了。
對于 50%負載的計算機,解決方案是對其進行虛擬化,而不是修復奇怪的創可貼和少量垃圾。
Captcha 被收費低廉的印度人團隊毆打(沒有冒犯的意思),但他們同意不對進一步揭露他的方法的人采取進一步的法律行動。 并不復雜。 因此,在垃圾用戶,垃圾郵件發送者和他們可能會塞進的每一個垃圾功能之間走下坡路。
我的 2 美分。
- LiveJournal 體系結構
- mixi.jp 體系結構
- 友誼建筑
- FeedBurner 體系結構
- GoogleTalk 架構
- ThemBid 架構
- 使用 Amazon 服務以 100 美元的價格構建無限可擴展的基礎架構
- TypePad 建筑
- 維基媒體架構
- Joost 網絡架構
- 亞馬遜建筑
- Fotolog 擴展成功的秘訣
- 普恩斯的教訓-早期
- 論文:Wikipedia 的站點內部,配置,代碼示例和管理問題
- 擴大早期創業規模
- Feedblendr 架構-使用 EC2 進行擴展
- Slashdot Architecture-互聯網的老人如何學會擴展
- Flickr 架構
- Tailrank 架構-了解如何在整個徽標范圍內跟蹤模因
- Ruby on Rails 如何在 550k 網頁瀏覽中幸存
- Mailinator 架構
- Rackspace 現在如何使用 MapReduce 和 Hadoop 查詢 TB 的數據
- Yandex 架構
- YouTube 架構
- Skype 計劃 PostgreSQL 擴展到 10 億用戶
- 易趣建筑
- FaceStat 的禍根與智慧贏得了勝利
- Flickr 的聯合會:每天進行數十億次查詢
- EVE 在線架構
- Notify.me 體系結構-同步性
- Google 架構
- 第二人生架構-網格
- MySpace 體系結構
- 擴展 Digg 和其他 Web 應用程序
- Digg 建筑
- 在 Amazon EC2 中部署大規模基礎架構的六個經驗教訓
- Wolfram | Alpha 建筑
- 為什么 Facebook,Digg 和 Twitter 很難擴展?
- 全球范圍擴展的 10 個 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上擴展
- 《 FarmVille》如何擴展以每月收獲 7500 萬玩家
- Twitter 計劃分析 1000 億條推文
- MySpace 如何與 100 萬個并發用戶一起測試其實時站點
- FarmVille 如何擴展-后續
- Justin.tv 的實時視頻廣播架構
- 策略:緩存 404 在服務器時間上節省了洋蔥 66%
- Poppen.de 建筑
- MocoSpace Architecture-一個月有 30 億個移動頁面瀏覽量
- Sify.com 體系結構-每秒 3900 個請求的門戶
- 每月將 Reddit 打造為 2.7 億頁面瀏覽量時汲取的 7 個教訓
- Playfish 的社交游戲架構-每月有 5000 萬用戶并且不斷增長
- 擴展 BBC iPlayer 的 6 種策略
- Facebook 的新實時消息系統:HBase 每月可存儲 135 億條消息
- Pinboard.in Architecture-付費玩以保持系統小巧
- BankSimple 迷你架構-使用下一代工具鏈
- Riak 的 Bitcask-用于快速鍵/值數據的日志結構哈希表
- Mollom 體系結構-每秒以 100 個請求殺死超過 3.73 億個垃圾郵件
- Wordnik-MongoDB 和 Scala 上每天有 1000 萬個 API 請求
- Node.js 成為堆棧的一部分了嗎? SimpleGeo 說是的。
- 堆棧溢出體系結構更新-現在每月有 9500 萬頁面瀏覽量
- Medialets 體系結構-擊敗艱巨的移動設備數據
- Facebook 的新實時分析系統:HBase 每天處理 200 億個事件
- Microsoft Stack 是否殺死了 MySpace?
- Viddler Architecture-每天嵌入 700 萬個和 1500 Req / Sec 高峰
- Facebook:用于擴展數十億條消息的示例規范架構
- Evernote Architecture-每天有 900 萬用戶和 1.5 億個請求
- TripAdvisor 的短
- TripAdvisor 架構-4,000 萬訪客,200M 動態頁面瀏覽,30TB 數據
- ATMCash 利用虛擬化實現安全性-不變性和還原
- Google+是使用您也可以使用的工具構建的:閉包,Java Servlet,JavaScript,BigTable,Colossus,快速周轉
- 新的文物建筑-每天收集 20 億多個指標
- Peecho Architecture-鞋帶上的可擴展性
- 標記式架構-擴展到 1 億用戶,1000 臺服務器和 50 億個頁面視圖
- 論文:Akamai 網絡-70 個國家/地區的 61,000 臺服務器,1,000 個網絡
- 策略:在 S3 或 GitHub 上運行可擴展,可用且廉價的靜態站點
- Pud 是反堆棧-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于擴展 Turntable.fm 和 Labmeeting 的數百萬用戶的 17 種技術
- StackExchange 體系結構更新-平穩運行,Amazon 4x 更昂貴
- DataSift 體系結構:每秒進行 120,000 條推文的實時數據挖掘
- Instagram 架構:1400 萬用戶,1 TB 的照片,數百個實例,數十種技術
- PlentyOfFish 更新-每月 60 億次瀏覽量和 320 億張圖片
- Etsy Saga:從筒倉到開心到一個月的瀏覽量達到數十億
- 數據范圍項目-6PB 存儲,500GBytes / sec 順序 IO,20M IOPS,130TFlops
- 99designs 的設計-數以千萬計的綜合瀏覽量
- Tumblr Architecture-150 億頁面瀏覽量一個月,比 Twitter 更難擴展
- Berkeley DB 體系結構-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天對 2000 萬張照片進行爬網,分析和排名
- LinkedIn:使用 Databus 創建低延遲更改數據捕獲系統
- 在 30 分鐘內進行 7 年的 YouTube 可擴展性課程
- YouPorn-每天定位 2 億次觀看
- Instagram 架構更新:Instagram 有何新功能?
- 搜索技術剖析:blekko 的 NoSQL 數據庫
- Pinterest 體系結構更新-1800 萬訪問者,增長 10 倍,擁有 12 名員工,410 TB 數據
- 搜索技術剖析:使用組合器爬行
- iDoneThis-從頭開始擴展基于電子郵件的應用程序
- StubHub 體系結構:全球最大的票務市場背后的驚人復雜性
- FictionPress:在網絡上發布 600 萬本小說
- Cinchcast 體系結構-每天產生 1,500 小時的音頻
- 棱柱架構-使用社交網絡上的機器學習來弄清您應該在網絡上閱讀的內容
- 棱鏡更新:基于文檔和用戶的機器學習
- Zoosk-實時通信背后的工程
- WordPress.com 使用 NGINX 服務 70,000 req / sec 和超過 15 Gbit / sec 的流量
- 史詩般的 TripAdvisor 更新:為什么不在云上運行? 盛大的實驗
- UltraDNS 如何處理數十萬個區域和數千萬條記錄
- 更簡單,更便宜,更快:Playtomic 從.NET 遷移到 Node 和 Heroku
- Spanner-關于程序員使用 NoSQL 規模的 SQL 語義構建應用程序
- BigData 使用 Erlang,C 和 Lisp 對抗移動數據海嘯
- 分析數十億筆信用卡交易并在云中提供低延遲的見解
- MongoDB 和 GridFS 用于內部和內部數據中心數據復制
- 每天處理 1 億個像素-少量競爭會導致大規模問題
- DuckDuckGo 體系結構-每天進行 100 萬次深度搜索并不斷增長
- SongPop 在 GAE 上可擴展至 100 萬活躍用戶,表明 PaaS 未通過
- Iron.io 從 Ruby 遷移到 Go:減少了 28 臺服務器并避免了巨大的 Clusterf ** ks
- 可汗學院支票簿每月在 GAE 上擴展至 600 萬用戶
- 在破壞之前先檢查自己-鱷梨的建筑演進的 5 個早期階段
- 縮放 Pinterest-兩年內每月從 0 到十億的頁面瀏覽量
- Facebook 的網絡秘密
- 神話:埃里克·布魯爾(Eric Brewer)談銀行為什么不是堿-可用性就是收入
- 一千萬個并發連接的秘密-內核是問題,而不是解決方案
- GOV.UK-不是你父親的書庫
- 縮放郵箱-在 6 周內從 0 到 100 萬用戶,每天 1 億條消息
- 在 Yelp 上利用云計算-每月訪問量為 1.02 億,評論量為 3900 萬
- 每臺服務器將 PHP 擴展到 30,000 個并發用戶的 5 條 Rockin'Tips
- Twitter 的架構用于在 5 秒內處理 1.5 億活躍用戶,300K QPS,22 MB / S Firehose 以及發送推文
- Salesforce Architecture-他們每天如何處理 13 億筆交易
- 擴大流量的設計決策
- ESPN 的架構規模-每秒以 100,000 Duh Nuh Nuhs 運行
- 如何制作無限可擴展的關系數據庫管理系統(RDBMS)
- Bazaarvoice 的架構每月發展到 500M 唯一用戶
- HipChat 如何使用 ElasticSearch 和 Redis 存儲和索引數十億條消息
- NYTimes 架構:無頭,無主控,無單點故障
- 接下來的大型聲音如何使用 Hadoop 數據版本控制系統跟蹤萬億首歌曲的播放,喜歡和更多內容
- Google 如何備份 Internet 和數十億字節的其他數據
- 從 HackerEarth 用 Apache 擴展 Python 和 Django 的 13 個簡單技巧
- AOL.com 體系結構如何發展到 99.999%的可用性,每天 800 萬的訪問者和每秒 200,000 個請求
- Facebook 以 190 億美元的價格收購了 WhatsApp 體系結構
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 構建社交音樂服務
- 大,小,熱還是冷-條帶,Tapad,Etsy 和 Square 的健壯數據管道示例
- WhatsApp 如何每秒吸引近 5 億用戶,11,000 內核和 7,000 萬條消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延遲進行實時處理
- 關于 Disqus 的更新:它仍然是實時的,但是 Go 摧毀了 Python
- 關于 Wayback 機器如何在銀河系中存儲比明星更多的頁面的簡短說明
- 在 PagerDuty 遷移到 EC2 中的 XtraDB 群集
- 擴展世界杯-Gambify 如何與 2 人組成的團隊一起運行大型移動投注應用程序
- 一點點:建立一個可處理每月 60 億次點擊的分布式系統的經驗教訓
- StackOverflow 更新:一個月有 5.6 億次網頁瀏覽,25 臺服務器,而這一切都與性能有關
- Tumblr:哈希處理每秒 23,000 個博客請求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 處理 10 億個請求的簡便方法來構建成長型啟動架構
- MixRadio 體系結構-兼顧各種服務
- Twitter 如何使用 Redis 進行擴展-105TB RAM,39MM QPS,10,000 多個實例
- 正確處理事情:通過即時重放查看集中式系統與分散式系統
- Instagram 提高了其應用程序的性能。 這是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架構
- 英雄聯盟如何將聊天擴大到 7000 萬玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大規模構建發布平臺
- Aeron:我們真的需要另一個消息傳遞系統嗎?
- 機器:惠普基于憶阻器的新型數據中心規模計算機-一切仍在變化
- AWS 的驚人規模及其對云的未來意味著什么
- Vinted 體系結構:每天部署數百次,以保持繁忙的門戶穩定
- 將 Kim Kardashian 擴展到 1 億個頁面
- HappyPancake:建立簡單可擴展基金會的回顧
- 阿爾及利亞分布式搜索網絡的體系結構
- AppLovin:通過每天處理 300 億個請求向全球移動消費者進行營銷
- Swiftype 如何以及為何從 EC2 遷移到真實硬件
- 我們如何擴展 VividCortex 的后端系統
- Appknox 架構-從 AWS 切換到 Google Cloud
- 阿爾及利亞通往全球 API 的憤怒之路
- 阿爾及利亞通往全球 API 步驟的憤怒之路第 2 部分
- 為社交產品設計后端
- 阿爾及利亞通往全球 API 第 3 部分的憤怒之路
- Google 如何創造只有他們才能創造的驚人的數據中心網絡
- Autodesk 如何在 Mesos 上實施可擴展事件
- 構建全球分布式,關鍵任務應用程序:Trenches 部分的經驗教訓 1
- 構建全球分布式,關鍵任務應用程序:Trenches 第 2 部分的經驗教訓
- 需要物聯網嗎? 這是美國一家主要公用事業公司從 550 萬米以上收集電力數據的方式
- Uber 如何擴展其實時市場平臺
- 優步變得非常規:使用司機電話作為備份數據中心
- 在不到五分鐘的時間里,Facebook 如何告訴您的朋友您在災難中很安全
- Zappos 的網站與 Amazon 集成后凍結了兩年
- 為在現代時代構建可擴展的有狀態服務提供依據
- 細分:使用 Docker,ECS 和 Terraform 重建基礎架構
- 十年 IT 失敗的五個教訓
- Shopify 如何擴展以處理來自 Kanye West 和 Superbowl 的 Flash 銷售
- 整個 Netflix 堆棧的 360 度視圖
- Wistia 如何每小時處理數百萬個請求并處理豐富的視頻分析
- Google 和 eBay 關于構建微服務生態系統的深刻教訓
- 無服務器啟動-服務器崩潰!
- 在 Amazon AWS 上擴展至 1100 萬以上用戶的入門指南
- 為 David Guetta 建立無限可擴展的在線錄制活動
- Tinder:最大的推薦引擎之一如何決定您接下來會看到誰?
- 如何使用微服務建立財產管理系統集成
- Egnyte 體系結構:構建和擴展多 PB 分布式系統的經驗教訓
- Zapier 如何自動化數十億個工作流自動化任務的旅程
- Jeff Dean 在 Google 進行大規模深度學習
- 如今 Etsy 的架構是什么樣的?
- 我們如何在 Mail.Ru Cloud 中實現視頻播放器
- Twitter 如何每秒處理 3,000 張圖像
- 每天可處理數百萬個請求的圖像優化技術
- Facebook 如何向 80 萬同時觀看者直播
- Google 如何針對行星級基礎設施進行行星級工程設計?
- 為 Mail.Ru Group 的電子郵件服務實施反垃圾郵件的貓捉老鼠的故事,以及 Tarantool 與此相關的內容
- The Dollar Shave Club Architecture Unilever 以 10 億美元的價格被收購
- Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入
- 從將 Uber 擴展到 2000 名工程師,1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓
- QuickBooks 平臺
- 美國大選期間城市飛艇如何擴展到 25 億個通知
- Probot 的體系結構-我的 Slack 和 Messenger Bot 用于回答問題
- AdStage 從 Heroku 遷移到 AWS
- 為何將 Morningstar 遷移到云端:降低 97%的成本
- ButterCMS 體系結構:關鍵任務 API 每月可處理數百萬個請求
- Netflix:按下 Play 會發生什么?
- ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務
- 每天為 1000 億個事件賦予意義-Teads 的 Analytics(分析)管道
- Auth0 體系結構:在多個云提供商和地區中運行
- 從裸機到 Kubernetes
- Egnyte Architecture:構建和擴展多 PB 內容平臺的經驗教訓
- 縮放原理
- TripleLift 如何建立 Adtech 數據管道每天處理數十億個事件
- Tinder:最大的推薦引擎之一如何決定您接下來會看到誰?
- 如何使用微服務建立財產管理系統集成
- Egnyte 體系結構:構建和擴展多 PB 分布式系統的經驗教訓
- Zapier 如何自動化數十億個工作流自動化任務的旅程
- Jeff Dean 在 Google 進行大規模深度學習
- 如今 Etsy 的架構是什么樣的?
- 我們如何在 Mail.Ru Cloud 中實現視頻播放器
- Twitter 如何每秒處理 3,000 張圖像
- 每天可處理數百萬個請求的圖像優化技術
- Facebook 如何向 80 萬同時觀看者直播
- Google 如何針對行星級基礎設施進行行星級工程設計?
- 為 Mail.Ru Group 的電子郵件服務實施反垃圾郵件的貓捉老鼠的故事,以及 Tarantool 與此相關的內容
- The Dollar Shave Club Architecture Unilever 以 10 億美元的價格被收購
- Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入
- 從將 Uber 擴展到 2000 名工程師,1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓
- QuickBooks 平臺
- 美國大選期間城市飛艇如何擴展到 25 億條通知
- Probot 的體系結構-我的 Slack 和 Messenger Bot 用于回答問題
- AdStage 從 Heroku 遷移到 AWS
- 為何將 Morningstar 遷移到云端:降低 97%的成本
- ButterCMS 體系結構:關鍵任務 API 每月可處理數百萬個請求
- Netflix:按下 Play 會發生什么?
- ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務
- 每天為 1000 億個事件賦予意義-Teads 的 Analytics(分析)管道
- Auth0 體系結構:在多個云提供商和地區中運行
- 從裸機到 Kubernetes
- Egnyte Architecture:構建和擴展多 PB 內容平臺的經驗教訓