目前，应用程序容器和虚拟化之间存在激烈的竞争。然而，对我来说，像 www.boycottdocker.org 这样的比较完全没有抓住重点。应用程序容器并不是要取代虚拟化。我相信大多数应用程序容器直接运行在 VM 之上，或者运行在像 OpenStack 这样的自动化基础设施（例如云）解决方案中。
在这篇文章中，我将给出我对这个主题的观点，但首先我应该提到我是 Docker 容器等应用程序容器的坚定支持者。即便如此，我还是会尽量让这篇文章保持中立。
技术周期
就像股票市场涨跌一样，不同技术周期的使用也是如此。我们都看到技术几乎消失然后又重新出现。例如在 1996 年，许多应用程序服务器使用服务器端 JavaScript (SSJS) 来开发应用程序（例如 Netscape 的 LiveWire、Microsoft ASP、BroadVision 一对一服务器）。然后 Java 和 Java EE 出现并改变了服务器端业务逻辑的技术使用。最近，SSJS 在 Node.JS 和 Vert.x 等应用程序服务器中再次获得关注。
我相信这些技术周期的原因更多是基于回声系统和开发人员的易用性。自 1996 年以来，JavaScript 确实取得了巨大的发展，但我相信 SSJS 正在获得牵引力，因为它或多或少是 Web 开发的事实标准。使用相同的语言开发客户端和服务器端可以使某些组织更加有效。今天也有更好的工具，包括 IDE 支持、测试框架等，适用于 SSJS。
最佳技术因您的观点而异
不同的技术有不同的好处，片面的比较不会对它们的适配产生太大的影响。举个例子，当 Java 第一次开始受到开发人员的关注时，那里有大量争论性的文章/研究将 C/C++ 与支持 C/C++ 的 Java 进行比较。从 2000 年到 2005 年，我曾在一家名为 BroadVision 的公司工作，而许多其他供应商转向 Java，而 BroadVision 则坚持使用 C/C++、Corba 和 SSJS。从技术的角度来看，这是最好的决定。 C/C++ 性能更高，Corba 优于 Java EE 的早期版本，对事务和安全性有很好的支持，而 SSJS 比 JSP 更容易。然而，开发过程（开发、测试、产品）等非常糟糕。由于我们的许多客户都在使用 SPARC，所以我有一台非常昂贵（而且速度不是很快）的便携式 SPARC 笔记本电脑，这样我就可以为客户开发 C/C++ 组件。我们的许多客户没有那么奢侈，不得不在服务器上编译代码，增加他们的开发往返。
IMO 有两个 Java 的主要好处。首先，JDK 可以免费用于开发，许多应用服务器供应商提供试用版，以便开发人员可以轻松地开始使用它。其次，一次编写，随处运行的范例意味着开发人员可以在他们的台式机/笔记本电脑上进行开发，而无需在服务器上进行编译。
为什么我们应该关心应用程序容器
不同的应用容器技术有不同的技术弊端，但决定一项技术是否流行的是这些弊端是否与当前的回声系统相关。 DevOps 和 CI/CD 等趋势要求更轻松地打包和交付应用程序。另一个趋势是微服务，其中大型整体应用程序被分解为可以独立扩展的较小部分，从而降低了对容器的性能要求。最后，云自动化还降低了修补和维护应用程序容器的需要，相反，人们可以只部署一个新版本的容器，而无需登录和手动修补容器。
这就是为什么我相信像 www.boycottdocker.org 这样的比较最终不会有任何影响。那么应用容器会取代虚拟化吗？我不这么认为。虚拟化非常适合抽象硬件，并且还会存在很长时间，但我们可能会转向运行许多应用程序容器的更大的虚拟化主机。
声称 Docker 是一个锁定，只是因为它不能在 Windows 或其他非 GNU/Linux 操作系统上本地运行也有点强大。 Docker 容器是一个开源项目，它使用了 Linux 的多种技术，例如 group 等。因此它确实需要 Linux，但不一定是 DockerOS。例如，Red Hat Enterprise Linux 和 Fedora 也支持本地运行 Docker。 Docker 公司将不得不找到一种方法将最初的成功转化为可行的业务，但如果他们以一种锁定的方式这样做，其他开源社区将做出反应并确保应用程序容器与 Docker 一样仍将是一种开放格式。
声称 PaaS 平台价格昂贵在许多情况下可能是正确的，但正如在所有新技术中一样，我们将看到价格调整以匹配它们带来的价值。 Red Hat OpenShift Enterprise 是一个 PaaS 平台，可以安装在您自己的数据中心，使用虚拟化或云基础架构，并且不需要您按分钟付费。
