 All right. Good morning everybody. My name is Thomas Graf. I'm co-founder and CTO of ISOvalent, but probably more importantly one of the creators of Cilium and currently the chair of the EBPF Governing Board or EBPF Foundation Governing Board. I'm trying to give an introduction to Cilium and EBPF, not Cilium, EBPF in five minutes. Let's see what that gets us. First of all, what is EBPF? How many of you, this is the first EBPF day? How many of you have been to an EBPF day before? First EBPF day. All right. Quite a few. Excellent. So you may be wondering what is actually EBPF and this is the closest accurate definition I could come to. EBPF is a programming language and runtime to extend operating systems. That sounds very abstract. A more practical comparison is EBPF is like JavaScript or Lua, but for kernel developers. Maybe you're even more confused. So let's look at this. On the left we have JavaScript, an example of JavaScript, how it's commonly used. You use JavaScript to run some code when some event happens, for example, most common example when the website user clicks on a button and submits a form. On the right side we have EBPF. Very, very similar. But you run EBPF programs in the kernel in the operating system when some event happens. For example, when a system call is being invoked, when a network packet is being processed, when a file is being accessed, and so on. So very different layers, operating system for EBPF, JavaScript, Lua, higher up in the stack, but conceptually they're actually very similar. They're making systems programmable. Why EBPF? That's the second question I usually get. Operating systems in particular Linux has become incredibly hard to change. It takes weeks or months to even get a change upstream and then years for consumers, for users to consume these Linux kernel versions, these new versions. So the innovation cycle is very, very, very long, very similar to hardware. This leads to this problem that, similar to what we have for CPUs, the operating system is essentially using building blocks because it has to predict use cases. It cannot just adopt to changing requirements all the time. That's why the kernel, the Linux kernel, typically has systems, subsystems that you, as a user, can configure. You cannot program them. For CPUs, we have solved these problems with higher-level programming languages like Java, Go, Rust, and so on. EBPF is the same concept applied to operating systems. So it gives us programmability and does allows us to continuously adopt to changing requirements and does innovate very, very quickly. That's the biggest fundamental reason why EBPF exists. Great. So we have programmability. How is this different to things like Lua or WebAssembly? Because there's lots of other languages much more widely known ones that have been around for ages that give programmability. Why and how is EBPF different? EBPF is specifically designed to be embedded into the operating system, Linux and Windows. It can interface with the Linux kernel, so it can call into kernel APIs, and it is restricted to run safely in the kernel context. But it is aimed for kernel developers and thus traditionally very hard to learn and use. Lua or WebAssembly, on the other hand, are designed to be embedded into arbitrary applications or systems. They're general purpose and they're aimed at application developers much easier to learn, but they cannot run in the context of the operating system. So the single unique feature of EBPF is that it is embedded into the operating system. That what makes EBPF unique. We could, for example, have chosen Lua as a runtime for the Linux kernel and give that a name. That would be similar to what EBPF is today. How does EBPF work? There's a language and there's a runtime. The language can be expressed in a variety of different languages. Pseudo-c code is the most common one where we use a compiler like LLVM or Clang to compile it into bytecode, but there's several different language frameworks via libpf-bcc to express EBPF programs in different higher level languages. All of this eventually produce so-called EBPF bytecode. That is our program. Then we have a runtime. This is what's embedded into the operating system. The runtime takes the bytecode, verifies it to make sure it is safe to run, just in time compiles it for efficiency, and then runs it at the requested hook points. In this example, it is being run when system calls are being invoked. This gives us these three properties. EBPF is secure. It has runtime verification. It has a sandbox concept. It has program signing. It is efficient because it is going through a just-in time compiler. It is embedded into the operating system, and it offers per-CPU data structures. It is portable. The bytecode is generic. It gets just-in-time compiled later on. It has data type discovery, BTF, as well as a stable API how to interface with the operating system. Who controls EBPF? EBPF is controlled by the EBPF foundation and the open source communities around it. If you are interested in participating on the governance side of EBPF foundation, feel free to go to ebpf.foundation. That's nice. Now we know what EBPF is. Where is EBPF used today? This may actually be a surprise. It's incredibly widely used. We could look at the Selenius file. It's everywhere, but that's kind of boring. Lots of logos. Let's look at some more extreme use cases. The cloud native landscape, we see a couple of projects using EBPF, but let's dive deeper and look at heavy applications of EBPF that you probably use every day. Facebook is using EBPF for load balancing. It's called Project Catron. It's been used in production for several weeks. All EBPF. Facebook is using this exclusively for all load balancing needs. We have all three big cloud providers, AWS, Azure, Google Cloud, using Syllium in their managed Kubernetes offerings. Many of you probably use a managed Kubernetes offering GKE, EKS, AKS at some point. They're using Syllium and does EBPF underneath. But even smartphones, this is the EBPF page of the Android operating system. Android uses EBPF. It has an EBPF loader and it uses EBPF programs to do traffic accounting. It uses it to account how much CPU memory each app uses and can even do GPU memory accounting and so on. It's all done using EBPF. So when you look at the traffic statistic of your app, how much traffic volume, how much network volume it consumed, that was counted using EBPF. Multicloud networking enterprises. There was a fantastic presentation at EBPF Summit a couple of weeks back where S&P Global presented how they're using EBPF with Syllium for a multicloud networking layer to essentially redefine how they think about networking. The talk was absolutely fantastic. It wrote to Invisible Network, S&P's global network transformation journey. You can go to EBPF.io, click on Watch Summit Recordings and you will find the talk recording. But there is one more thing because the biggest aspect of EBPF where I think we'll see a lot more innovation going forward is observability. So really happy to announce an absolutely fantastic new partnership between Grafana and ISOvalent. Grafana is bringing their entire observability knowledge and tools at Lockheed, Grafana, Tempo and so on. And ISOvalent is bringing Syllium, Tetragon, Hubble for observability and all of our EBPF knowledge and together we're building a new set of tools that you can use for observability. A couple of examples, network observability where we can now embed Grafana dashboards directly into Syllium's Hubble UI for amazing network observability, metrics for traffic volume, network policy drops, traffic volume and so on. But there is more. We can also do EBPF-based HTTP tracing and HTTP observability. And for example, build golden signal dashboards that we see on the right side of the screen, as well as integration in the Grafana Tempo where we can trace individual HTTP requests, all thanks to EBPF and those without sidecars, without proxies at all. Very, very fascinating. And last but not least, because of Syllium's Tetragon project, we also have excellent visibility into the security layer. And for example, display process ancestry, how applications behave and what commands they execute and visualize that in Grafana tool sets as well, as well as things like TLS handshake monitoring. This was a five-minute introduction to EBPF and I tried to use a couple of real-world examples as well. EBPF is already everywhere and we're using it every day. But there's lots of more exciting things coming and I'm looking forward to a whole day of presentations. Thanks to a lot, everybody.