无论你的组织有什么要求，也不管你为应用程序选择容器还是虚拟机，在企业软件世界中始终有一条基本规则在发挥作用：变革是困难的。
作者 | Heather Joslyn & Lawrence E Hecht
策划 | 云昭
几年前，不少技术文章都会输出这样一种观点：Linux容器和虚拟机是数据中心中两个截然相反的组件。诚然，尤其当一项新技术被采用时，这种现象就会很明显：在新技术的炒作周期中，新事物往往会被推向行业的每一个角落，并且寻找战胜旧软件、硬件组合的新的宣传点。
你可能还记得JavaScript何时将接管服务器端，或者虚拟现实何时将彻底改变教育。事实上，这些技术最终只是找到了“舒适的”使用领域，而不是取代其他。然而，事实上，很难判断某项技术最终会在哪里最有用，以及在哪里会被更好的选择所取代。
现在，Linux容器和虚拟机不再是全新的，它们已经成为通用软件开发人员为各种场景考虑的工具。现在，我们想提供一个指南，指导每种技术在当今的混合云环境中何时何地适用。
1、容器？太大的用不了！
也许,最简单的决策方法是根据应用程序的大小和复杂性。容器是一种应用程序打包技术。容器可以在没有Kubernetes的情况下直接部署到操作系统中，而且通常有非常好和有效的理由来使用它们。这也是我们与Red Hat Enterprise Linux和Ansible的优势战略的一部分：容器是一种简单、可复制的部署软件的方式，同时最大限度地减少迁移部件。
不少其他类似的或是竞对的技术，具有许多相同的功能，如unikernel、Wasm等。因此，虽然容器可能是当今部署应用程序的正确方式，但随着该模型的优化和采用新类型的部署模型，未来可能会有一些变化。
简单地说，有些应用程序太大、太复杂，无法按原样放入容器中。我们通俗地称它们为单体。需要注意的是，这里没有技术限制：没有CPU/内存阈值，你会放弃容器。相反，这是基于代价的考量。
例如，一个安装程序将数据库加中间件加$thing1和$thing2等部署到一个服务器上，按原样进行容器化可能会很困难。可能需要对应用程序进行“现代化”，以解耦组件和/或采用对容器化更友好的应用程序框架和/或运行时。其中一个例子是将Java应用程序从SpringBoot移动到Quarkus。
2、不是所有的容器都要上K8s
开发者和管理者，无论他们是否采用了新兴起的云原生架构或DevSecOps方法，相信都会采纳容器，原因有很多。应用程序容器化的好处包括速度、安全性、可移植性和简单性。然而，这并不意味着将虚拟机彻底抛弃。
真正的问题在于，“我想把容器化应用程序部署到Kubernetes，还是直接部署到（虚拟化的）操作系统？”这里有很多因素需要考虑。
首先需要注意是应用程序的要求。应用程序是否需要作为一个单独的节点持续运行而不中断？Kubernetes不会在节点之间无中断地迁移应用程序组件。它们被终止并重新启动。如果你的应用程序不能容忍这种行为，那么Kubernetes就不适合了。
其次，考虑应用程序的各种组件的状态也很重要。如果有问题的应用程序依赖于第三方组件，那么这些组件可能会限制容器的使用。许多第三方供应商，尤其是在以虚拟机为中心的行业，在创建Kubernetes就绪/兼容版本的软件方面进展缓慢。这意味着你既可以部署虚拟机，也可以自己承担在Kubernetes中支持其软件的责任。
甚至在评估这些选项之前，认真审视一下组织内部可用的技能也是很重要的。你的团队是否具备处理Linux容器的技能和能力？你是否拥有或愿意为Kubernetes构建和获取必要的专业知识？这扩展到API驱动的消费和配置。你的应用程序和开发团队是否需要/想要使用API消费和配置平台的能力？
这在不管是私有云，还是公共云和Kubernetes中都是可能的，但通常更复杂、更难预处理，需要专业自动化团队的大量协作。当涉及到公共云时，团队需要在其使用的每个公共云中拥有特定的专业知识，从而增加了另一层需要管理的复杂性。这是一个Kubernetes可以同质化并进一步实现可移植性的领域。
3、基础设施效率
在大多数情况下，一个拥有数万到数千个实例的规模的应用程序在Kubernetes集群上运行的效率要比在虚拟机中运行的效率高得多。这是因为容器化组件被打包到可用资源中，并且需要管理和维护的操作系统实例更少。
此外，Kubernetes可以更无缝、更轻松地扩展和缩小应用程序。虽然可以创建新的虚拟机来扩展应用程序组件或服务的新实例，但这通常比Kubernetes慢得多，也更难。Kubernetes专注于在应用层实现自动化，而不是在虚拟化层，尽管KubeVirtualt也可以实现自动化。
基础设施效率也意味着成本影响。这对每个组织来说都是不同的，但对一些组织来说，减少虚拟机的数量将影响他们向操作系统供应商、系统管理程序供应商和硬件供应商支付的许可费。然而，这可能会也可能不会被Kubernetes的成本和管理它所需的人才所抵消。
在安全方面还有其他考虑因素。Kubernetes是一个共享的内核模型，其中许多容器表示许多应用程序在同一节点上运行。这并不是说它们不安全——Red Hat OpenShift和部署到Red Hat操作系统的容器利用了SELinux和其他安全功能。
然而，有时这还不足以满足安全需求和合规性需求。这留下了几个进一步隔离的选项：部署许多Kubernetes集群（很多人都这样做）、使用Kata容器等专门技术或使用完整的虚拟机。
4、写在最后：别轻易更改
无论你的组织有什么要求，也不管你为应用程序选择容器还是虚拟机，在企业软件世界中始终有一条基本规则在发挥作用：变革是困难的。有时，如果某个东西正在运行，就没有理由移动、更新或迁移它。如果你的应用程序在虚拟机上可靠地运行，并且公司没有推动将其迁移到其他地方，那么只要它能得到可靠的支持，也许它就可以在原地运行。
有时，组织内部变革的最佳场所并不在遗留应用程序的堆栈中，而是在新想法不断增长的绿地之中。但即使是那些绿色的田野，也必须以某种方式与旧谷仓相连。
然而，实际使用的技术并不一定会在这些绿地中有所建树。这样，找到一种在环境中同时支持容器和虚拟机的方法是很重要的，因为你可能犯的唯一真正错误是：完全忽略其中一种技术。
原文链接：https://thenewstack.io/container-or-vm-how-to-choose-the-right-option-in-2023/
