Containers vs Serverless：本質差別是什麼？

在雲計算領域，容器和無伺服器計算已經占據了發展前列。

作者 | Emra Samdan

翻譯 | bocloudresearch

一點曆史

在不久以前，應用程式的開發、部署和維護要比現在複雜得多，耗時也多。在最初，維護不僅需要修複應用程式的代碼，還需要修複對實體機器的支援。保持伺服器、硬體和軟體的更新也是非常關鍵的任務。

在本世紀初，一種名為“基礎設施即服務(IaaS)”的新模式迅速流行起來。IaaS提供了從第三方提供商租用遠端伺服器和虛拟機的可能性，這些提供商可以完全負責管理硬體、網絡和預訂。

IaaS出現之後，消除開發人員的所有非編碼職責來簡化開發人員工作，這一想法推動了新方法、模型和服務的創新。

容器是什麼?

Docker的官方網站提供了以下簡短而優雅的定義:“容器是一個标準的軟體單元，它将代碼及其所有依賴項打包，進而使應用程式在不同的計算環境之間快速、可靠地運作。換句話說，通過使用容器，開發人員可以確定他們的應用程式可以在任何雲平台或本地伺服器上運作。在某些方面，容器類似于虛拟機，比如兩者都是隔離資源。但是，虛拟機模拟實體裝置，而容器建立應用程式層的抽象。

無伺服器計算是什麼？

在無伺服器計算中，整個應用程式或應用程式的一部分被解耦為多個函數，每個函數都響應諸如HTTP請求、新消息到達消息隊列、或在存儲中儲存或修改新對象等時間觸發的。平台可以在特定的時間或周期運作這些函數，這對cron jobs（定時任務）很有幫助。

要使此系統工作，開發人員隻需編寫功能代碼，并将其及其依賴項打包到zip檔案中，然後将該zip檔案發送到無伺服器端點，由提供商負責供應和擴充。

無伺服器的關鍵特性之一是“按需付費”模型，在這種模型中，公司僅按函數的實際執行時間付費。如今，AWS Lambda應該是最受歡迎的無伺服器提供商。

容器和無伺服器有什麼共同之處嗎?

是的。現在，無伺服器和容器都很流行，它們允許開發人員專注于自己的代碼而不是基礎設施，這極大地提高了開發速度。容器和 serverless 都非常适合于微服務和基于元件的體系結構。在使用它們時，部署和擴充通常比使用傳統的單體架構更快、更具成本效益，因為你操作的是應用程式的一小部分，而不是整個應用程式。雖然容器和serverless 有這些共性，但是每種技術都有自己的優勢、弊端和用例。

容器化的優勢

容器的第一個優勢是可移植性。由于容器已經包含了它需要運作的所有内容，是以隻需放置一台安裝了容器引擎的機器即可運作。容器與平台無關，是以它們可以運作在Linux、Windows、macOS、Mesos、Docker、Swarm或Kubernetes上。它們甚至可以在另一個容器中運作。

在計算資源使用方面，容器也比虛拟機更高效。盡管容器和虛拟機都是虛拟化的，但是虛拟機會使用自己的作業系統來模拟整個計算機，是以會消耗更多的資源。另一方面，容器可以共享同一作業系統，進而使作業系統更小，更快地啟動和關閉。

容器的另一個好處是允許開發人員完全控制應用程式。雖然這意味着必須手動配置系統設定，但這也意味着擁有真正的靈活性。這在serverless上是無法實作的，因為無伺服器的所有内容都是由雲提供商管理的。

容器的用例

當我們想要将一些大型的單體應用程式重構為更小的獨立部分， 以便遷移到微服務體系結構并獲得更好的性能、可測試性和擴充速度時，容器确實是很有幫助的。例如，将以前的大型應用程式拆分為幾個獨立的服務：其中一個負責使用者管理，另一個負責轉換媒體檔案等。每個服務都可以輕松擴充，以便在其職責範圍的負載增加時提供更好的性能。但這對于單體應用程式來說是不可能實作的，在單體應用程式中，需要向整個系統添加新執行個體，這既昂貴又耗時。

是以，容器适合于長時間運作的應用程式，以及具有特定系統需求的應用程式，如果沒有對系統的完全控制，這些應用程式很難設定。

Serverless的優勢

由于上面提到的“按需付費”模型，托管無伺服器應用程式的成本可能比使用任何其他方法都要低得多。無需為功能的空閑時間付費，如果沒有流量，那麼每月的賬單上就不會有費用。幾乎所有無伺服器的提供商都有免費層，其中包括每月固定數量的請求和執行時間。通常情況下，所提供的數量足以使小網站或初創公司免費運作。

對于容器，将應用程式分發到部件或微服務是關鍵步驟。在serverless中，它是将應用程式或其各個部分分發到單個函數中，每個函數負責特定的邏輯段。工程師更容易了解和開發單個功能的邏輯，這極大地提高了開發和部署速度。與部署整個應用程式相比，部署一小部分功能的風險更小。

無伺服器的另一個巨大優勢是自動伸縮。無伺服器的函數在提供者控制下的小型、無狀态的臨時容器中運作。提供者對響應負載峰值的擴充承擔全部責任，并且可以在幾秒鐘内啟動數百個執行個體。而且，仍然隻需要為所有函數的總執行時間付費。

什麼時候使用無伺服器比較好?

Serverless的事件驅動特性使得它對于不總是需要運作的應用程式(或其部分)非常有用。

假設你正在為一個現有的應用程式開發媒體處理功能。新子產品雖然不會經常使用，但是仍然需要足夠的計算能力來完成它的任務。将其放如應用程式中可能需要切換到更強大的執行個體——這是一個冒險的舉動，因為如果同時運作一些繁重的任務，可能會導緻其他所有使用者的延遲。在這種情況下，還需要支付更多的費用，并且仍然面臨由上述瓶頸所導緻的一些問題。

相反，如果選擇了serverless，那麼媒體處理功能将與應用程式的其餘部分隔離。當它不被使用時，就不需要為此付費，并且可以始終確定它不會影響到應用程式的其他部分。

容器的弊端

即使沒有人使用應用程式，也至少有一個承載容器的虛拟機執行個體始終在運作。由此導緻容器比無伺服器更昂貴。

即使容器可以在共享計算機中快速擴充，但由于需要對計算機本身進行擴充，是以其他擴充也不很快。 但是，将容器與業務流程系統（如Kubernetes或AWS ECS）一起使用可以使擴充更智能。

無伺服器的弊端

對于大多數開發人員來說，serverless最可怕的部分是供應商鎖定。當你送出到serverless時，實際上是在單個雲提供商上進行堆棧。這些函數中使用的無伺服器應用程式和 api 的體系結構因不同的提供商而有所不同，是以更改提供商或切換到内部解決方案的成本可能很高。盡管如此，有一些專家并不同意這個觀點，他們聲稱廠商鎖定實際上并不是一個問題。

使用無伺服器方法不容易實作可觀察性、監視和調試。由于應用程式可以被分散到多個部分，而每個部分都有自己的 bug 和錯誤，是以控制和檢視全局變得非常重要。

容器和無伺服器可以一起操作嗎?

容器和無伺服器可以一起操作，答案是肯定的。将主要應用程式功能作為一個容器化的微服務來運作，同時将無伺服器使用于某些背景操作或很少使用的功能（但占用CPU），可能會非常有效。

另一個有趣的組合是AWS Fargate提供的。該服務結合了無伺服器和容器的優點，允許你更好地控制你的應用程式，而不必擔心伸縮難題。

結論

容器和無伺服器通常被認為是互相競争的技術。但仔細觀察就會發現它們隻是不同的技術，當在同一個項目中使用時，它們實際上可以彌補彼此的缺陷。重要的是要記住，“舊的”并不意味着“過時”，“新的”并不意味着“更好”。解決方案的有效性取決于特定的用例、項目需求、團隊經驗和團隊偏好。