The Service Mesh Interface (SMI) specification provides an abstraction layer on top of different service mesh implementations, with the goal of facilitating tooling to be built on top of the interface and also allowing the swapping of compliant implementations. Brendan Burns, co-founder of Kubernetes and currently Distinguished Engineer at Microsoft, spoke recently at the QCon New York 2019 Conference, about the new specification and its future roadmap.
Burns discussed the current service mesh landscape, where there is lot of fragmentation, confusion and complexity with several different implementations in the market. When adopting service mesh-based solutions, organizations deploy a large and important part of the application architecture to the service mesh, so it's not easy to rollback or rip out at a later time if something doesn't work. Users typically need to decide between multiple tools and integrate them to work with each other or pick a single implementation which may not have all the features they need.
Many industry entities thought that the service mesh ecosystem needed a common standard to address these challenges, which led to the creation of SMI specification. The SMI abstraction layer provides an easy-to-consume API that can be implemented by many different service mesh implementations (such as Istio, Linkerd, or Consul Connect). The approach to developing the SMI isn't a new pattern, as it's similar to how other specifications have emerged, such as Open Container Initiative (OCI), Container Network Interface (CNI), Container Storage Interface (CSI), and StorageVolumes.
The SMI specification goals include the following:
- Isolate concepts from implementation; right now the product is the implementation
- Provide the “core concepts” of service mesh
- Release and iterate
- Build a community around a service mesh as a concept
Burns talked about the reasons behind this approach: users need service mesh concepts, not implementations; tool vendors need abstraction, not specialization; and the implementors need isolation from users. Service Mesh Interface community partners include Microsoft, Linkerd, HashiCorp, Solo.io, Red Hat, Pivotal, VMware, among others.
Burns gave an overview of Service Mesh Interface API which includes the following components: TrafficSpec, TrafficTarget, TrafficSplit, and TrafficMetrics. SMI reuses Kubernetes APIs as much as possible for all of these features. He discussed how Routes and Traffic Targets are configured, and showed example YAML configurations. He also demonstrated how to configure the other aspects like TrafficSplit and TrafficMetrics, and mentioned that when you define a traffic split configuration, Kubernetes creates a new service for splitting the traffic for the incoming requests.
SMI spec currently has three service mesh implementations: HashiCorp's Consul, Linkerd and Istio. It also supports tooling with frameworks like WeaveWorks' Flagger and Rancher Labs' Rio.
If you want to learn more about Service Mesh Interface, check out the specification, Github project, and the SDK. You can also check out the SMI webinar which contains example code that you can use to run the services on a Kubernetes Cluster hosted in Azure cloud platform.