 So this talk is actually going to be one of my favorite things, it's perspective, and it kind of ties kind of the date together. And we start off with a story of six blind men discovering an elephant and kind of taking a look at it for the first time, right? So the first person, the first blind man feeling the trunk declares that it must be a snake, and the second standing by the flapping ear says that it must be a fan. The third grasping the trunk declares that this must be a spear, or the tusk, sorry, tusk being a spear. The fourth wrapping his legs around the leg, wrapping his legs, his arms around the leg says that it must be a tree trunk, and the fifth touches the side of the beast and says that this must be a wall. Finally, the sixth feeling the tail describes it as a rope. I think that many people when they start discovering and exploring eBPF for the first time kind of feel like these blind men, they're confused by how many things that eBPF can apply to, right? It's just a huge field. I mean, we've heard everything from how to handle, how to use this for networking, how to use it for security, how to use it for profiling, how to use it for application tracing. It's just, I mean, this is the reason why a lot of people call these things Linux superpowers, right? It just sort of applies to everything in the space. We even got questions about who should care about it, and the answer seems to be everyone. Yeah, pretty much everyone. Yeah, sorry, everybody is the answer. So taking these kind of, taking these one at a time, the first one that we're going to talk about is an SRE. So for the SREs among you with responsibility for keeping clusters running smoothly, eBPF is all about that large and growing set of powerful tools that make, that are available off the shelf ready and waiting to help you solve a problem that you can't solve with other means or with, or without the rich context that eBPF can provide you. At a recent eBPF summit, I actually helped host that. Brendan Gregg, who's one of the authors of the eBPF Tracework and a lot of the kind of surrounding area, gave a talk on getting started with eBPF observability, and he had a great slide in that that said, think like a sysadmin, not like a programmer. And his point I think was that you don't have to get into the low level details of eBPF and how it is implemented, or even write your own eBPF code. Just think of eBPF as a set of additional tools that you can make use of right away. I mean, like one of the things that we just saw Kyle presenting on was how to kind of build eBPF trace programs and those sorts of things, right? So for a lot of the time when we talk about like one of the biggest superpowers that a lot of people are using, it's about context. SREs love context. It's one of the things that puts a light on in the darkness, and being able to actually access that context with simple tools like eBPF Trace is a pretty powerful thing. It really moves them all forward. The next blind person that we're speaking of is the app developer, right? And what are they interested in? They're interested in debugging tools. They're interested in libraries. They're interested in flexibility. They're interested in that portability of tools that you don't have to write every single time. For most app developers like SREs, the low level details of eBPF are probably not super interesting unless you're developing eBPF code. But the context that eBPF can provide them, right? Like being able to instrument your application automatically, like we saw in the talk from Liz Rice talking about how leveraging eBPF, we're starting to kind of approach the same sort of technology that we see in typically in service meshes, right? To be able to auto-instrument an application without making changes. To be able to understand what that application is doing at runtime without actually instrumenting the application code itself, right? Pretty amazing stuff that we can actually, I mean just some of the stuff that we can do. And I think that that would be very attractive to developers. The other benefit of eBPF for application developers is that they are no longer constrained to write code in user space. Which means that like that talk that we saw, or a paper that recently came out, basically making things like memcache available so that when a system call that makes a call to memcache shows up, we just basically grab that system call and throw it directly to the memcache statement, right? Like shortcutting the whole networking process entirely. And making that local memcache statement something that you could deploy alongside all of the applications in a container orchestration system like Kubernetes. Pretty amazing stuff. One of the very first things that I saw that really blew my mind and I think would probably impress most application developers was an effort to basically allow for applications to use TLS or to use some sort of TLS authentication method without actually making any changes to the code. Again, this is one of those things where we see service mesh is really kind of taking storm. But I've seen this using eBPF with a Kafka topic, right? It's pretty amazing stuff. You can kind of change the behavior of that application at runtime without the application even being aware of it. And in so doing, reduce the burden on your application developers and give them even more security, more features, more functionality. Being able to deliver more of that functionality much faster. I think I'm going to talk about the next blind man here and not always so blind. But from the perspective of the security professional, right? And we heard this in several of the talks, but particularly from Eric and Melissa or Apple, right? eBPF is really exciting. They're probably one of the profiles of people that gets most excited about eBPF because the ability to attach probes throughout the kernel anywhere they want and see what's going on from sys calls to network packet processing. That means that they can actually monitor in real time everything that's going on in a cluster and use that to baseline normal behavior and information you can use to define policies. So we saw that with Margot Manteirola's talk where she monitored the sys calls that were happening and used that to automatically generate a sec-comp policy. How brilliant is that? The problem that most of the security professionals have is just not knowing what policies to define. Now we can use eBPF to tell us or suggest what policies should be applied in the cluster. And then, of course, you actually have the power to enforce these policies using eBPF as well. So, you know, or detect anomalous behavior and alert on it. You saw in the work with the eBPF-based Linux security module that KPC and Leo and Leonardo showed. We saw how that could really get down at the lowest levels of the Linux kernel to enforce policies that you wanted applied across the system. Or a slightly different take on this. Mauricio showed us how we could do that specific to system D. So when you start up system D, you can create on just a command line parameter saying, well, which type of file system should a particular system D module be able to access. So some really exciting things there. And really crucial to this working and being viable, because this, you know, it needs to actually work in production, needs to be acceptable to the operators, the people that are trying to make these clusters work, is the fact that eBPF enables these capabilities with a very low overhead. Right? So you can deploy it in production, enforcing these policies without having some kind of massive performance hit. And, you know, and part of how it does that is getting closer to the hardware as well. And, you know, Liz talked about how, you know, some eBPF programs could even be put down as onto the network hardware. And Dave mentioned that as well. So you really can get kind of realistic, host-based denial of service enforcement. Whereas previously, you could only do denial of service on some kind of dedicated, you know, big iron firewall box. Now you can put it in more places in the network. These kind of things are super exciting for security. I'm definitely seeing security crop up as a forensics analysis piece as well. I mean, we talked about gathering all this context and getting it off of this, getting into a data lake and those sorts of places. I mean, that's definitely a place where I see that coming up. Whether it's just network forensics, whether it's application forensics, what were the command lines, you know, like, did you see a process start after the actual running process of the container? Like being able to provide that information has been so super helpful. Duffy talked about application developers, but there's another type of developer as well. You know, the kind of maybe more rarefied era of the kernel developer. You know, and for these folks, you know, eBPF actually is an opportunity as well. It gives them the opportunity to develop and release new features without having to wait for the upstream kernel community to merge what they're working on. So you might think, well, you know, eBPF is enabling people that aren't the ones working on the core of the kernel. But I think, you know, that that's a mistake. And even for the folks who are developing on the kernel, there are going to be things where it makes sense to release it in eBPF instead of pushing changes upstream. And because that whole process just takes years and years and years to get not just get merged into upstream, but then get into all of these downstream distros and then get deployed into, you know, real-world networks. And that process gets, you know, can get bypassed. So it enables them now to innovate at the same speed as application developers. And, you know, it was one of the points that I talked about at the beginning of today. You know, and things like eBPF iterators, you know, we're getting all of these new capabilities. And Greg, he talked about, you know, how he's been leveraging eBPF iterators to create richer capabilities with the eBPF programs that he's writing. And so, you know, there's a lot of exciting things happening in eBPF for these kernel developers. And the other way of looking at it as well is not just the traditional kernel developers are now able to do more. It's also that folks who've maybe traditionally been more on the application development side now can start to think of themselves as kernel developers, you know, they're able to actually enhance the capabilities of the kernel with these eBPF programs that they're developing. And, you know, I thought the last talk that we had, you know, Kyle went through a whole lot of the different libraries available to people, really kind of showed how it's accessible now with these libraries that are out there for people to develop these new kernel capabilities. We also see the kernel being able to iterate and innovate so that even before they make a commitment to do something multiple years to get it into all those downstreams, we see a way that they can run tests, they can run ideas and see if there is engagement or a need for that in talking in product terms if there's a customer and market fit for what they're trying to think about. So there's another group that we were, we believe are very important in this, and that's an infrastructure architect. These, from this perspective, eBPF provides a whole new set of tools and building blocks when you're creating clusters, specifically Kubernetes clusters, but also more generically. We've seen a lot of work around Kubernetes today, but an example of this would be getting your own CNI that is an eBPF CNI for Kubernetes and Sky talked about that when they said that they'd selected that and we're using that in their Kubernetes clusters. So there's lots of advantages for infrastructure architects. The core elements of the architecture become programmatic and programmable. So this is again infrastructure as code, but with a new lens on it as well. And it allows us with that ability to program it, to evolve it over time, watch what happens, make test cases and go ahead and deploy and make changes so that they are, can be introspected over time, as well as can be engaged with more as you're making test cases. Of course, one of the other super important pieces, there's tons of flexibility, but there's also performance. And this is the thing that anyone who talks about over observability has concerns about. You have to be very efficient when you're instrumenting something. We saw a talk today about running instrumentation in prod, like go look at what's happening in prod. How many people have been in tech long enough to never do that? That's me. I have been in tech long enough to never run tracing in prod, but now there's a way apparently. And we also heard from Dave Thaler, where EBPF is becoming an enabler for the common architecture across multiple platforms. And it is becoming the common architecture across platforms. We heard also about core and how that is again, there's a long lead time to get these things in, but there are ways that we're getting there. And that all of this work is really being broadened. So it's not just a Linux technology. It's coming to Windows. It's coming to other operating systems. And an infrastructure architect will no longer need to worry if EBPF programs would need to be created for multiple architectures. We're seeing that go to a single architecture. So architecture infrastructure architects, very important. And then we get to my absolute favorite topic of the world. And that's all of you, which is the community of EBPF. So thank you for participating. Thank you for being here. Thank you for asking questions and listening and learning. And thank you for taking what you've learned here today out into the world and inviting and engaging and welcoming others into this community. Because that is the most important part of open source, in my opinion. Starting with a community, starting with a small group of experts and insiders creating something really neat, really compelling. And then that group gets bigger. And then that group gets bigger beyond that. And then we start seeing the industry take notice. We've had the formation of the EBPF foundation in the last six months. And we've had the EBPF summits. And now we have an EBPF, a cloud native EBPF day. Let me be clear. All of this is promoting adoption. All of this is promoting growth. All of this is teaching people about what we think is so cool. So we're here to work with you all to become advocates for EBPF, to talk about it, to be excited about it, and to share that excitement so that we can continue to grow in this way. Because as a tech, it's pretty impressive. One other thing, all the projects we talked about today are open source. Please feel free to jump in. Please feel free to contribute. And let me be clear, contributing is not just by code. You can contribute by running your own EBPF summits. You could contribute by trying to help someone think through an architectural problem. You could contribute by pointing a newbie in the Slack channel, which is, of course, slack.ebpf.io to get registered. You could point a newbie in the Slack channel to some documentation and answer a super simple question. You could ask a super difficult question. All of these things are contributing to the community. All of these things are growing the group that is involved with EBPF. Expanding the ways that the idea of EBPF as a platform can be used and engaged with. We really hope you all will join us. You've taken a great first step. I completely echo everything that Sarah said. One thing I would bring it back to is what we started this particular presentation with, which is perspective, right? When you're involved in the open source project, when you see somebody ask a question that you know the answer to, you're bringing your perspective to the problem and that in itself is a huge contribution, right? It's not about whether you can, you know, whether you know the answer to some complicated BPF loop that is messing somebody up. It's about whether you can bring a fresh perspective, a fresh set of eyes, whether you can listen to the question and hear something in the question that nobody else heard, right? That is a huge contribution to any open source project. And being welcoming in that, because the conversations that hurt a community most are the ones that shut down something for being too basic or shut down something for, you know, we argued about that six months ago, never mind. But going ahead and being welcoming, being engaging and trying to share your excitement about EBPF, because all of you got out of your houses, most of you probably wrote a plane to get here. And then all of you are sitting here for whatever it's been nine hours now in a face mask. And that's, that's got to be some excitement driving you. So thank you. Thank you. Thank you for joining us today for the first cloud native EBPF con EBPF summit day cloud native EBPF day. Thank you. Cloud native EBPF day. Either of you have more to say. I would like to just add one thanks to what you said, which is, you know, I think this this would not have happened without a lot of work by a lot of people. Many of him are in this room. But one in particular, I think he's still in this room. Dan pop. Oh, okay. So he's not, he's not here. So that's all right. We can, we can talk behind his back. But even behind his back, I would say, you know, this, this day was, you know, very much down to him. He, he produced the initial momentum that got it off the ground. And, you know, a lot of folks from Lexi help Lindsey at the CNCF. You know, it was, it was really a big group effort. And, you know, thank you for coming and you know, sharing that with us today. Thank you all to all of the speakers. Enjoy your week.