Istio為什麼現在申請加入CNCF？

Istio指導委員會決定將服務網格專案作為雲原生計算基金會(CNCF)的孵化專案提供，這引發了一個問題：為什麼花了這麼長時間?

此前，IBM(原始創造者之一，其他包括谷歌和Lyft)和其他委員會成員對該專案的治理表示擔憂，特別是谷歌倡導在2020年為該專案建立開放使用共享空間(Open Usage Commons，OUC)。然而，一位Istio指導委員會成員在GitHub上指出，今天的環境已經發生了變化。

時機正確

Istio指導委員會暗示時機是正確的。Istio指導委員會成員Craig Box在GitHub上釋出的Istio宣告稱，此舉旨在透過Gateway API“深化”Istio與Kubernetes的整合和透過無代理網格“深化”Istio與gRPC的整合，“更不用說在Istio旁邊成長起來的Envoy了。”Craig Box是谷歌雲(Google Cloud)雲原生倡導團隊的負責人。“我們認為是時候將premier Cloud Native stack統一在一個傘下了。”宣告寫道。

然而，Istio加入CNCF的申請是在谷歌於2020年為Istio建立開放使用共用(OUC)許可證以及谷歌對相關商標的所有權受到批評之後提出的。IBM認為OUC許可計劃“令人失望，因為它沒有達到社群對開放治理的期望”，當時IBM的總經理兼IBM雲平臺技術長Jason McGee在2020年的一篇部落格文章中寫道。

“一個開放的治理過程是許多成功專案的基礎。如果沒有這種供應商中立的專案治理方法，Kubernetes相關專案的社群內就會出現摩擦。在專案開始時，就達成了一項協議，即該專案成熟後將向CNCF捐款。”McGee寫道，“IBM仍然認為，管理關鍵開源專案(如Istio)的最佳方式是在一個聲譽良好的組織的支援下進行真正的開放治理，該組織為所有貢獻者提供公平的競爭環境，為使用者提供透明度，並對許可證和商標進行供應商中立的管理。谷歌應該重新考慮他們最初的承諾，將Istio納入CNCF。”

IBM開放技術副總裁Todd Moore表示，為了讓Istio專案實現其長期目標，谷歌必須放棄這些商標。

“很久以前，IBM就意識到社群的力量是開放的，而在中立中得到保障的專案是獲得動力和催生市場的專案。雖然Istio專案治理取得了巨大的進步，但該專案並沒有註定會獲得長期中立所能保證的廣泛採用。單一供應商對商標和許可證的控制是對廣泛採用的一種威懾，因為終端使用者和行業參與者都意識到了這些陷阱。”

與此同時，Moore指出，谷歌不願交出商標的各方“已經不復存在”。“這讓明智的人得以獲勝。一開始，誰將註冊商標是一個難題，IBM真誠地接受了谷歌，我們將該專案提交給CNCF的協議將得到遵守。”

谷歌發言人在一封電子郵件回覆中反駁道：“我們一直在等待Istio生命週期的合適時機捐贈，現在正是其成熟的合適時機。谷歌聯絡了OUC，要求他們將商標捐贈給Linux基金會。OUC同意這樣做，因此作為捐贈的一部分，商標將被轉讓。”

最初的不情願

昨天，Istio的指導委員會表示，OUC許可將繼續有效。然而，這些商標將轉移到Linux基金會，但仍將根據OUC的商標指導方針進行管理。

據業內人士透露，谷歌的某些交易方不願放棄Istio商標的所有權。企業管理協會(EMA)分析師Torsten Volk表示，這是因為，谷歌“已經在Istio上投入了大量的員工時間，並將服務網格視為進入企業市場的關鍵切入點。”

Volk說：“對任何供應商來說，控制將分散式應用程式連線在一起的‘繩子’都是一個很好的切入點，但谷歌肯定知道Docker的所作所為為Kubernetes鋪平了道路。重點是，谷歌需要採取這一步，以便VMware、Cisco、IBM、Red Hat和朋友們繼續致力於Istio，而不是幹別的。”

雖然Istio保留了OUC許可，但將相關商標轉移到Linux基金會的行為，尤其是申請成為CNCF專案的決定，似乎已經安撫了IBM——至少在某種程度上。

IBM的反應

IBM在一篇帖子中寫道：“IBM完全相信開放治理和社群的力量。因此，我們熱烈歡迎向CNCF提交Istio。”

然而，IBM並沒有說得更具體。Volk認為，這可以解釋為“過去圍繞這個話題的大量摩擦，谷歌仍然堅持OUC許可模式，而不是簡單地採用沒有商標保護的傳統開源許可。”

“這對所有相關方來說都是一個棘手的話題，因為Istio整合要求每個供應商進行重大投資，沒有人願意向董事會解釋自己的公司為什麼要為谷歌做貢獻。”

更多支援和治理

與此同時，谷歌工程副總裁Chen Goldberg在一篇部落格文章中指出，根據CNCF DevStats的資料，谷歌已經為Istio提供了超過一半的貢獻和三分之二的commit。在Istio採用Envoy後，谷歌也成為Envoy的最大貢獻者。

Goldberg寫道：“Istio是Kubernetes生態系統中最後一個位於CNCF之外的主要組成部分，其API與Kubernetes非常一致。在我們最近向CNCF捐贈Knative之後，Istio將在基金會的支援下完成我們的雲原生堆疊，並使Istio更接近Kubernetes專案。加入CNCF還可以讓貢獻者和客戶更容易地展示支援和治理，使其符合其他關鍵雲原生專案的標準，因此，我們很高興能夠幫助支援該專案的增長和採用。”

Istio加入CNCF對Solo來說只是個好訊息——它是Istio工具的領先供應商。當然，CNCF的支援只會讓Istio更加強大，這會轉化為Solo.io的Gloo Mesh和其他基於Istio的產品的效能優勢。

Solo的創始人兼執行長Idit Levine說：“五年前，我們對Istio下了賭注。即使它不在CNCF，我們也相信Istio是最好的服務網路。之前人們對Istio為什麼不在CNCF有點困惑，甚至有點擔心。現在，我認為Istio加入CNCF將使Istio成為服務網格的事實標準。”

Solo全球現場技術長副總裁Christian E.Posta和現場工程師Rinor Maloku在《Istio in Action》一書中對服務網格進行了定義。Posta和Maloku寫道，這是一個相對較新的術語，“用來描述分散的應用程式網路基礎設施，使應用程式具有安全性、彈性、可觀察性和可控性。服務網格以這種方式描述了一種架構，它由一個資料平面和一個控制平面組成，資料平面使用應用層代理代表應用程式管理網路流量，控制平面管理代理。Posta和Maloku寫道，這種架構“允許我們在應用程式之外構建重要的應用程式網路功能，而不依賴於特定的程式語言或框架”。

“Istio是一個服務網格的開源實現。它最初由Lyft、谷歌和IBM的人員建立，但現在它擁有一個充滿活力、開放、多樣化的社群，其中包括Lyft、紅帽、VMware、Solo.io、Aspen Mesh、Salesforce和許多其他人。Istio允許我們構建可靠、安全的雲原生系統，並在大多數情況下解決安全、策略管理和可觀察性等難題，而無需更改應用程式程式碼。”