Dropbox曾經是較早躋身獨角獸俱樂部的AWS明星使用者，而現在他們卻跳下大船，走上了自建資料中心的道路。原因主要還是成本。Dropbox的工程副總裁Aditya Agarwal表示，雲端計算公司也是要賺錢的，規模大了以後自建還是可以節省大量資金。也難怪，Dropbox本身主營業務就是S3之上比較薄的一層，如果不自己搞，面對平臺的競爭（Amazon、微軟和Google都有類似的雲盤服務），毫無優勢啊。

據Wired網站的報道，Dropbox的整個遷移過程長達數年（文章裡說的是2年半，但從Magic Pocket從2013年就開始開發，以及Hacker News評論裡前員工指出的，肯定不止），已經在近期完成。其中主要工作包括：

• 自行開發類似AWS S3的檔案儲存系統Magic Pocket，由James Cowling團隊負責。原來的版本是2013年開始，用Go針對普通硬體編寫的。然後在自己的資料中心進行測試，看是否能可靠支撐AWS中20%的資料180天，一旦發現bug，就重新計時。後來為了適應自建硬體，而且原系統記憶體佔用較大，Jamie Turner又改用Rust重寫了其中的兩個大元件（OSD - Object Storage Device和volume manager）。這裡更詳細地討論了改用Rust的原因：堆的尺寸，節省CPU時間等等，當然也有問題，Dropbox整體基礎設施團隊都在用Go，所以很多庫都要再寫，而Rust的許多特性還不足，編譯時間也太慢。
• 自行設計了名為Diskotech的機器，每臺可以儲存1PB資料，由曾在Twitter和Dell工作的Rami Aljamal團隊負責。Diskotech每個機器18”×6”×42”（英寸），放在深度1.5倍的標準4U機櫃裡，硬碟是10T和14T的host-managed SMR。（參考HN上的討論。）
• 機房施工和安裝，1天40～50個機架，每機架8臺機器。
• 資料遷移，每天4PB。峰值可以達到0.5TB/s。（參考這裡。）

其他技術細節還包括：
- 使用了Reed-Solomon編碼，但為降低重建成本而做了優化。類似於Local Reconstruction Codes。
- 網路IO方面，在mio之上自行開發了基於futures的框架（受Finagle啟發）。所有I/O是非同步的，但應用任務經常線上程池（儘可能控制得較小）裡完成。

James Cowling在HN討論裡說明了整個專案的成效：

效能提升3～5倍。成本節省巨大，但具體不能透露。穩定性方面，S3和Magic Pocket都表現不錯。總原始儲存量是EB級別的。

Dropbox的官方部落格說，“資料持續性達到99.9999999999%以上，可用性超過99.99%。”

Dropbox的5PB數量級很大了，但也只佔AWS的百分之幾；而且Dropbox很小心地一再強調，仍然與Amazon在合作，尤其是歐洲，因為使用者增長很快，還將繼續使用AWS。

這種告別雲會成為一種趨勢嗎？我的判斷是否定的，Dropbox的案例比較特殊（主要業務就是儲存，競爭激烈，利潤空間有限）。而且，能招到這一大規模專案所需的工程人員（很多來自Facebook、Google和Twitter等公司，已經有過大規模開發和運營的經驗），絕非易事。

何況，之前雖然有Facebook和Twitter這樣的成功案例，但也有前車之鑑：Zynga在轟轟烈烈自建雲之後不久，公司業務萎縮，大量硬體成了負擔……