虛擬機器(VM) vs. 容器(Container)

 虛擬機器 Virtual Machine

    在 Container 的概念尚未開始之前，一個應用程式的執行會是透過虛擬機器（簡稱 VM）來進行。為什麼不直接執行應用程式呢？因爲每台主機的環境配置、作業系統（簡稱 OS）都不盡相同，所以當一台主機要直接執行用另外一台主機開發出來的應用程式，很可能會因為環境不一致的關係而失敗。VM 的概念是在將應用程式打包時，除了程式本身，還順便一起打包開發的作業系統，當任何一台主機（Host OS）要執行此應用程式時，就可以在 VM 中先下載裝有此應用程式所需一切資源的作業系統（此稱 Guest OS）， 模擬出一個熟悉的空間給此應用程式，這樣就能確保應用程式的順利執行。

VM 的好處有:

1. 軟硬體分離：因為應用程式執行的環境是虛擬的，所以硬體不用被限制在特定廠牌或是規格。
2. 安全性高：對作業系統而言，看起來就像是在一臺正常的實體機器中，在 VM 中做的動作不會影響到 Host OS，並且就算多個 VM 在同一臺實體伺服器中執行，彼此之間也都是獨立互不干擾的。

但 VM 有一個明顯缺點：OS造成很多空間和資源的浪費。

1. 時間上來說，每次都要先在 VM 裡面裝好一套OS才能執行應用程式，建好OS也要等開機，所以 VM 的建立速度就不會很快（大約是幾十秒到幾分鐘）。
2. 空間上來說，一套OS大都上百 MB，就算應用程式本身只有幾 KB，還是必須要耗費一整個OS的資源。資源分配上來說，實體伺服器不只要分配資源給應用程式本身，也會需要將一部份運算資源分給OS的執行，是個必要之惡。

容器 Container

為了改善 VM 浪費資源的缺點，就開始有Container 。

容器提供一種標準的方式，將應用程式的程式碼和相依性封裝至單一物件。也可以將容器使用於對安全性、可靠性和可擴展性有基本要求的程序和工作流程 。開發人員希望確保應用程式的環境保持一致，因此他們採用容器化方法。這麼做有助於減少在不同運算環境中偵錯應用程式和診斷所耗時間的落差。

Container 同樣是將應用程式連同其所需環境（相關程式碼、函式庫、環境配置檔）一同打包的技術，但是在 Container 中不需要安裝OS就能執行應用程式。既然 Container 不像 VM 那樣自己的OS自己做，那 Container 要在哪裡運行呢？答案是在 Host OS 的核心系統層。

所有 Container 共用 Host OS，並建立資源控管機制來分配 Host OS 上的系統資源，因此省去了執行 Guest OS 的時間與心力，而能夠同時做到每個 Container 互相獨立。
所以說，VM 的中心是OS，而 Container 的中心是應用程式。

Container 的優勢基本上都跟甩掉了 Guest OS 有關：

1. 執行速度快：相比 VM 以分鐘為單位，Container 執行速度可以以秒為單位。
2. 儲存空間小：相比 VM 以 GB 為單位，Container 執行速度以 MB 為單位。
3. 資源更有效運用：免去了執行 Guest OS 的義務，同一台主機上可以裝載的 Container 數量可以是 VM 的好幾倍。

但 Container 也不是很完美的。比如說它沒有建立自己的OS，所以只能依賴 Host OS，並且縱然它解決了很多 VM 的限制，想要體驗 Container 的完整威力，就要先將應用程式變成下列提到的 AWS 的各種服務，不然 Container 就只會是一個比較容易打包的工具而已。 

執行容器化應用程式時，須要考量可擴展性。假設使用的並非具有多個容器的單一主機，而是必須管理擁有數百個容器的數十個主機。在這種大規模下，這須要花多少時間來監視記憶體用量、安全性、記錄等等。

在 AWS 中，就可以依據各種需求建立和執行容器化的應用程式和控管機制。