This is the second in a two-part network service mesh series aimed at untangling the current “mess of meshes” in virtualized open source networking. Last time, we looked at service meshes through the lens of Istio and Envoy, learning that they are application-centric tools that take on much of the higher-level networking functionality developers previously had to deliver through their own apps. By delegating that functionality to dedicated service meshes, developers can now focus on the core business differentiators of their applications.
But more recently—and somewhat confusingly—we’ve seen the rise of the new open source Network Service Mesh project to which Nikolay has been actively contributing. How is that different from the service meshes that we described in part one?
Perhaps the best way to make the distinction is to say that while traditional service meshes are application-centric, Network Service Mesh is connectivity-centric, or connection-centric.
As we described in earlier blogs, this project maps the concept of a service mesh onto the lower levels (i.e. L2/L3) of the networking stack. It does so in order to solve issues that have not actually been solved by virtualizing networking. There are use cases, for example, where people need much finer-grained control of their lower-level networks than they were able to grasp with a service mesh alone. The solution there is clearly to engineer the same kind of control you have for higher-level protocols with a service mesh but at a lower level.
That’s what the Network Service Mesh project aims to offer: the same discoverability, durability, configurability, and security as a service mesh but for lower-level workloads.
Network Service Mesh Use Cases
While Network Service Mesh is still a very young project, we foresee use cases in a variety of domains:
- In high-performance computing to leverage a cloud native approach to workloads. Cloud native environments aren’t optimized for high performance at present because cloud workloads were originally designed with higher-level traffic in mind.
- When you want to use a protocol that isn’t typically available in Kubernetes. Storage Area Networking is a case in point, where Network Service Mesh can be used to make the storage area network part of the cloud native deployment and manageable through cloud orchestrators like Kubernetes.
- As a pathway to multi-cluster connectivity, where you can use Network Service Mesh to essentially abstract the concept of a distributed service.
- To interconnect virtual machine-deployed and cloud-native, or container-deployed, workloads.
- In Network Functions Virtualization (NFV) like 5G and edge-type deployments.
Network Service Mesh isn’t delivering all these yet, of course. It’s just a year old. But people from various communities are already asking us what we will likely be able to provide them with and when. These questions are helping us figure out what capabilities to build into the project and in which order.
Network Service Mesh and Kubernetes
A quick aside here to explain how Network Service Mesh works with Kubernetes: While not directly tied to Kubernetes, it is capable of enhancing the Kubernetes networking model in a way that doesn’t disrupt the features that developers already know and love. The Network Service Mesh does not seek to integrate within or replace the CNI but instead works in parallel with it. Network Service Mesh allows for a separate (and performant when required) data path from the CNI.
In practice, this means that architects/developers can bring a chosen data plane to their Kubernetes deployments and rely on Network Service Mesh to provide both the local and remote connections needed to string together the network service in its entirety. This differs from other approaches, such as MULTUS, in that additional interfaces can be added to pods through a variety of mechanisms not directly controlled by the CNI.
A future together?
Network Service Mesh and service meshes aren’t competing with each other; they are operating at different levels. And as Network Service Mesh grows in popularity, we foresee people gaining the most benefit from using the two together, gaining finer control over more levels of the networking protocol stack.
We don’t necessarily see the two projects merging completely, but it would make sense for them to increase their cooperation so they better complement each other and provide a better overall solution.
To this end, we have already made steps towards integrating Network Service Mesh with Envoy, which is essentially the lowest layer of the full Istio stack. Check out its GitHub page to find examples of how to make use of Envoy within Network Service Mesh.
Other next steps – a bright future
We see both service mesh and Network Service Mesh continuing to grow in the future.
Service meshes are already widely adopted and are on track to augment software-defined networking in the enterprise space. Quite a few vendors now contribute to open source service mesh projects like Envoy and Istio, and many are using them for their own production needs. A number of major clouds providers have also made service mesh available as part of their offerings, and several companies now offer Istio and Envoy support services.
In many cases, vendor-specific service mesh integrations are now tightly woven into their portfolio offerings. But while these integrations currently look as if they are diverging to some degree, we expect these efforts will end up following the upstream projects source evolvement. Efforts like Service Mesh Interface are seeking to unify the API to talk to different service meshes and thus create a common landscape for end-users. In the future, we think existing solutions will converge under such common APIs, and virtually everyone will use some form of a service mesh when running their workloads in a cloud environment.
Network Service Mesh, meanwhile, is gaining attention. It’s now part of the Cloud Native Computing Foundation’s new Telecom User Group and is one of the technologies being evaluated there. It’s also working with the CNCF to enable Network Service Mesh on their new CNF testbed.
More broadly, those of us working on the project believe it has the potential to be foundational for the next generation of networking function virtualization (NFV) for telco, edge, and IoT workloads.
Lastly, we’re exploring how Network Service Mesh can be leveraged to become the underlying connectivity layer for traditional Kubernetes networking services like CNI and the more recently-established service mesh solutions.
As we noted at the start of this pair of blogs, open source networking is an exciting area to be working in these days. Watch this space for more reports on our progress in the months to come.
Stay tuned to the Open Source Blog and follow us on Twitter (@vmwopensource) for all the latest open source news and updates.
