服务网格是一组重要的功能，可以在运营服务式架构时解决一些困难的服务到服务通信挑战。就像Kubernetes和容器有助于在一组计算机上提供一组很好的抽象来部署和运行工作负载一样，服务网络也出现了抽象网络，使运营商和开发人员能够控制请求路由，可观察性和政策执行。这提供了很多潜力。
唯一的问题是，虽然Kubernetes已经成为用于抽象调度工作负载的底层基础架构的强大API，但是没有一个单一的实用API可以显示服务网格中所需的功能。
“服务网接口”的公告提出SMI规范打算统一运行在Kubernetes上的服务网格所需的功能和API（尽管这有助于为在k8s之外运行的服务网络奠定基础）。
样做对服务网格社区有几个直接的好处：
- 服务网格实现可能很复杂; 专注于表现出与实现无关的关键功能的API可提高整体可理解性
- 在服务网格社区的动荡世界中，关注能力并通过标准接口减少了对任何特定实现的依赖。
- 服务网格公开了一组强大的旋钮和杠杆，用于操纵和定义规则（编程网络）; 有些东西需要协调这些旋钮和杠杆; 是否由供应商提供的扩展或您自己编写的扩展 - 将网络编程到任何一个特定的实现，其假设将您与此实现联系起来，并可能使您的实现复杂化
- 为较低层的稳定性（如服务网格）奠定基础工作，为整个生态系统获胜的进一步创新打开了大门
最低公分母
社区中有些人对这种方法的可行性表示怀疑，而恕我直言，他们的声音非常重要。例如，我非常尊重的Tim Hockin提到了SMI方法成为“最低共同点”的可能性，并且可以取悦任何人
服务网格的新功能仍然可以肯定出现（如不同服务网格实现的时间点上的不同功能集所示），但Istio，LinkerD，Consul，App Mesh等的功能似乎正在围绕以下方面展开：
- 流量请求路由（加权路由，L7请求级别匹配等），可以启用金丝雀释放等功能。这样做的目的是减少爆炸半径的变化影响。
- 请参阅Istio，App Mesh; Linkerd和Hashicorp Consul的流量路由
- 顶级度量标准集合，如延迟百分位数，吞吐量，错误率
- 见Istio，App Mesh，Linkerd; Consul将在不久的将来轻松配置它
- 政策执行基于服务标识
- 请参阅Istio，Consul，Linkerd和App Mesh，以便在不久的将来添加它
语义并没有那么不同
目前，Istio已经为这些功能提供了成熟和开发的实现，但是还有其他一些实现也实现了这些功能并且正在发展壮大。实际上，这些实现的方向彼此非常相似，在易用性，用户体验，管理，集成等方面存在重要差异。但重点是“服务网格提供的功能”的语义。没有那么不同。恕我直言，围绕这些不那么不同的能力的API可能在社区的帮助下，包括Istio, linkerd, consul, App Mesh ！
Envoy Proxy变得普及
关于控制平面本身，其他服务网格提供商也希望在Envoy之上构建，我们将看到它们在实现中也没有那么多分歧。
基于现有实现
最后，SMI部分来自现有的服务网格实现。这不是一个梦想的，由财团驱动的，在由没有实施，操作甚至使用服务网格的人们带领的天空中的馅饼。相反，社区目前由具有现实生活，部署在生产中的服务网格实现的供应商和组织提供。从这些经验中获得实用API的能力并非遥不可及。
SMI由供应商领导
我所尊重的社区中另一个突出的声音是Zack Butcher，他表达了他的观点，即SMI没有通过设计坏气味的测试，因为它是由想要卖东西的供应厂商领导的。
SMI Spec的创始人之一Brendan Burns 有一个有趣的看法：
“服务网格中的当前技术水平，你必须将自己锁定到一个实现是不好的。此外，没有人可以为所有服务网格构建共享工具，这更糟糕。并且没有人能够构建包含服务网格apis 而不会选择实现的的Helm charts。“
在我工作的Solo.io，我们有兴趣看到服务网格的单一界面出现，因为我们经常会遇到需要解决的客户：
- 不确定选择哪个网格
- 想要建立在网格之上，但希望在动荡的环境中对冲他们的赌注
- 想要更友好的用户体验来管理他们的服务网格
- 需要将他们的南北流量与他们的东西方向的网格决策相结合
- 希望供应商帮助他们，但......
- 不确定任何一个网格供应商的动机
此外，企业发现供应商之间相互竞争以满足他们的最终需求具有很大的价值（并且在此找到了很多价值！）我们在过去看过这种在Java和Java EE等社区中的表现。
赢家通吃？
在我看来，现实是我们最终将采用多种服务网格实现（无论是否设计），我们需要以某种方式统一它们（在其功能级别，集成级别）与他们，或管理他们或所有上述的水平）。
例如，我们与客户和潜在客户一起看到的真实用例是当前对Istio进行内部部署的投资，但其他团队将进入AWS并全力以赴，包括使用AWS App Mesh。他们有一个真实的情况，他们需要在这些网格之上构建工具，他们正在构建自己的抽象。如果存在社区主导的抽象，他们会使用并看到这样做的很多价值（至少不必自己做！）。
推动服务网络社区向前发展
目前，社区中的健康辩论是必要的，以表达我们可以探索和克服的关注点和异议以及机会，以便为最终用户和平台构建者提供服务网络的强大功能。服务网格代表了一组强大的应用程序网络功能，但实际上这不是最终游戏。
就像像Kubernetes这样的容器和编排系统已经使“容器变得无聊”，服务网格也会使应用程序网络变得无聊。为用户，社区以及参与此社区的组成供应商创造价值的有趣机会将在堆栈中更高，包括在服务网格之上。
如果服务网格生态系统最终成为赢家 ，那就太棒了！我们将有一个API来构建我们的系统。如果没有，并且我认为这会是更高概率的命题，那么我们最好共同努力找出正确的API来展示这些可以通过服务网格提供的重要功能，而不管实现如何。