虽然，Docker是非常前沿的容器化技术，但很多IT开发人员却并没有直接使用，而是在寻找Docker方案，出现这种状况的主要原因是什么？
经了解得知，Docker其实并不容易使用，对于很多技术人来说，Docker的落地是一个艰难的学习过程，需要提前解决一些问题。比如：应用程序性能监控并不能直接使用。另外，虽然Docker提供了基本的工具，但你需要集成第三方工具才能实现。
要知道，容器编排需要配置和管理编排工具，如需要在Docker Swarm、Kube.NETes或Apache Mesos方面具有相当丰富的专业知识。因为，与传统的技术堆栈相比，Docker容器需要更多的技术功底。如果不能正确地理解这个工具，运行Docker就会变得复杂，花费的成本也更高。
如果你所在企业，恰好也在选择Docker替代方案，以下路径仅供参考：
方案1:无服务器架构
无服务器架构是Docker容器化技术中比较有代表性的替代方案。顾名思义，无服务器架构消除了管理服务器或运行应用程序的底层基础设施的需要。这并不意味着不需要服务器，而是由云供应商承担了服务器方面的工作。开发人员可以简单地编写应用程序代码，将其打包并部署到任何平台上。他们可以选择购买应用程序所需的特定后端服务，并将其部署到所需的平台上。
无服务器架构消除了基础设施管理负担或Docker/Kubernetes配置复杂性、可扩展性和升级，从而加快了产品上市时间。触发事件的能力使其成为排序工作流和CI/CD管道的一个很好的选择。无服务器计算的最大优点之一是，可以扩展应用程序超出云提供商的能力。
购买应用程序所需的特定功能的灵活性大大降低了成本。例如，当运行docker容器并遇到不可预测的流量峰值时，将不得不增加ECS环境容量，企业将为额外的服务容器和容器实例按需支付费用。对于SaaS业务，成本优化始终是优先考虑的问题。当企业使用无服务器架构时，将只扩展应用程序运行时所需的功能，而不是整个基础架构。这样，就可以优化成本。此外，无服务器架构简化了部署过程，允许企业部署多个服务而无需进行底层配置。我们可以在任何地方运行代码，因此可以使用最近的服务器来减少延迟。
无服务器架构的缺点是，随着应用程序的增长，应用程序故障排除变得复杂，因为我们不知道应用程序内部发生了什么。由于这个原因，无服务器被称为黑盒技术。所以，正确选择非常重要，否则我们付出更多的成本。在无服务器架构中，Autodesk、Droplr、PhotoVogue和AbstractAI等公司都是使用无服务器模式的典型案例。
方案2:来自VMware的虚拟机
在VMware环境下部署虚拟机是Docker的另一种选择。VMware是虚拟化领域的领导企业。Docker在操作系统层抽象资源，而VMware在硬件层进行虚拟化。VMware提供的重要产品之一是vSphere套件，其中包含用于促进云计算虚拟化操作系统的不同工具。vSphere使用ESXi, ESXi是在单个主机上运行多个操作系统的hypervisor。因此，每个操作系统都使用其专用资源运行。
谈到容器化，VMware虚拟化硬件和底层资源，这意味着它们不是完全隔离的。与Docker相比，VMware虚拟机更加资源密集，而且不轻量级和便携。对于需要完整服务器的应用程序，VMware是一个选择。虽然Docker应用轻量级且运行速度更快，但VMware正在迅速赶上，当前的ESXi版本与裸金属机性能相当或优于裸金属机。
将VMware用于容器化任务有多种选择。例如，企业可以安装VMware vSphere ESXi管理程序，然后在其上安装任何操作系统。Photon是VMware提供的一个开源的、以容器为中心的操作系统。针对google Compute Engine和Amazon Elastic Compute等云平台进行了优化。它提供了一个名为tdnf的生命周期管理系统，该系统基于包并且与yum兼容。Photon应用轻量级，启动速度快，占用空间小。或者，企业可以在ESXi上运行任何linux发行版，并在操作系统中运行容器。
与VMware虚拟机相比，Docker容器包含更多需要保护的层。对于需要高安全性和持久性存储的环境，VMware是一个不错的选择。
VMware虚拟机最适合IaaS环境中的机器虚拟化。虽然VMware虚拟机可以作为Docker的替代品，但它们不是相互竞争的技术，而是相互补充的。为了获得两者的优势，企业可以在VMware虚拟机中运行Docker容器，使其变得超轻量级和高度可移植性。
方案3:来自AWS、Azure和GCP的单块实例
Docker的另一个替代方案是使用AWS实例或Azure和GCP vm部署单片应用程序。当实现AWS EC2实例时，它将安装操作系统的基本组件和其他必需的软件包。企业可以使用Amazon machine Image (AMI)在EC2实例中创建虚拟机。它们包含启动实例的指令。ami应该由开发人员在AWS中指定。有针对特定用例的预配置ami。企业可以将Amazon ECS用于编排目的。但与Docker容器相比，AWS AMI映像不是轻量级的。
方案4:Apache Mesos
Apache Mesos是由Apache软件基金会开发的开源容器和数据中心管理软件。它的前身是Nexus。Mesos是用c++编写的。它作为一种抽象工具，将虚拟资源从物理硬件中分离出来，并为在其上运行的应用程序提供资源。你可以在Mesos之上运行Kubernetes、Elastic Search、Hadoop、Spark等应用程序。
Mesos是作为一个集群管理工具创建的，类似于Tupperware和Borg，不同之处在于它是开源的。它使用模块化架构。Mesos的一个重要特性是，它将数据中心资源抽象出来，同时将它们分组到单个池中，使管理员能够有效地管理资源分配任务，同时提供一致和卓越的用户体验。它提供了更高的可扩展性，可以在不干扰集群的情况下添加新的应用程序和技术。它带有一个由Zookeeper提供支持的自我修复和容错环境。它允许在相同的基础设施上运行不同的工作负载，从而减少了内存占用并优化了资源。例如，可以在同一基础设施上运行传统应用程序、分布式数据系统或无状态微服务，同时单独管理工作负载。
Apache Mesos允许企业在其上运行各种工作负载，包括容器编排。对于容器编排，Mesos使用一个名为Marathon的编排框架。它可以轻松地运行和管理关键任务工作负载，这使得它成为企业架构的最爱。
Mesos不支持服务发现。然而，可以使用运行在Mesos上的应用程序，比如Kubernetes，来实现这个目的。它最适合涉及多个Kubernetes集群的复杂配置的数据中心环境。它被归类为集群管理工具，使组织能够运行、构建和管理资源高效的分布式系统。Mesos允许企业在Linux容器中隔离任务，并快速扩展到数百甚至数千个节点。易于扩展是它与Docker的区别所在。
如果企业希望在可靠的平台上运行关键任务和多样化的工作负载集，并具有跨云和数据中心的可移植性，Mesos是一个不错的选择。Twitter、Uber、Netflix和苹果(Siri)都是使用Apache Mesos的代表企业。
方案5:基于云打造的容器技术
Cloud Foundry是由Cloud Foundry基金会管理的开源平台即服务(PaaS)产品。该工具由VMware工程师用Ruby、Go和JAVA编写，并于2011年发布。Cloud Foundry因其持续交付支持而广受欢迎，它促进了产品生命周期管理。它基于容器的体系结构在多云环境中非常有名，该方案可以部署在任何平台上，同时允许企业在不干扰应用程序的情况下无缝地移动工作负载。
Cloud Foundry的关键特性是易用性，它允许快速原型，允许企业从任何本地IDE编写和编辑代码，并将容器化的应用程序部署到云中。Cloud Foundry选择正确的构建包，并自动为简单的应用程序进行配置。该工具限制打开的端口数量以提高安全性。支持动态路由，实现高性能。应用程序运行状况监视和服务发现是开箱即用的。
Cloud Foundry使用自己的容器格式Garden和容器编排引擎Diego。然而，随着Docker的普及和大多数用户开始使用Docker容器，Cloud Foundry不得不支持Docker。为此，它将docker容器封装为Garden映像格式。然而，将这些容器转移到其他编排引擎并不容易。Cloud Foundry面临的另一个挑战来自Kubernetes。虽然Cloud Foundry支持无状态应用程序，但Kubernetes足够灵活，可以支持有状态和无状态应用程序。迫于用户的喜好，Cloud Foundry用Kubernetes取代了它的编排引擎Diego。没有了它的容器运行时和编排平台，Cloud Foundry容器生态系统变得不那么重要了。
Cloud Foundry的失败强调了减轻工作负载的重要性，同时还强调使用Docker和Kubernetes解决方案，是大势所趋。
当然，大体方向是，Docker的优点超过了缺点。即便使用Docker的替代品时，也会遇到很多挑战。从长远来看，如果我们有足够的时间和精力，多去研究Docker，会获得长远回报。但如果我们没那个时间，以上Docker的替代方案，也可以去选择。
京公网安备 11010802035086号