通用操作系统已穷途末路？

最近我在Twitter上看到了一则饶有意思的聊天，不由得想起了可能不是每个人都意识到这一点：通用操作系统正从我们的服务器上被挤掉。

你所说的通用是啥意思？穷途末路又是啥意思？

首先，有必要澄清一下。我所说的通用操作系统是指大多数人如今用于运行服务器工作负载的操作系统，无论是RHEL、变种版本（比如CentOS或Fedora或Debian），还是衍生版本（比如Ubuntu）。我们还包括Arch、各种BSD 和opensolaris版本以及Windows。我所说的穷途末路其实不是说它们消亡或不再有用。我的假设是，它们不再成为我们启动新服务时使用的默认操作系统，最初很缓慢，后来比较快。

容器的虚拟机管理程序

本文的第一个部分包括讨论我所说的容器的虚拟机管理程序，如今它们更可能被称为CaaS，也就是容器即服务。我甚至猜测，VMWare将不得不在这个领域交付某种产品（看看vSphere Integrated Containers和Photon OS方面的工作）；把OpenShift排除在外也许为时过早（OpenShift 3主要是作为一种Kubernetes发行版而交付的）。我很快会回过头来解释为何这对你钟爱的Debian服务器构成威胁。

竞相成为PID1

对任何运行过Docker的来说，你可能为这个问题而纠结：主机进程监管工具（可能是systemd）的角色始于何处，容器进程监管工具（Docker引擎）又终于何处？你非得与两者都要直接交互吗？

现在设想一下：你服务器上的所有软件都在容器里面运行。为何现在我需要两个百分之百重叠的进程监管工具？明显的答案是不需要，这就是为什么Docker与systemd之争不可避免。请注意：这也不是Docker所特有的。对cri-o（https://github.com/kubernetes-incubator/cri-o）来说，容器进程生命周期管理是其范围内的职责。

容器成为软件单位

隐藏在我那个假设背后未说明的是，容器成为了软件的单位。我这里的意思是说，我们构建或购买的软件将日益作为容器来发布、作为容器来运行。容器将随带足够多的元数据，以便运行时环境能确定需要什么资源来运行容器。

别低估了来自这种共享契约的简化性假设的数量。至少，在主机层面，你可能需要大量的近乎相同的主机，它们都向容器调度程序公共其功能。

操作系统的实施细节

我们在这个市场亲眼目睹了纵向集成的堆栈（vertically integrated stack）大行其道。

Docker for Mac/Windows/AWS/Azure交付时随带自己的操作系统，这种Alpine Linux衍生版名为Moby，它并不是为最终用户直接管理而设计的。
来自CoreOS的Tectonic是一款Kubernetes发行版，它在受管理的CoreOS主机集群上运行。操作系统的大部分由频繁的原子滚动更新版来加以管理。
来自Red Hat的OpenShift Enterprise是另一种Kubernetes衍生版，这回它是在Atomic主机上运行。
Pivotal CloudFoundry交付时随带IaaS、主机操作系统、内核、文件系统和容器操作系统，它们都共同经过了测试。

在所有上述情况下，操作系统是更高级软件的一个实施细节。它不是旨在直接管理，或者至少不是与你如今运行的通用操作系统同样的程度加以管理。

这就是为什么说，对运行服务器的大多数通用操作系统而言，它们已穷途末路。运行容器的机器会运行更单一用途的工作负载，你运行的软件越来越多地会在容器里面运行。

你之所以会这么做，而不是自行构建一切软件，原因在于兼容性。无论是内核版本、文件系统驱动程序、操作系统变量，还是让你的操作系统版本与我的操作系统版本不一样的众多变化因素，构建和测试在各个地方都可以运行的软件是一项艰巨而无尽头的任务。商业因素在这方面也起到了作用；毕竟，能够为所有人支持经过验证的单一产品有莫大的优点。

带来的影响

此举带来了许多影响，看看它对早期采用者和企业客户来说有何影响颇有意思。