无论你如何理解政治，毫无疑问UBER就是创新的代名词，正如它颠覆了传统的交通运输行业在这个分享体系中的领导地位。但是问题在于最快的创新者往往会遇到一些问题，正如微软、苹果、亚马逊都曾经遇到过一样。问题在于一旦你开始创新并且旗开得胜，你的进度会快到你自己都无法跟上，以至于有时会迷失对于大局的掌控，从而不得不暂缓进度边走边建设。
这就是Casper S. Jensen今年初作为软件工程师刚刚加入UBER计算机平台部门时候发现的故事。
在Docker欧洲会议的第一天，Jensen开始他的演讲即是关于UBER如何保持简单友好的用户交互界面的同时，在背后支撑的是实际上是一个非常巨大的体系，用户程序仅仅是冰山一角，底下是无数的功能在支撑它。毕竟，当前UBER在69个国家有自己的市场营销和管理规则，每天运行上百万次，超过4000名员工同时工作在这个平台上。
传统的软件开发模式（bold）
当时Jensen以及其他四位组员都是刚刚加入UBER不久，他们迫切需要寻找一种解决方案来应付日常工作中为数不少且日益增长的失败和挫折。
在刚刚过去的那个冬天，他们的开发流程还是如下所示：
1. 写服务RFC（Request for Comments）-Uber的开发流程非常重视反馈机制。在开始任何新的东西前，他们开始描述新的服务需求系统架构和变更理由，然后分发到相应的邮件列表。
2. 等待反馈，比如：“你有没有听说过有哪些家伙在其他地方做同样的事情”，这里主要专注于捕捉早期错误。
3. 开始写必要的基本框架。
4. 开始开发服务。
5. 等待基础架构团队编写服务框架。
6. 等待IT部门的服务就位。
7. 等待基础架构的团队服务就位。
8. 部署到开发服务器和测试。
9. 部署到生产环境。
10. 监控迭代。
他描述的步骤五到7年为：“真的，真的很痛苦的一部分。这些步骤可以很容易地耗费数天时间，在某些情况下，甚至几个星期。”。“这是为什么？ 这不是因为这些步骤本身很困难，大部分的脚步都是现成的，新集成涉及的大约只有几十行。”
“这么小题大做的原因很简单，在这个公司内部只有很少的一部分人真正知道怎么做事，而不至于破坏其他已有服务”。这些细小错误积少成多，就如同一个个的破折号，大幅减缓了所有事情的进度。
直到2015年2月，一封内部邮件内部流转并设定了如下目标：
Jensen描述他们的期望如下：
- 允许服务拥有者保留部分专有空间，在一定范围内他们可以任意方式安装任意程序，前提是不破坏其他服务。
- 在这种模式下，他们可以做任何事并不受打扰。
我们必须做点什么来改变现有模式同时不要破坏已有的服务。
UBER自己需要克服的障碍
当你公司的基础设施在高速发展时，你也会有一定压力。包括如Jensen所说“我们组有时不得不如此，因为公司的其他部门都在飞奔。”
UBER需要的不仅仅是全天候的可用性和正常运行，以及无数本地化的功能。“没有人见识过UBER的所有功能，我们所了解的仅仅是我们所工作的一小部分”。他举例说，就像UBERPOOL,UBERKITTENS,UBERICECREAM，以及UBEREATS，等。每天都迫不及待的不断增加新的功能。UBER另人眼花缭乱的成功是基于其全方位的高速增长，包括数据中心，服务器和基础设施。他们需要一个能够保持这种增长的解决方案。
“我们希望能有很容易的流程，很方便的基础设施，使开发者可以真正快速添加功能。其中之一，也是最重要的部分之一，是创造新服务的流程”。Jensen说。“我们意识到这意味着Docker”。他说决定迁移到Docker上来是很容易下的决定。“因为这非常容易解释，只要人们曾经去读过它，并且理解它的基本概念即可。”他说Docker对于开发者社区而言是非常容易推销的概念，每个人都迫切期望在其中找到自己喜爱的容器。
克服容器成长中的阵痛
他们对自己说“我们都能编写代码，这应该很容易吧？过两天，我们就大功告成了。“事实上没这么容易。虽然他们在二月份做出了这个决定，就一直持续到了盛夏才最终走上了Docker之路。
Jensen解释道，“基于Docker，虽然一切都只是改变了一点点，但是这需要我们转换思维。”
对于Docker应用，其中最大的障碍在于的内部集群管理系统uDeploy。它需要做持续的滚动升级以及内部回滚的支持。它的多个触发器用于出错报警，比如当健康检查、电路突然出错时。这包括负载测试和集成测试用以保证出错时快速回滚。uDeploy包括：
- 每周4000升级
- 每周3000构建
- 每周300回滚
- 在系统管理的600多个服务
根本就没有办法摆脱或淘汰uDeploy，所以UBER团队决定同时部署传统的服务以及基于Docker的服务。
“这也意味着，我花了很多时间去仔细检查我们已经实现的所有功能，并为之增加对于Docker服务的支持”，Jensen说道。“对于任意在uDeploy实现的标准输入和标准输出，我们都必须在Docker做同样实现”。
他们发起的Docker并没有太多计划，这让Jensen意识到他们在最初给了开发者太多的自由。“事情不应该是这样的。”他说道，贴紧他的手指。“你真的需要重新思考基础设施的所有部分。”
Jensen说，如果你未雨绸缪，真正关注的基础设施和Docker如何在其中发挥它自己的那部分角色，docker的最终结果将会顺利得多，也好得多。
Docker如何推进新的可收缩的UBER服务
现在的UBER已经有约三分之一实现了容器化，但是我们期望的是100%。为什么？当然，转型过程是痛苦的，但是结果是我们所希望的，那就是摆脱以下阻止我们可持续化部署最痛苦的三个点。基于Docker,我们可以彻底摆脱它们：
- 等待基础架构团队编写服务框架。
- 等待IT部门的服务就位。
- 等待基础架构的团队服务就位。
现在，他们可以不必再拷贝之前的项目、或者是手工实现一切必须的基础架构，而是直接使用一系列工具其中包含所有配置和基础文件。他说，基于标准化的服务，这一切可以再几十分钟内一帆风顺的下来，而在之前我们得花上几个小时甚至几天。
除此之外，UBER也非常认可Docker能够帮助消除团队之间的依赖性，提供了更多的自由，因为成员不再依赖于特定的框架或特定版本。现在框架和服务使用者现在可以尝试新的技术和管理他们自己的环境。
原文地址：How Docker Turbocharged Uber’s Deployments
译者介绍：王旭敏，Nokia开发工程师，关注云计算、高性能或可用等架构、容器等。
