Microsoft has launched its Service Mesh Interface (SMI) spect, promising to knit competing service meshes together with support from a raft of cloud native players.

It might feel like service meshes are like buses – you wait ages for a technology that promises to move intelligence back into the network, then a load turn up all at once.

Microsoft said SMI would define “a set of common, portable APIs that provide developers with interoperability across different service mesh technologies including Istio, Linkerd, and Consul Connect.”

As well as Microsoft, the project has been kicked off in “partnership” with Linkerd, HashiCorp, Solo.io, Kinvolk and Weaveworks.

“We see a proliferation of service mesh technologies with many vendors providing new and exciting options for application developers,” Microsoft’s lead program manager for containers, Gabe Monroy wrote.

“The problem is developers who turn to mesh technologies must choose a provider and write directly to those APIs. They become locked into a service mesh implementation. Without generic interfaces, developers lose portability, flexibility, and limit the ability to benefit from innovation across the broad ecosystem.”

With SMI, Microsoft promises a standard interface for meshes on Kubernetes, a basic feature set for “the most common mesh use cases”, the ability to support new capabilities over time, and “space for the ecosystem to innovate.”

Monroy said the top three service mesh features demanded by enterprise customers were: traffic policy; traffic telemetry; and traffic management.

Going beyond these, he said, “With many exciting mesh capabilities in development, we fully expect to evolve SMI APIs over time, and look forward to extending the current specification with new capabilities.”

HashiCorp said its Consul software “will support the [SMI] Traffic Access Control specification, with possible integrations for the others in the future.”

Red Hat promised “As SMI matures as a standard interface for meshes on Kubernetes, we plan to utilize its capabilities across OpenShift Service Mesh so our developers have the flexibility of a common API to build on and our customers have a consistent experience as we evolve and improve the product.”