早期，大家都认为硬件抽象层基于hypervisor的虚拟化方式可以最大程度上提供虚拟化管理的灵活性。各种不同操作系统的虚拟机都能通过hypervisor（KVM、XEN等）来衍生、运行、销毁。然而，随着时间推移，用户发现hypervisor这种方式麻烦越来越多。为什么？因为对于hypervisor环境来说，每个虚拟机都需要运行一个完整的操作系统以及其中安装好的大量应用程序。但实际生产开发环境里，我们更关注的是自己部署的应用程序，如果每次部署发布我都得搞一个完整操作系统和附带的依赖环境，那么这让任务和性能变得很重和很低下。
基于上述情况，人们就在想，有没有其他什么方式能让人更加的关注应用程序本身，底层多余的操作系统和环境我可以共享和复用？换句话来说，那就是我部署一个服务运行好后，我再想移植到另外一个地方，我可以不用再安装一套操作系统和依赖环境。这就像集装箱运载一样，我把货物一辆兰博基尼跑车（好比开发好的应用APP），打包放到一容器集装箱里，它通过货轮可以轻而易举的从上海码头（CentOS7.2环境）运送到纽约码头（Ubuntu14.04环境）。而且运输期间，我的兰博基尼（APP）没有受到任何的损坏（文件没有丢失），在另外一个码头卸货后，依然可以完美风骚的赛跑（启动正常）。
Linux Container容器技术的诞生（2008年）就解决了IT世界里“集装箱运输”的问题。Linux Container（简称LXC）它是一种内核轻量级的操作系统层虚拟化技术。Linux Container主要由Namespace和Cgroup两大机制来保证实现。那么Namespace和Cgroup是什么呢？刚才我们上面提到了集装箱，集装箱的作用当然是可以对货物进行打包隔离了，不让A公司的货跟B公司的货混在一起，不然卸货就分不清楚了。那么Namespace也是一样的作用，做隔离。光有隔离还没用，我们还需要对货物进行资源的管理。同样的，航运码头也有这样的管理机制：货物用什么样规格大小的集装箱，货物用多少个集装箱，货物哪些优先运走，遇到极端天气怎么暂停运输服务怎么改航道等等... 通用的，与此对应的Cgroup就负责资源管理控制作用，比如进程组使用CPU/MEM的限制，进程组的优先级控制，进程组的挂起和恢复等等。
截至今天，业界有一个重要的趋势，即从VM迁移到容器以部署软件应用程序。其主要原因是与VM相比，容器提供的灵活性和低成本。谷歌多年来一直使用容器技术与Borg和Omega容器集群管理平台大规模运行Google应用程序。更重要的是，Google通过实施cgroup和参与libcontainer项目为容器空间做出了贡献。在过去几年中，Google可能已经在使用容器的性能，资源利用率和整体效率方面获得了巨大的收益。最近，微软没有在Windows平台上进行操作系统级虚拟化，立即采取措施在Windows Server上实现对容器的本机支持。
在生产环境中，Docker、Rocket和其他容器平台不能在单个主机上运行，原因是它们暴露于单个故障点。当一个容器集合在单个主机上运行时，如果主机失败，在该主机上运行的所有容器也将失败。为了避免这种情况，需要使用容器主机集群。解决这个问题的第一个最开放源码的容器集群管理平台之一是Apache Mesos。它最初是作为一个研究项目在加州大学伯克利分校开发的，后来在2012年左右转移到了阿帕奇(Apache)。Google采取了类似的步骤来实现一个先进的、开放源码的容器集群管理系统，名为Kubernetes。Docker还启动了一个名为Docker Swarm的解决方案。今天，这些解决方案还处于非常早期的阶段，可能需要几个月才能完成全部功能集，并在生产环境中广泛应用。
微型服务是另一项突破性的技术，而不是一种使用容器进行部署的软件体系结构。微服务是一个Web服务的轻量级实现，与标准Web服务相比，它的启动速度非常快。这是通过在一个服务中打包一个功能单元并将其嵌入到一个轻量级的Web服务器二进制文件中来实现的。
通过考虑上述事实，我们可以预测，在未来几年内，容器可能会占用虚拟机，有时可能会完全取代它们。去年，我与一些企业合作，在POC层面实施基于容器的解决方案。很少有人想接受挑战并将其投入生产。随着容器集群管理系统变得更加成熟，这可能会很快发生变化