Balancing minimalism with the pressure to deliver new features is not a concern unique to service mesh. It’s a question any team overseeing well-adopted open-source software must address at some point. Still, for service mesh, providing a standard means to extend the platform could help address custom capabilities and benefit unique container ecosystem deployments.
It appears that Envoy-based service meshes are rallying behind a standard way to extend the mesh: using WebAssembly to add custom plugins to the Envoy Proxy filter chain. This has spawned a repository hub of third-party reusable plugins to act on incoming requests (similar to Docker Hub). But, how are non-Envoy meshes addressing extensibility? Could a similar ecosystem emerge?
I recently met with William Morgan, Linkerd creator and CEO at Bouyant, to learn about Linkerd’s approach to extensibility. Morgan explained that the Linkerd philosophy is to privilege modularization over bloat to retain a lightweight, minimalist approach. Below, we’ll explore what out-of-the-box customizations Linkerd provides and see what plans are on the horizon for third-party extensions.
Comparing Service Mesh Proxies
First off, what is service mesh? Service mesh places network proxies beside containers to handle cross-cutting concerns. This permits an abstracted method to quickly apply things like load-balancing, traffic control, policies, metrics or security for service-to-service communication across a herd of microservices.
Some service mesh leaders point toward consolidation around Envoy as a standard proxy for service mesh data planes, but not all agree. For example, Linkerd opted not to use Envoy. Morgan still supports this decision as Linkerd releases v2.10.
In short, it comes down to retaining a lean solution. “Using Envoy wouldn’t allow us to build the lightest, simplest and most secure Kubernetes service mesh in the world,” writes Morgan in a recent blog post. Instead, Linkerd uses a “micro-proxy” built specifically for the linkerd2-proxy project. With nearly 7,000 stars and over 700 forks on GitHub, it seems many developers appreciate the ultra-light approach of linkerd2.
While the general trend is to add more and more, Linkerd is looking for ways to keep things slim. “Linkerd was built for a particular need, with a desire to keep it lightweight and minimalist,” Morgan says.
Assuming more default configurations would go against this lightweight ambition, Morgan explains. Instead, there are ways to integrate extensions without making them part of the core project. This could be accomplished by taking an existing Kubernetes object and giving it syntactic sugar to make it feel like the rest of Linkerd, Morgan says.
He described a few ways to customize and extend Linkerd:
- Metrics and observability: Linkerd is shipped with a telemetry pipeline and a dashboard to visualize helpful metrics. However, in some cases, this may be “vestigial.” Therefore, in v2.10, it was removed by default. Users can still opt-in with a single command.
- Ingress controllers: Ingress controllers could be pre-packaged as an extension. While this isn’t part of the core Linkerd project, it would be easy to add.
- Multi-cluster functionality: Providing the ability to communicate seamlessly between clusters could be beneficial for disaster recovery. In Linkerd, this is on by default, but can be switched off.
Providing opt-in and opt-out capabilities gives mesh users more size and complexity preferences to choose from, Morgan says. “The more control we can give users over the exact surface area, the better,” he says.
Service Mesh Extensibility
Though Linkerd has laid the groundwork for third-party extensions, the project hasn’t really seen momentum in this area, Morgan notes. He’s also not convinced WebAssembly is the right tool for the service mesh proxy use case.
“WebAssembly, as a technology, is sound,” Morgan says. It’s an incredible design tool for in-browser situations; for example, Sigma describes how they cut load time by 3X using WebAssembly. “But, using WebAssembly for data plane plugins in service mesh? I think that’s 90% marketing and 10% hope.”
Linkerd maintainers simply have yet to find a concrete use case for WebAssembly in Linkerd. While this could change over time, Morgan currently advocates for “supreme focus” in finding ways to use service mesh to solve concrete use cases. “There’s a tendency in the cloud-native space to jump from one hype train to the next,” he adds.
Finding an ROI For Service Mesh
Naturally, adding more technology to the stack incurs additional overhead in terms of compute, onboarding and ongoing maintenance. Therefore, it’s important to consider if service mesh is worth it for your scenario, and find where your break-even point lies.
Morgan believes the core benefits of service mesh can be delivered in a low-cost way. Of course, it will be “dramatically different depending on the nature of service mesh,” he adds. But when it comes to extensions, juicing up the mesh with too many abilities could amplify this cost and result in too much overhead. “Everything that we add to a project exacts an operational cost to the user,” he notes.
Morgan is also a bit queasy about the idea of using service mesh as a gateway to externalize microservices as API products. While others are more bullish on the concept, Morgan feels organizations require a separation between business and operational logic for long-term viability. “There is a set of concerns around handling traffic from the outside internet, which is totally untrusted, [and those are] different from the set of concerns around handling traffic within the cluster,” he says.
It’s an interesting argument – some groups emphasize adding more to the mesh, while others aim to slim it down. It seems that for some, before extending service mesh, ensuring the mesh delivers tangible value with minimal overhead is a more pressing concern.