CNCF Projects Bring Service Mesh Interoperability, Benchmarks
Both the Meshery and Service Mesh Performance (SMP) projects joined the Cloud Native Computing Foundation (CNCF) earlier this month at the Sandbox level.
Meshery is a multiservice mesh management plane offering lifecycle, configuration, and performance management of service meshes and their workloads, while SMP is a standard for capturing and characterizing the details of infrastructure capacity, service mesh configuration, and workload metadata.
When the projects first applied in April for inclusion, the Technical Oversight Committee (TOC) had one clarifying question for them: should they be combined with or aligned in some manner with the Service Mesh Interface (SMI) project?
Lee Calcote, founder of Layer5, the company partly behind both of the projects, explained that it was an alluring prospect for the CNCF, but that, for the time being at least, the projects would continue on their own separate paths.
“For the TOC, what was enticing about that particular consideration is, this would mean the CNCF would then have a would then have a project that says, ‘Here is what makes a service mesh,’ and then here’s the thing that verifies that, in fact, it is a certain kind of a service mesh,” said Calcote. “So all in one project, it’s defining things that are service meshes, validating that, in fact, they adhere to these specifications that they are what they say they are, and then Meshery does more on top of that, in terms of helping people get run service mesh successfully.”
Calcote, who also serves as the chair of the Network special interest group (SIG) at the CNCF, said he then presented to the CNCF the following diagram, which shows the relation between the three projects. For the time being, he said, both SMI and SMP are “relatively younger projects, both of which still are figuring out what they want to be when they grow up,” and may be considered for consolidation later on down the line, while Meshery has a larger focus than the two projects and will definitely be kept on its own.
While the SMI works to define the broadest characteristics that could apply to something defined as a service mesh, looking for the lowest common denominator, Meshery works in the opposite direction, trying to accentuate the differences and strengths of the individual services meshes. SMP, meanwhile, is more of a specification and works to provide a common format for capturing and describing data around the performance of the service mesh itself.
In comparison to SMI, Calcote said that “SMP essentially just goes a lot deeper. Part of what is trying to address is this long-standing question — and it’s a question that faces the people who are adopting a service mesh today, people who are adopting service mesh tomorrow, people who have already adopted a service mesh — What should I be measuring to consider how efficiently I’m running my service mesh?”
Between the three projects, then, users have not just a way to interface with any SMI-compatible service mesh via a common API, but also a way to measure the performance of different service meshes, and finally, a method with which to interface with and operate those service meshes while taking advantage of their specific advantages.
“It’s a multi-mesh world, that Meshery and SMI approach slightly differently, in so much as Meshery has 10 different adapters for 10 different service meshes, and it does so to allow each individual service mesh to expose its differentiated value, while SMI’s approach to that same goal is to provide a unified set of abstractions, a unified set of APIs,” explained Calcote. “Meshery doesn’t constrain your interaction to the lowest common denominator. Rather, it exposes the differentiated value of each mesh.”
Part of the goal of SMP and Meshery is to not only provide a greater level of interoperability between different service meshes, but also to give users easily accessible information around the performance of those different service meshes, to better choose which one will serve them best, in the form of a “MeshMark.” With MeshMark, SMP is aiming to provide a benchmark for comparing different service mesh setups, according to the numerous characteristics and conditions necessary to make such an assessment.
“We’re trying to provide people with tools to characterize the performance of these environments. The characterizations here aren’t limited to a service mesh. They don’t only take into account the mesh. That’s actually part of why SMP is different than SMI. It is that SMP says, ‘It’s all the things, it’s your clusters and your nodes. It’s what workloads you’re running,” said Calcote. “Part of its goal is, alongside Meshery, to help in a vendor-neutral way to facilitate choice of service mesh, to help people understand the overhead involved in running a bunch of proxies.”
Armed with this information, they can then use Meshery to deploy and operate any of the 10 service meshes it comes with adaptors for. Calcote said that Meshery will try to complement the existing service mesh control plane, in order to make operation easier and to add on other functionality, such as facilitating chaos engineering, or even taking on some level of business logic, given its access to every packet moving over the network.
“Part of the belief is that service meshes are an inevitable new layer in your cloud native infrastructure that over time will be a ubiquitous component,” said Calcote. “There’s a lot that can be done in the network, a lot of intelligence, and so Meshery, as a management plane, picks off some of those features.”
