You might know what a Service Mesh is - but what is Cilium Service Mesh? What does eBPF have to do with it? Where are the sidecars? And why is this generating so much interest? Tune in to an interview with Thomas Graf where he explains the history of services mesh, why Cilium Service Mesh is different and what that means in terms of complexity and performance! Introduction So to get started, Thomas, do you want to tell us what Cilium Service Mesh is? Absolutely. Let's do that, and I will actually share the blog I've written and we'll go through that because it has some nice pictures in it. So what is a service mesh? We'll start very broad and high level first, and then go into what is unique about Cilium Service Mesh. A service mesh is a technology that looks at providing connectivity between services and, in addition, observability, security, traffic management, and resilience. Service mesh observability What does that actually mean? First of all, we want resilient connectivity. If something goes wrong, it should retry. Very similar to TCP, we want retransmissions and connectivity to resume if there was a temporary glitch. Then we want layer 7 traffic management. We want layer 7 load balancing based on HTTP headers, host names, request-based load balancing, and so on, for HTTP, gRPC, and other layer 7 protocols. Then we want identity-based security. We want mutual authentication. We want services to validate each other's identity. We also want observability and tracing. We want to see on the request level what is being sent between services, not just at the network level but at layer 7: API calls, HTTP requests, responses, return codes, latency, and the entire service map. Sidecar-free service mesh Very importantly, we want this transparently, because in the past people built this functionality directly into applications. You might have a Python app and a Go app, and you would link service mesh functionality into each app with a library to do retries, TLS for mutual authentication, and so on. But that required modifying all your apps, and if you used different frameworks you needed different libraries. This is why the sidecar model was introduced. It moved that library into a sidecar proxy so applications could stay unmodified. In that picture, all service communication goes through a sidecar as it leaves the application and before it enters the application on the other side. What we are proposing with Cilium Service Mesh is that we want to get rid of the sidecar proxy. We don't necessarily want to get rid of the proxy. We're huge fans of Envoy. Envoy has been integrated with Cilium for many years, and quite a bit of functionality in Cilium is implemented via a combination of eBPF and Envoy. What we don't necessarily like is one sidecar proxy per app or per pod. What we're providing with Cilium Service Mesh is something much closer to how namespacing and other kernel technologies work. We want service mesh to become part of the operating system and be transparently available without requiring additional sidecar proxies. Service mesh demo We want to make service mesh as transparent as TCP is today, or as cgroups and namespacing technology are today. We see service mesh as a founding block for containers. From an integration perspective, it looks like a service mesh that sits as part of your network stack, essentially just above TCP. We see service mesh as an extension of TCP. TCP is kind of the old-school service mesh. It already has some security and retransmission functionality, and service mesh provides similar ideas adapted to microservices and cloud-native infrastructure. The reason we want to do that is that injecting a sidecar is incredibly expensive. This picture shows how a sidecar has to be injected and how traffic passes through the network stack multiple times. That comes at a pretty high cost. If you provide similar functionality directly in eBPF, there is a massive performance benefit. The yellow line here is a proxy-based infrastructure with sidecar injection, blue is the baseline with no visibility, and red is an eBPF-based HTTP visibility library, for example one that provides OpenTelemetry tracing data. That is incredibly powerful because suddenly we can get that visibility data without introducing a lot of overhead. Before we leave it off, I wanted to show the other big difference, which is the overall footprint. This picture tries to show the footprint when we're running with sidecars. On one node, if you have 30 pods, in a sidecar model you also have to run 30 sidecar proxies. In a sidecar-free model, when we make this part of the operating system and run one proxy per node or maybe one proxy per namespace, we can heavily reduce the footprint, the memory footprint, and the CPU footprint of the service mesh.