Docker的发展势态如同森林大火，势不可挡。这项新型的Linux容器技术引燃了一路上的一切东西，面对其迅猛发展的势头，我们许多人还没有回过神来。Docker不仅是有史以来最受欢迎的开源项目之一，它还从根本上改变了人们考虑构建应用程序的方式。
基于Docker的应用程序背后的许多理念从严格意义上讲并非很新颖，但Docker给那些旧观念带来了全新视角。借助许多云开发实践，Docker促进了最佳实践，比如12-Factor应用程序。这些最佳实践当初是为了构建基于PaaS的应用程序而开发的，如今普遍适用于基于Docker的应用程序。
我们能从Docker热潮中学到什么?不妨看一看这四个方面。
1. 微服务架构大行其道
整体式云应用程序的程序开发已玩完了。取而代之的是微服务架构，这种架构可以将大型应用程序及所有内置功能分解为更小的、目的导向的服务，而这些服务又可以借助通用的REST API与对方进行联系。
上世纪90年代，有一种类似的概念，名为基于接口/组件的架构。而最近，面向服务架构(SOA)似乎迎来了一些发展势头。如今，微服务概念已成为Docker社区的一个标准文化基因，流行的趋势是将应用程序分解为分离的、极简的、专门的容器，这些容器专注于只做好一件事。
完全封装的Docker容器能够为微服务应用程序构建一种高效的分布式模型，从而支持微服务。这让规模较小的开发团队有机会得以使用较大规模的架构(比如Facebook和推特使用的那种架构)，因而改变了云开发实践。
2. 让开发和运营的关系更紧密
尽管Puppet、Chef、Salt及其他工具引领了开发运营(DevOps)潮流，但这些工具在运营团队当中比在开发人员当中更受欢迎。
Docker是第一种在开发人员当中与在运营工程师当中一样受欢迎的开发运营工具。原因何在?因为开发人员可以在容器里面工作，而同时运营工程师可以在容器外面工作。
开发团队采用Docker时，他们为软件开发生命周期增添了一层新的敏捷性。一大区别在于一致性。基于Docker的应用程序在笔记本电脑上运行与在生产环境中运行完全一模一样。由于Docker围绕应用程序封装整个状态，你没必要因底层操作系统存在的架构差异而操心失去依赖项或软件缺陷。
#p#
3. 为持续集成确保一致性
持续集成能够实现代码测试自动化，因而一向是减少成品中软件缺陷数量的好方法。不过持续集成存在两大弊端。
首先，很难封装所有依赖项。Jenkins和Travis等传统的持续集成/持续交付(CI/CD)技术通过获取源代码库，构建应用程序组件。虽然这种方式相对适用于许多应用程序，不过二进制依赖项或操作系统层面的变化会让代码在生产环境中运行起来与在开发/测试/质量保证环境中运行起来略有不同。由于 Docker将应用程序的整个状态封装起来，更能确保代码在开发/测试/质量保证环境中与在生产环境中运行起来一模一样。
其次，持续集成并不是为微服务架构构建的。持续集成的设计思路其实假设应用程序位于一个代码库当中。然而，Docker最佳实践鼓励各个Docker容器都松散耦合的微服务架构。这带来了新一代的持续集成/持续交付工具，比如Drone和Shippable，它们都是从头设计的，设计当初就着眼于Docker容器。这些工具让你可以开始测试从多个代码库获取的多容器应用程序。
4. 确保最佳容器彼此协作
Docker 并不调整你自己的服务窗口，比如Hadoop、Nginx或MongoDB，而是鼓励开源社区在Docker Hub中相互协作、微调容器，这个公共代码库让每个人都可以使用同类中最佳容器。由于Docker容器能够封装状态，它们让你可以更灵活地配置运行起来最佳的软件。
因此，Docker让任何人都可以充分利用封装方面的最佳实践(具体表现为结合别人的容器)，从而改变了云开发实践。这就像云组件有一套乐高积木，它们终于有了组合起来的标准。
云计算领域的乐高积木
时常出现这一幕：一项新技术出现后，颠覆了现状。就在不久前，云计算领域还以按需提供、API驱动的虚拟机以及围绕虚拟机建立的服务为主。这带来了一系列旨在克服虚拟机局限性的工具。
Docker 在迅速改变云计算领域的规则，彻底颠覆云技术格局。Docker为持续集成/持续交付、微服务、开源协作和开发运营铺平了道路，不但改变了应用程序开发生命周期，还改变了云工程技术实践。每天，成千上万新的开发人员在开心地重新设计或构建基于Docker的新应用程序。想在不断变化的世界保持竞争力，关键是要明白Docker热潮会涌向何方。
原文标题：4 ways docker fundamentally changes application development
