Future of Service Mesh - Sidecar or Sidecarless or Proxyless?

The presentation discusses the benefits of a sidecarless architecture for service meshes and the use of ebpf technology. The main goal is to make service mesh infrastructure more reliable and less complex.

• Sidecarless architecture removes the need for injection and containers, reducing resource overhead and complexity.
• The use of ebpf technology allows for customization of the Linux kernel to improve reliability.
• The focus should be on making service mesh infrastructure boring and reliable, rejecting new and shiny features.
• Z-tunnel is not replacing Envoy, but rather providing an optional waypoint proxy for service counter namespace basis.
• The goal is to make service mesh infrastructure critical infrastructure that can be depended on.

The speaker compares the goal of service mesh infrastructure to that of the Linux kernel, which has become critical infrastructure that can be depended on. The focus should be on making service mesh infrastructure boring and reliable, rather than constantly adding new features.

As service mesh APIs become standards for operators and developers per the GAMMA initiative, there are still various different architecture choices to run service meshes, whether it is sidecar or sidecarless or even proxyless. What about proxies, Envoy C++ based proxy or Rust based proxy? What are the design considerations when choosing one architecture over another? This panel brings experts from Google, IBM, Solo and Microsoft to share their perspectives on sidecar, sidecarless and proxyless for future of service meshes and what you should consider when deciding which architecture is the right choice for your organization. Initial seeding questions: - We all understand sidecar architecture for service mesh, can you explain what sidecarless service mesh is? - Are people interested in a non-sidecar approach for service mesh? Why? - Does proxyless mean eBPF without proxy? - What about L7 processing - which architecture should we use?