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允许我们构建可靠、安全的云原生系统，并在大多数情况下解决安全、策略管理和可观察性等难题，而无需更改应用程序代码。”