随着容器发展模式逐渐成为主流，容器堆栈本身也在不断发展。现在，企业看到了容器的价值，开发和业务重点正在从引擎转移到增加更多复杂的功能，以便更直接地获得业务收益。事实上，在短短几年内，容器已经从没有管理、技术精湛和社区分化的现状转变成为更加高雅、商用化的IT包，并且完全遵循由跨厂商的开放容器生态。
在最基本的层面上，Linux容器使得企业能够将应用程序域整个runtime环境打包并隔离，以运行所需的所有文件。这使得在保留全部功能的同时在环境(开发、测试和生产等)之间迁移容器化应用变得容易。Linux容器通过分隔责任区域来帮助减少开发和运营团队之间的冲突，开发人员可以专注于他们的应用程序，运营人员则专注于基础设施。
而且，因为Linux容器是基于开源技术的，所以一旦得以应用，组织就可以获得最新和最大的技术进步。容器技术(如CRI-O，Kubernetes和Docker)可以帮助简化团队，加速和协调应用程序开发和部署。
事实上，容器正处于IT不断发展的进化阶段，他们正在成为创新的平台。从复合应用程序和微服务到快速应用程序开发以及DevOps的各种排列，企业IT现在处于另一个转折点：路在何方?
以下是组织和开发人员现在需要了解的关于容器堆栈以及如何改变的八件事情。
要素
要运行容器，需要整个企业容器基础设施：Linux、runtime、编排。这个堆栈通常由LDK-Linux、Docker和Kubernetes组成，但随着容器技术的发展，这一趋势也在不断发展。Docker并不是唯一的通用容器runtime，新的容器似乎每天都在冒出来。而且，专用的容器runtime正在开发中，它能够让用户推进边界，如在隔离的虚拟机中运行容器。
Kubernetes为王
容器技术使得企业能够更有效地开发、测试、部署和维护应用程序，这是当今任何组织的竞争命脉。但是容器本质上有很多移动部件，而且大多数公司都有很多容器。Kubernetes Orchestration，一款用于自动化部署，扩展和管理容器化应用程序的开源系统，使企业能够充分发挥容器的优势。除此之外，还有其他一些选择，最著名的是Mesos和Swarm，但是不得不说Kubernetes已经成为了行业的标准。
CRI和CRI-O的角色
去年，Kubernetes项目引入了它的容器运行时接口(CRI)，这是一个插件接口，它提供kubelet，这是一个用于创建容器和启动容器的集群节点代理，可以使用不同的OCI兼容容器运行时而不需要重新编译Kubernetes。在这项工作的基础上，CRI-O项目(最初称为OCID)为Kubernetes提供了一个轻量级的runtime。CRI-O使开发人员能够直接从Kubernetes运行容器; 只要容器图像符合OCI标准，CRI-O就可以运行它。这消除了对独立运行时间的需求，降低了复杂性并提高了可靠性。
容器标准
容器的标准化对于企业更广泛和更有效地采用容器起到推动作用，但对于公司和开发团队来说，能够将这些标准放在其环境中做出关于容器堆栈的正确决策是非常重要的。现在要关注的标准组织包括Open Container Initiative(OCI)Image Specification(1.0.1版刚刚发布); OCI运行时间规范(也是版本1.0.1); Kubernetes Container Runtime Initiative(CRI);容器网络接口(CNI)和Docker容器网络模型(CNM)。
各种开源项目的角色
Google工程师基于内部平台开发的Kubernetes可以说是目前容器领域最活跃的开源项目之一。虽然Kubernetes可能是最明显的开源容器项目之一，但还有其他几十个正在推动容器栈的项目。例如，Origin是OpenShift的上游项目，它使组织能够开发，部署和管理容器。组织和个人都可以通过成为这些社区中的一个或多个社区的积极贡献者，更充分地利用容器。
公有云集成
随着企业扩大其容器堆栈的应用，利用公有云受到企业重视。例如，现在很多AWS服务都可以通过内置在OpenShift Container Platform中的Service Broker界面访问。这使得AWS用户可以更轻松地在OpenShift中配置和部署服务，并为企业需求提供基于Kubernetes的单一可扩展应用程序定义。
无聊是件好事
今天的IT专业人员不会考虑Linux内核，因为这很无聊。真正的创新都是在内核以上，容器runtime接口也是如此。事实上，当你在考虑容器堆栈时，这个值已经不再是runtime级别的了。runtime已经成为无聊的工作，这意味着组织不必担心或投入资源。相反，他们可以把重点放在如何通过容器生态系统的发展以及容器在自己的组织中的使用来创新。
应用程序开发重定义
Linux容器的潜力比重新定义开发乃至操作都要大的多。它们也加速了应用程序本身的重新定义，由于容器的原因，我们所知道的整体式应用程序堆栈可以分解成几十个甚至数百个细小的单一用途的应用程序，这些应用程序组合在一起时，可以执行与传统应用程序相同的功能。这使得每个单独的部分都可以被重写、重用和管理，远比单一应用程序更有效，从而提供了一个完全由微服务构建的真正的复合应用程序，可以轻松扩展以满足需求。虽然微服务架构并不要求使用容器，但大多数转向微服务的组织都会发现容器是实现应用程序的最佳方式。
