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

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

容器正在徹底改變人們建置、封裝和部署軟體的方式。但經常被忽略的是,它們如何徹底改變人們建置用於建置、封裝和部署軟體的軟體的方式。(如果您必須讀兩遍這句話也沒關係...)今天,以及在明天的 Container World 演講中,我將探討像 Kubernetes 這樣的容器協調器如何構成下一代平台即服務 (PaaS) 的基礎。特別是,我對像 Azure 容器服務Google 容器引擎其他 這樣的雲端容器即服務 (CaaS) 平台如何成為 PaaS 建構於其上的新基礎架構層感興趣。

為了理解這一點,重要的是要考慮傳統上由 PaaS 平台提供的一組服務

  • 原始程式碼和可執行檔的封裝和發佈
  • 軟體版本的可靠、零停機時間的推出
  • 修復、自動擴展、負載平衡

當您查看此清單時,很明顯,這些傳統“PaaS”角色中的大多數現在已被容器接管。容器映像和容器映像建置工具已成為封裝您的應用程式的方式。容器登錄檔已成為在全球發佈您的應用程式的方式。可靠的軟體推出是使用 Kubernetes 中的 Deployment 等協調器概念實現的,而服務修復、自動擴展和負載平衡都是使用 ReplicaSetsServices 在 Kubernetes 中部署的應用程式的屬性。

那麼 PaaS 還剩下什麼?PaaS 會被容器即服務取代嗎?我認為答案是“否”。PaaS 剩下的部分始終是 PaaS 最重要的部分,那就是有主見的開發人員體驗。除了我上面列出的 PaaS 的所有通用部分之外,PaaS 最重要的部分始終是開發人員體驗和應用程式框架使開發人員在平台邊界內更有效率的方式。PaaS 使開發人員能夠在不到一小時的時間內從筆記型電腦上的原始程式碼轉變為全球可擴展的服務。這非常強大。

然而,在傳統 PaaS 的世界中,建置 PaaS 基礎架構本身所需的技能,即使用者軟體在其上運行的軟體,需要非常強大的分散式系統技能和經驗。因此,PaaS 傾向於由分散式系統工程師而不是特定垂直開發人員體驗方面的專家建置。這意味著 PaaS 平台傾向於通用基礎架構,而不是針對特定垂直領域。最近,我們已經看到這種情況開始改變,首先是針對行動 API 後端的 PaaS,然後是針對“函數即服務”的 PaaS。然而,這些產品仍然是在原始基礎架構之上從頭開始建置的。

最近,我們開始看到這些平台建構在容器基礎架構之上。以“函數即服務”為例,至少有兩個(可能更多)在 Kubernetes 上運行的函數即服務的開源實作 (fissionfunktion)。這種趨勢只會持續下去。在容器即服務之上建置平台即服務非常容易,您可以想像將其作為大學電腦科學作業發布。這種易於開發意味著在特定垂直領域(例如用於運行三維模擬的軟體)具有特定專業知識的個別開發人員可以而且將會建置針對該特定垂直體驗的 PaaS 平台。反過來,透過針對如此狹窄的體驗,他們將建置一個完美適合該狹窄垂直領域的體驗,使其解決方案在目標市場中具有吸引力。

然後,這指向在容器即服務之上建置的下一代 PaaS 的另一個優勢。它使開發人員無需在特定的 PaaS 平台上做出“全有或全無”的選擇。當分層在容器即服務之上時,基本功能(命名、發現、封裝等)都由 CaaS 提供,因此在恰好部署在該 CaaS 之上的多個 PaaS 之間是通用的。這意味著開發人員可以混合和匹配,將多個 PaaS 部署到相同的容器基礎架構,並為每個應用程式選擇最適合該特定平台的 PaaS 平台。此外,重要的是,如果原始 CaaS 基礎架構更適合他們的應用程式,他們可以選擇“下降”到原始 CaaS 基礎架構。將 PaaS 從提供基礎架構層中解放出來,使 PaaS 能夠多樣化並針對特定的體驗,而無需擔心過於狹隘。這些體驗變得更有針對性、更強大,但透過在容器即服務之上建置,也變得更加靈活。

Kubernetes 是下一代應用程式、PaaS 等的基礎架構。鑑於此,我對我們今天發布的 公告 感到非常興奮,即 Azure 容器服務上的 Kubernetes 已達到正式發布階段。當您將下一代應用程式部署到 Azure 時,無論是在 PaaS 上還是直接部署到 Kubernetes 本身(或兩者兼有),您都可以將其部署到受管理的、受支援的 Kubernetes 叢集上。

此外,由於我們知道 PaaS 和軟體開發的世界整體而言是混合式的,因此我們很高興宣布 Azure 容器服務中的 Windows 叢集 預覽版正式發佈。我們也正在 ACS-Engine混合式叢集 上努力,並預計在未來幾個月內將其推向正式發佈。

我很高興看到容器和容器即服務正在改變運算世界,我深信我們僅僅觸及了未來幾個月和幾年內將看到的轉型的皮毛。