本篇文章已超過一年。較舊的文章可能包含過時的內容。請確認頁面中的資訊自發布以來是否已變得不正確。
雲原生應用程式介面
標準介面（或，第十三要素）
當你在博學之士面前提到我們需要「軟體標準」時，你會得到一些有趣的表情。大多數人承認軟體標準一直是那些最大膽、最成功的專案（例如網際網路）成功的核心。但大多數人也懷疑它們如何應用於我們今天所處的創新世界。我們的專案是以週為單位執行，而不是年。在這個流動性高、競爭激烈的世界中，陷入由大型軟體公司驅動的標準實務將是喪鐘。
這不是關於「那些」標準。那些經過多年的深入考量和協商，最終由一個名稱為四個字母縮寫的機構發布的標準。這是關於一種不同的方法：找到在現實世界中有效的方法，並以社群的力量來擁抱它。
讓我們回到第一原理。如果要用一個詞來描述雲原生，我們會選擇「可自動化」。
大多數現有的應用程式並非如此。
應用程式與其環境有許多介面，無論是與管理基礎設施、共享服務或其他應用程式。為了讓我們能夠將操作員從修補、擴展、將應用程式從一個環境遷移到另一個環境、更換依賴項以及處理故障狀況中解放出來，一套結構良好的通用介面至關重要。不言而喻，這些介面必須為機器而設計，而不僅僅是人類。機器友善的介面允許自動化系統理解受管理的系統，並創建應用程式在自動化環境中生存所需的鬆散耦合。
隨著容器化基礎設施的建立，應用程式可以使用一組關鍵介面，這些介面遠遠超出今天單一節點可用的範圍。「無伺服器模式」（意味著短暫的、事件驅動的功能執行）的採用將進一步加劇在與節點完全解耦的環境中理解運行程式碼的需求。所需的服務將從應用程式配置開始，並擴展到監控、日誌記錄、自動擴展等等。隨著應用程式繼續適應成為「雲原生」世界中更完整的公民，功能集只會不斷增長。
更深入地探討一個例子，許多服務發現解決方案已被開發出來，但通常與特定的儲存實作、特定的程式語言、非標準協定，和/或在其他方面有主觀意見（例如，規定應用程式命名結構）綁定。這使得它們不適合通用用途。雖然 DNS 有其限制（最終需要解決），但它至少是一個標準協定，在其實現中仍有創新的空間。CoreDNS 和其他雲原生 DNS 實作證明了這一點。
當我們檢視 Google 內部的系統時，由於軟硬體環境大致同質，我們能夠在沒有正式介面定義的情況下實現非常高的自動化程度。相鄰系統可以安全地對介面做出假設，並且透過提供一組普遍使用的函式庫，我們可以規避這個問題。一個很好的例子是我們的日誌格式不需要正式指定，因為產生日誌的函式庫是由維護日誌處理系統的團隊維護的。這意味著到目前為止，我們可以無需像 fluentd 這樣的東西（它正在社群中解決與日誌記錄系統介面的問題）就能應付。
即使 Google 已經設法以這種方式應付過去，但這對我們造成了傷害。其中一種方式是當我們收購一家公司時。將他們的技術移植到我們的自動化系統中運行需要大量的工作。在繼續創新的同時做這項工作尤其困難。但更重要的是，開源世界中正在發生許多創新，我們不容易利用這些創新。當新技術出現時，我們希望能夠試驗它、逐步採用它，甚至可能回饋貢獻。當你運行一個垂直整合的客製化堆疊時，這是一件很難做到的事情。
缺乏標準介面讓客戶有三個選擇：
- 忍受高昂的運營成本（現狀），並接受你的開發人員在許多情況下將把他們的大部分時間花在處理應用程式的維護和管理上。
- 註冊成為像 Google 一樣的公司（自己建構一切，從地板上的混凝土開始）。
- 依賴單一或少數幾家供應商來提供完整的解決方案，並接受一定程度的供應商鎖定。任何規模的公司（從企業到新創公司）中很少有人覺得這有吸引力。我們相信開放社群更強大，並且當堆疊的每一層都有競爭時，客戶會受益。應該有可能在每個層級（日誌記錄、監控、協調、容器運行時環境、區塊和檔案系統儲存、SDN 技術等）組建一個具有最佳功能的堆疊。
標準化管理系統和應用程式之間的介面（至少透過慣例）至關重要。人們可能會認為使用介面的通用慣例是創建在雲端和大規模環境中良好運作的現代系統的第十三個要素（擴展 12 要素方法）。
Kubernetes 和雲原生運算基金會 (CNCF) 代表著一個絕佳的機會，可以支持標準介面的出現，並支持完全自動化軟體世界的出現。我們希望看到這個社群擁抱從有效技術中推廣標準介面的理想。顯而易見的第一步是確定當前的一組關鍵介面，並在 CNCF 中建立工作組，開始評估該領域中已存在的候選方案，並贊助工作以開始開發跨容器格式、協調器、開發人員工具和實現雲原生願景所需的眾多其他系統的標準介面。