雖然，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的替代方案，也可以去選擇。
