I recently returned from giving a talk at this year’s European DevConf in the Czech Republic. It was my first time going and it was an extremely positive experience—I had some great discussions with people and attended some really insightful sessions. As a service mesh engineer, I was also excited to see that it seems to be a really hot topic right now. You could argue, though, that it’s perhaps a little too hot. In fact, expectations for service mesh are getting slightly out of hand.
This perspective informed my own contribution at DevConf, where I shared an experience of trying to really push service mesh to deliver on the promise we keep hearing so much about. The work I previewed is my own, but it comes out of the development I’ve been doing at VMware on the open source Network Service Mesh project, which aims to enable advanced networking for cloud native, container-based solutions. The challenge I gave myself was to see if I could solve the specific, Telco-type problem of applying different kinds of filters to video through a service mesh solution.
Could I, for example, embed subtitles on the video, add a logo over it or scale it up or down? These are all common requirements for video distribution, but was it possible to solve them with this modern approach? My talk explained how I tackled the challenge, how things changed as I went along and offered a first look at the solution I came up with – which I’m calling Cloud Native Video Processing – and have now shared on GitHub as another example of how we can use service mesh out in the wild.
It’s not a huge project and it’s not perfect by any means, but I think it shows that it really is possible to go beyond the traditional use cases for service mesh technologies, like traditional web applications structured as microservices or in depth telemetry. I encourage you to watch the video and explore the code if you are interested, but I’ll share two key takeaways from the project here:
The first has to do with a major claim of service mesh proponents: that the infrastructure should be transparent to people writing applications. I found that this wasn’t entirely true, at least when you are trying to meet a lower level networking challenge like video processing. For these kinds of workloads, you do still need to design specifically for the service mesh—you can’t simply do what you’ve always done by default.
The second finding has to do with protocols. Service mesh assumes higher level protocols like HTTP—which is great for web application workloads—but I found that it genuinely is challenged when you try to go to a lower level. So, this project became an important validation for the approach underlying the lower level-enabling Network Service Mesh project that I mentioned above.
Cloud Native Video Processing, in other words, turns out to be a good use case not just for the service mesh approach, but also for the value of Network Service Mesh as an extension of that approach. Once again, please feel free to check out the project on GitHub if you are interested, and many thanks to my VMware colleagues for their feedback and advice.
Stay tuned to the Open Source Blog and be sure to follow us on Twitter (@vmwopensource) for the latest news and updates.
