Microsoft has spearheaded the launch a new platform targeted at providing developers with interoperability across different service mesh technologies running on Kubernetes. The move comes at a critical time for service mesh technologies that are increasingly being looked at to help manage sprawling container deployments.

The latest push is through the Service Mesh Interface (SMI) platform. It defines a set of common, portable APIs that support interoperability across service mesh technologies like Istio, Linkerd, and Consul Connect. A service mesh is a dedicated layer for managing, controlling, and monitoring service-to-service communication within an application.

Gabe Monroy, lead program manager for containers at Microsoft, noted that the explosion of microservices, containers, and orchestration systems like Kubernetes has made it more difficult for engineering teams to secure, manage, and monitor the growing number of network endpoints.

“Service mesh technology provides a solution to this problem by making the network smarter, much smarter,” Monroy wrote. “Instead of teaching all your services to encrypt sessions, authorize clients, emit reasonable telemetry, and seamlessly shift traffic between application versions, service mesh technology pushes this logic into the network, controlled by a separate set of management APIs.”

The ecosystem has developed a number of service mesh options to help with this management, but as Monroy notes, once one is picked the developers lose portability, flexibility, and are limited in their ability to benefit from innovation across the broad ecosystem. Basically, if someone picks Istio for their service mesh they are locked into using Istio for all of their needs unless they want to deal with more coding.

SMI provides a standardized API that will allow for the ability to deal with traffic policy, traffic telemetry, and traffic management across different service mesh technologies. It is specified as a collection of Kubernetes Custom Resource Definitions (CRD) and Extension API Servers. These APIs can be installed onto any Kubernetes cluster and manipulated using standard tools.

The SMI specifications also define a set of common APIs that allow service mesh providers to deliver their own implementations. That integration can be through the use of SMI APIs directly or through the use of build operators to translate SMI to native APIs.

Others supporting the project include Linkerd, HashiCorp, Solo.io, Kinvolk, Weaveworks, Aspen Mesh, Canonical, Docker, Pivotal, Rancher, Red Hat, and VMware.

The SMI launch comes at a critical time for the ecosystem. A number of initial options have been available for several years, but the recent growth in the use of Kubernetes as the de facto container orchestration platform has also spawned the greater use of containers to support applications.

Istio is viewed by many as the most likely winner among currently available service mesh technologies. It was established in mid-2017 with backing from Google, Lyft, and IBM and has since seen rapid adoption.

Istio provides developers with visibility into microservices without the need to change application code. The platform sits at the network level and uses a substrate for microservices development and maintenance. This allows for the decoupling of management from application development.

Linkerd has been around longer, having initially been developed in 2015, and is viewed at the other most popular option. It was adopted into the Cloud Native Computing Foundation (CNCF) in 2017, which is an advantage it might have over Istio that remains outside of official CNCF support. However, a majority of its code commits come from a single vendor – Bouyant.

It should be noted that none of the initial Istio backers have thrown their names behind the SMI effort, while Bouyant is definitely on board.

Tom Petrocelli, a research fellow at Amalgam Insights, recently released a report on the service mesh space that noted the “unfortunate rivalry” between the two platforms could act “as a drag on the market.”

“It introduces unnecessary conflict, confusion, and distraction,” Petrocelli wrote. “Not only is this unfortunate but unnecessary. There is plenty of headroom for many vendors and approaches.”

Petrocelli, writing before the SMI project was announced, did add that emerging innovations like a service mesh orchestrator “will be especially important for multi-cloud and hybrid environments that may be running service meshes with different technology.”