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在轰轰烈烈自建云之后不久，公司业务萎缩，大量硬件成了负担……