Today we are excited to launch Service Mesh Interface (SMI) which defines a set of common, portable APIs that provide developers with interoperability across different service mesh technologies including Istio, Linkerd, and Consul Connect. SMI is an open project started in partnership with Microsoft, Linkerd, HashiCorp, Solo.io, Kinvolk, and Weaveworks; with support from Aspen Mesh, Canonical, Docker, Pivotal, Rancher, Red Hat, and VMware.

For years, the mantra for network architecture was to keep your network pipes as dumb as possible and build smarts into your applications. The network’s job is to forward packets, while any logic for encryption, compression, or identity lives inside the network endpoints. The Internet is premised on that mantra, so you could say it has worked fairly well.

But today with the explosion of micro-services, containers, and orchestration systems like Kubernetes, engineering teams are faced with securing, managing, and monitoring an increasing number of network endpoints. Service mesh technology provides a solution to this problem by making the network smarter, much smarter. 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.

This is a popular pattern in the cloud-native ecosystem. We see a proliferation of service mesh technologies with many vendors providing new and exciting options for application developers. 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.

Service Mesh Interface provides:

  • A standard interface for meshes on Kubernetes
  • A basic feature set for the most common mesh use cases
  • Flexibility to support new mesh capabilities over time
  • Space for the ecosystem to innovate with mesh technology

What SMI covers

We have joined forces with HashiCorp, Buoyant, Solo.io, and others to build initial specifications for the top three service mesh features we hear from our enterprise customers:

  1. Traffic policy – apply policies like identity and transport encryption across services
  2. Traffic telemetry – capture key metrics like error rate and latency between services
  3. Traffic management – shift and weight traffic between different services

This is just the beginning of what we hope to achieve with SMI. 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.

How SMI works

The idea behind Service Mesh Interface is not new. It follows in the footsteps of existing Kubernetes resources like Ingress, Network Policy, and CNI. Like Ingress or Network Policy, SMI does not provide an implementation. Instead, the SMI specification defines a set of common APIs which allows mesh providers to deliver their own best-of-breed implementations. Integrating with SMI can happen two ways. Tools and mesh providers can either use SMI APIs directly or build operators to translate SMI to native APIs.

“SMI is a big step forward for Linkerd’s goal of democratizing the service mesh, and we’re excited to make Linkerd’s simplicity and performance available to even more Kubernetes users.” William Morgan, Linkerd maintainer

“The standardization of interfaces are crucial to ensuring a great end user experience across technologies and for ecosystem collaboration. With that spirit, we are excited to work with Microsoft and others on the SMI specification and have already delivered the first reference implementations with the Service Mesh Hub and SuperGloo project,” said Idit Levine, Founder and CEO of Solo.io

Ecosystem friendly

For early technologies like service mesh, it’s important we create space for the ecosystem to innovate and explore different approaches to solving customer problems. As service mesh technology continues to evolve, the interoperability provided by SMI will help the emerging ecosystem of tools and utilities that integrate with existing mesh providers. Instead of integrating with each mesh individually, tools like flagger, and SuperGloo can integrate with SMI, gaining cross-mesh capabilities.

“The interest and momentum around service meshes has reached a point where the industry needs to collaborate on a set of standards that can help assure their success,” said Sushil Singh, Chief Architect, VMware NSX Service Mesh at VMware. “Service Meshes provide rich set of foundational capabilities for the future of applications. It’s the right time to work towards defining standard APIs that simplify the consumption and capabilities of service mesh technology to enable a healthy ecosystem. VMware is excited to participate in this very important effort.”

“Customers and community members alike have been seeking a way to better standardize the configuration and operation of service meshes. With the beginning of the Service Mesh Interface (SMI), we see this as a way to help maximize choice and flexibility for our Red Hat OpenShift customers. This flexibility provides users the ability to prioritize functionality over implementation details,” said Brian ‘Redbeard’ Harrington, principal product manager for service mesh, Red Hat.

Join the conversation

We cannot wait to see how the Service Mesh Interface evolves and welcome everyone to join the conversation. Visit the SMI website.