云服务和SaaS厂商创造了微服务的概念和“云原生”模型，以便在持续开发和运营过程中实现高效扩展。对于Facebook、Google或eBay这类始终在线的全球服务而言，传统的方法已不适用。容器与Docker作为此类微服务的终极打包工具应运而生，而Kubernetes、Docker Swarm和DC/OS这类新的编排平台则负责其部署、调度及生命周期的处理。Serverless及FaaS基本上就是这个模型更加自动化的一种演进。
我们希望交付的是随着时间推移而演进或扩展的弹性应用。实现的方式是将应用打散成多个层级（微服务），每一层都具有自己的弹性扩展能力，然后通过可靠的消息在这些微服务之间进行通信。
如果我们希望能动态地进行扩展、处理故障或修改版本，微服务就不能是有状态的。与传统应用不同，微服务使用的是不可变镜像，并将配置、日志、状态及数据储存在弹性云数据服务（对象、NoSQL/NewSQL、日志/消息流）中。
云数据服务通常是将一组商用服务器（具有本地磁盘）集群起来构建而成。我们要么使用预集成的云提供商数据服务，要么使用开源或商业软件来运行自己的数据服务。
开发人员和企业主立即就能感受到云原生方式的益处：这让他们可以使用一个敏捷的、持续的方法更快地进行应用开发，同时其弹性扩展可满足需求的波动。
传统基础设施团队与厂商和云用户与提供商的想法不同。他们依然以虚拟机、虚拟网卡和虚拟磁盘（虚拟基础设施，即“私有云”）来看待这个世界，并试图让容器兼容现有的做法。这意味着他们将重心放在重构遗留的或单体的应用，以便其运行于容器中，从中获得的打包自动化好处最少，敏捷、弹性及CI/CD不在其列。他们也可能将那些应用保留在虚拟机中，并将其遗忘。
上周在奥斯汀举行的DockerCon上，我看到一些厂商试图让容器像VMware或OpenStack那样工作。最极端的例子是将SAN或超聚合块存储作为“容器问题”的解决方案。其间，我与三个主要存储厂商的交流大致如此：
他们：我们负责编排容器块存储卷的创建、配备文件系统、快照、去重等等。
我：但是我为什么需要这个，Docker提供了一个（不可变的、去重的）镜像文件系统，并且持久化数据是可选的，期望的是文件或数据库抽象层（不是虚拟磁盘）吧？
他们：哦，这就是为什么我们复杂的自动化系统要分配并配备块空间、在磁盘卷上创建一个（具有固定容量的）文件系统并将其附加到容器中。
我：但是磁盘卷无法在微服务之间共享（对于弹性而言这是非常基本的），而我希望容器是弹性的而非固定的。我可以使用一个共享文件系统，为什么还要让自己陷入一堆配置磁盘容量和格式化文件系统的麻烦中？难道我不能将共享文件系统挂载到容器中？
