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