This article is more than 1 year old
Looks like we've got ourselves into another fine mesh: Enter the Service Mesh Interface
Microsoft pushing standard for new containery hotness
KubeCon Europe Microsoft took to the stage at KubeCon in Barcelona today to push its take on the proliferation of mesh technologies that have sprung up around the container-happy tech.
The Service Mesh Interface (SMI) represents an attempt to bring a little interoperability into an increasingly disparate meshy world
Meshes have been all the rage lately. More than one person The Register spoke to at KubeCon remarked that while the tech used to be the new shiny, it really was about time vendors got their collective act together to make the thing work.
To recap, a service mesh describes the network of containers and services that spring up as part of a distributed application. It comprises all the hooks, connections and infrastructure needed to communicate.
With great scalability comes great management pain: the mesh increases in complexity as it grows. Technology such as Istio and its ilk exist to deal with the problem by making the network itself smarter. Rather than having components take care of functionality such as load balancing, versioning and the like, a service mesh shunts this onto the network via a set of management APIs.
This is all well and good, until one realises that as service mesh technology vendors have emerged, so has a variety of usually incompatible APIs, forcing a user to pick their preferred tech and face lock-in if they ever wish to go elsewhere.
Enter SMI which Microsoft is pushing, along with other mesh-minded outfits, such as Solo.io, Hashicorp and Buoyant.
Following the likes of Ingress, SMI isn't an implementation but instead a set of common APIs which Service Mesh vendors must build against. Or create a layer to translate SMI to their native API.
Mind the crane: Windows Server containers loaded up on the Azure Kubernetes Service
READ MOREThe theory goes that as service mesh evolves, the interoperability afforded by SMI will make it considerably easier for tools and utilities to integrate with existing providers rather than just picking one technology and gambling that it will win out.
The first SMI specification will focus on traffic: applying policies, capturing metrics and shifting and weighting traffic between services.
Idit Levine, founder and CEO of Boston-based Solo.io, was on modest form, declaring the technology as "probably one of the biggest things that will happen in the conference today" in an interview with The Register. She then qualified that with "because service mesh is such a hot topic".
Indeed it is. One of the head honchos of Red Hat's Open Shift, Brian Gracely, told us that "a year ago, mesh was the thing, now it's like what's the performance of mesh? How do I do mesh across clouds?"
Solo.io, a 15-person startup, has smarts in the service mesh arena, last year emitting the open-source SuperGloo, an abstraction layer for consistency across different meshes. The company followed that up with the Service Mesh Hub last week, which extended SuperGloo with a dashboard to install and operate meshes along with extensions via an Extension Catalog.
The Hub is a reference implementation of the SMI specification.
Microsoft's selection of the outfit as a mesh mate is therefore not terribly surprising, and using the might of the Windows giant to, er, encourage mesh providers to adopt the specification will do Solo.io's Service Mesh Hub no harm either.
And as for who will be the custodian of this standard? Not one vendor, according to Levine: "We're going to give it to the CNCF."
So there. ®