如今，将数据迁移上云似乎成为了企业转型的主流，但在企业上云的潮流中，有一位逆行者，Dropbox 从 2015 年就开始将数据从云端迁移到内部数据中心。截止到目前，Dropbox 反向迁移已有 5 年时间，实际效果到底如何呢？

Dropbox 为什么要反向迁移呢？

故事可能要从 2015 年 AWS re:Invent 大会讲起，当时 AWS 首席执行官 Andy Jassy 在主题演讲中表示：“上云之后，企业中最为稀缺的软件工程师就可以从繁重的基础设施运营工作中解放出来，真正帮助企业实现业务的差异化优势。”

当 Andy Jassy 在会议上大谈云计算的好处时，曾是 AWS 明星用户的 Dropbox 在早些时候却选择离开AWS，离开云，朝着另一个方向发展。2015 年 2 月至 10 月，Dropbox 成功将 90% 的用户数据从云端迁移至内部数据中心，这就是 Magic Pocket 项目。

为什么 Dropbox 要反向迁移呢？一个比较直观的原因就是成本，Dropbox 的工程副总裁 Aditya Agarwal 曾表示，“云计算公司也是要赚钱的，规模大了以后，自建反而可以节省大量资金。”

其次，云计算公司不足以支撑 Dropbox 的业务规模和需求。2016 年，Dropbox 公司基础设施副总裁 Akhil Gupta 在博客中写道：“我们一直很清楚，建立自身业务所需要的基础设施只能由我们自己亲手构建。因为开源社区中的任何成果都不足以可靠支撑我们的庞大业务规模与具体需求。事实上，全球范围内很少有哪家企业拥有像我们这样严苛的存储需求。”

第三，性能问题。Dropbox 认为自身产品的核心竞争力是性能，如果在内部数据中可以从端到端自定义整个技术栈，在特定的用例下提升性能。另外，Dropbox 的块存储与其它公司不同，因此可以根据产品规模和特定的用例来使用硬件和软件，提升单位经济效益。

从 Dropbox 反向迁移案例中，我们能获得什么

Dropbox 刚开始进行反向迁移时，大家都认为是“偶发事件”。五年过去了，其它企业和组织也意识到了公有云存在的局限，反向迁移有其存在的合理性。在这样的背景下，Dropbox 的 Magic Pocket 项目自然成为了一个值得研究的案例。

从 Dropbox 反向迁移案例中，我们可以获得什么样的经验呢？

以更小的时间窗口来规划

Dropbox 公司数据中心物理基础设施负责人 Latane Garetson 在接受采访时表示，“Dropbox 公司制定了一项计划，我们关注自身容量现状，并借此确定容量的之后增长预期。”根据惯例，他带领的团队为数据中心建立起规划模型。

Garetson 带领的团队为数据中心建立规划模型，Dropbox 采取了一种相当小众的容量规划方法。Garetson 团队以短期计划为基础，将迁移周期划分为 6 个月甚至是 3 个月，并把时间窗口控制在这样的水平，以细粒度方式专注解决具体问题。

Garetson 自己也认为这是一种“离经叛道”的处理方式。以更小的时间窗口做规划，并不意味着Dropbox 放弃进行年度增长预测，只是在年度增长预测中，其与软件团队的沟通与预期交付周期总会出现多次变化。因此，Dropbox的做法是，在整个迁移过程中，基础设施团队与内部软件团队紧密合作，首先确定今年的运营期望是什么，然后据此进行容量模型预测，按照季度、月度、甚至是星期来对预测结果做持续更新。

软件先行，硬件再跟上

大多数 IT 部门部署工作的起点是先获取或者自主构建硬件，然后对硬件进行划分和部署，并将其整合到服务集群中，与业务软件融合。而 Dropbox 的做法正好相反。

Dropbox 是软件团队先行，软件团队根据业务活动先做出容量预测，然后为数据中心设计出服务器模板，团队中的开发者按照“图纸”进行工作，预先完成服务配置与服务器扩展规划。

打个比方，可能比较类似于麦当劳的得来速餐厅，软件团队在窗口处下达订单，将上述配置结果按顺序交付给硬件团队，后者根据预期容量需求完成生产部署。由于软件团队方面已经制定了配置计划，因此新增服务器拥有自配置能力，不再需要硬件工程师分担额外的配置压力。

Garetson 认为整个迁移过程中最重要的因素是构建时间。2015 年，Dropbox 把构建周期从六个月缩短为三个月。而制定的年度规划方案中，也会设置时间节点，如果预测结果发生变化，那么就可以根据节点对规划作出调整，从而将实际的构建周期控制在三个月。

构建周期的缩短，说明 Dropbox 对项目的控制力较强。一旦某项构建计划因意外原因而推迟，Dropbox 可以随时将其取消，并在不中断正常业务的同时启动新计划。从微服务协调到分布式软件组件调度（当组件未响应时及时切换），Dropbox 认为只要规划本身关注总体需求（而非一时一地的滞后问题），公司就能够更灵活地实现容量构建目标。

容量变化

数据中心的容量变化也是需要时刻关心和密切关注的，Dropbox 技术团队能够在当前窗口内的任意给定时间内，根据新容量的交付规划对现有库存进行建模。通过这种方法，Dropbox 可以将整体容量目标拆分成多个可行的小项目。

相比于大多数存储用途的数据中心，过去五年中，Dropbox 基础设施中的机架密度始终保持增长。密度的提升，意味着总机架占地空间降低的同时，客户可用的存储容量却一直在快速上涨。Garetson 表示：“相当于我们拥有了更多的物理空间。随着密度的增加，以往需要 100 台机柜才能满足的需求，如今只要 30 台就可以解决。”

对于云存储厂商来说，动态增加容量建模的方法似乎正是最理想的规划方法。到目前为止，大多数企业的数据中心都会根据核心服务与应用程序的空间与容量需求进行设计。Dropbox 则反其道而行之，以存储介质的增长作为前提，以此推断能够承载多少核心服务，最终将规划周期控制在 6 个月以内。如果其它类似场景的企业，能够和 Dropbox 一样建立一套规划模型，那么就可以将服务运营体系保持在内部数据中心，而不是只有上云一个选择。

参考文章：

https://www.datacenterknowledge.com/manage/dropbox-s-reverse-migration-cloud-own-data-centers-five-years

创作场景

从云到数据中心，Dropbox 五年反向迁移的经验总结