本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

容器即服務，下一代 PaaS 的基礎

作者：Brendan Burns (Microsoft) |

容器正在徹底改變人們構建、打包和部署軟體的方式。但常常被忽視的是，它們正在徹底改變人們構建那些用於構建、打包和部署軟體的軟體的方式。（這句話可能需要讀兩遍才能理解……）今天，以及明天在Container World的演講中，我將探討像Kubernetes這樣的容器編排器如何成為下一代平臺即服務（PaaS）的基礎。特別地，我關注像Azure Container Service、Google Container Engine和其他這樣的雲容器即服務（CaaS）平臺如何成為PaaS所構建的新的基礎設施層。

要理解這一點，重要的是要考慮傳統上由PaaS平臺提供的一系列服務：

  • 原始碼和可執行檔案打包及分發
  • 可靠、零停機地推出軟體版本
  • 自我修復、自動伸縮、負載均衡

當您檢視這份列表時，很明顯，這些傳統的“PaaS”角色大部分現在已經被容器接管。容器映象和容器映象構建工具已成為打包應用程式的方式。容器登錄檔已成為在全球分發應用程式的方式。可靠的軟體釋出透過Kubernetes中的Deployment等編排器概念實現，而服務自我修復、自動伸縮和負載均衡都是使用ReplicaSets和Services部署在Kubernetes中的應用程式的特性。

那麼PaaS還剩下什麼？PaaS會被容器即服務取代嗎？我認為答案是“否”。PaaS剩下的部分是它最初最重要的部分，那就是有主見的開發者體驗。除了我上面列出的所有PaaS的通用部分之外，PaaS最重要的部分始終是開發者體驗和應用程式框架在平臺邊界內使開發者更高效的方式。PaaS使開發者能夠在不到一小時內將筆記型電腦上的原始碼轉換為全球可擴充套件的服務。這具有巨大的力量。

然而，在傳統PaaS的世界中，構建PaaS基礎設施本身（即執行使用者軟體的軟體）所需的技能和經驗要求非常強的分散式系統知識。因此，PaaS往往由分散式系統工程師而不是特定垂直領域開發者體驗專家構建。這意味著PaaS平臺傾向於通用基礎設施，而不是針對特定垂直領域。最近，我們看到這種情況開始改變，首先是針對移動API後端的PaaS，後來是針對“函式即服務”的PaaS。然而，這些產品仍然是在原始基礎設施之上從頭開始構建的。

最近，我們開始看到這些平臺構建在容器基礎設施之上。以“函式即服務”為例，至少有兩個（可能更多）在Kubernetes之上執行的開源函式即服務實現（fission 和 funktion）。這種趨勢只會持續下去。在容器即服務之上構建平臺即服務非常容易，您可以將其想象成作為本科計算機科學作業分發。這種開發的簡易性意味著具有特定垂直領域專業知識的個人開發者（例如用於執行三維模擬的軟體）能夠並且將會構建針對該特定垂直體驗的PaaS平臺。反過來，透過針對如此狹窄的體驗，他們將構建一個完美契合該狹窄垂直領域的體驗，使其解決方案在該目標市場中具有吸引力。

這進而指出了下一代PaaS構建在容器即服務之上的另一個好處。它使開發者無需在特定的PaaS平臺上做出“全押”的選擇。當PaaS分層構建在容器即服務之上時，基本功能（命名、發現、打包等）都由CaaS提供，因此在部署在該CaaS之上的多個PaaS之間是通用的。這意味著開發者可以混合搭配，將多個PaaS部署到相同的容器基礎設施上，併為每個應用程式選擇最適合該特定平臺的PaaS平臺。同樣重要的是，如果原始CaaS基礎設施更適合他們的應用程式，他們可以選擇“降級”到原始CaaS基礎設施。將PaaS從提供基礎設施層中解放出來，使PaaS能夠多樣化並針對特定體驗，而不必擔心過於狹窄。這些體驗變得更加有針對性、功能更強大，而且透過構建在容器即服務之上，也更加靈活。

Kubernetes是下一代應用程式、PaaS及更多基礎設施的基礎。鑑於此，我非常高興我們今天宣佈 Azure 容器服務上的 Kubernetes 已普遍可用。當您將下一代應用程式部署到 Azure 時，無論是透過 PaaS 還是直接部署到 Kubernetes 本身（或兩者兼有），您都可以將其部署到託管的、受支援的 Kubernetes 叢集上。

此外，由於我們深知PaaS和一般軟體開發的世界是混合的，我們很高興地宣佈Azure Container Service中的Windows叢集的預覽版可用。我們還在ACS-Engine上開發混合叢集，並預計在未來幾個月內將其普遍可用。

我很高興看到容器和容器即服務正在改變計算世界，我相信我們只是觸及了未來幾個月和幾年將要看到的變革的表面。