We've had previous conversations with Liz Rice in the DevOps Sauna podcast before and hosted her eBPF talk at The DEVOPS Conference Global 2023. Many people don't know much about the work that Isovalent is doing and eBPF in general, although they are huge worldwide. Bill Mulligan, Community Pollinator from Isovalent, is here to tell a few stories about their work and impact.

Bill (00:05): People are going to want things with eBPF inside, not because they know exactly what eBPF is, but because of what it unlocks and enables them to do.

Marc (00:19): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I've bet the depths remain classified. And Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom. Enjoy your time in the DevOps Sauna.

Marc (00:45): Hello, we are back in the sauna. I am super excited and a bit humbled to have the opportunity to have a conversation with Bill Mulligan the Community Pollinator from Isovalent. Hi, Bill, how are you? 

Bill (01:01): Good. How are you? 

Marc (01:02): It's really fantastic. And it's been nice we had a little bit of pregame warmup to speak and you just drew me in with every single thing that you had to say. I have my usual cohort here Andy Allred. 

Andy (01:13): Hello-hello. 

Marc (01:14): When we were talking before and I've been on a few conferences on the circuit with Liz Rice. We we had her here on the DevOps Sauna podcast before, and we're still educating. It seems like a lot of people don't know that much about the work that Isovalent is doing and eBPF in general although you are hugely across the world. Could you tell a little bit of stories, Bill, about the work and the impact that you guys are doing?

Bill (01:43): Sure. Isovalent is founded around eBPF. And the founders made the bet a long time ago that eBPF would be the future of how we do things within the Linux kernel and in the cloud native world. And so, I think fast forward to today, like about seven years later, we've really seen that long-term bet really starting to come true. And Isovalent focuses around the Cilium project, which is a host of different projects covering things in the cloud native world like networking, observability, and security. And the way that we're doing things a bit differently is doing those with eBPF from the ground up. And that unlocks a really new way of doing things and is what really excites me about being at Isovalent.

Marc (02:29): Excellent. I think just to give a sense of the scale, there was a couple of data points that I believe that you had a couple of stories about how eBPF is used today.

Bill (02:41): Yeah, eBPF is, I guess, really transformational technology because it allows us to unlock innovation in the Linux kernel, which is getting to be over 30 years old now. There's a lot of code in there. It's deployed across millions, billions of devices. And actually, changing something in the Linux kernel is starting to be quite difficult. And so, because it needs to work across all these different places, you can't introduce breaking changes. And so eBPF allows us to add programmability and flexibility into the Linux kernel. And we're seeing a lot of really interesting real-world use cases that are impacting how people are doing things in production today, I think two of my favorite ones that almost everyone can relate to are around the stuff that Google and that Meta or Facebook are doing. On the Google side, main developer of Android and every single Android device in the world. And actually, my phone too because it's a Google Pixel uses eBPF. And so, you can think of the deployment scale of that. And what can use eBPF, right? Phones are quite different than datacenter servers or other applications of Linux kernel, but they want to be able to pull different metrics and data on how the phone is using the actual network. And with eBPF, they're able to add that functionality without needing to upstream it to the Linux kernel, right? They can get information that they need for a specific device without having to wait years for the kernel development cycle. And that's quite interesting. And then on the other side, on the Meta or Facebook side, they've actually been using eBPF to process every single packet coming into one of their data centers since 2017. And so once again, the scale, the bandwidth, and the performance improvements that they're giving them is pretty awesome. I know I use Facebook Messenger and WhatsApp all the time to communicate with my family. And it's interesting to see the foundational technology behind that is actually something that I'm working on in my day job too.

Marc (04:42): So every single cat video posted on Facebook goes through eBPF? 

Bill (04:49): Exactly. 

Marc (04:50): Really, really cool. It's inexplicable when like we have a conference and we do a poll and we ask the developers in the audience, do you know about eBPF? And most of them they say no today.

Bill (05:06): Yeah, I think eBPF is an interesting technology. And actually, the way that I look at it is in some ways, it's actually not a bad thing. I remember growing up, maybe you do too, the whole Intel Inside thing. I can still remember the little jingle behind it. And everybody wanted like yeah, I want Intel inside, like this is this is great. Besides people actually working on the hardware understand what Intel Inside actually meant? And I think we're going to be in actually quite a similar place with eBPF. People are going to want things with eBPF inside, not because they know exactly what eBPF is, but because of what it unlocks and enables them to do. It allows them to have things like faster networking, better observability, more secure systems, and those are the things that developers are actually going to care about. And it's going to impact the work that they're doing. The actual implementation details of eBPF under the cover isn't so important. And so, I think what we're actually going to move towards a world is everybody's going to be using and leveraging eBPF. But not everybody else. Everybody needs to know or develop or actually write the code for it. I think that's quite powerful and quite cool. People don't need to be writing C code, but they can leverage higher level tools like Cilium, like tetragon, do you have better networking, better observability, better security? And that's, I think, quite a powerful concept.

Marc (06:39): Quite wonderful. We realized on the observability track; I think it was one of the last conferences when we were talking in the halls. That is it that EBPF defies quantum physics because it gives you observability without actually changing the result?

Bill (06:56): Haha, so we need to be running towards eBPF.

Marc (06:59): Interesting. All right, Andy,

Andy (07:01): I was just thinking about this Schrodinger as eBPF. And there was an example that I brought up a while ago, we had a bit of telco code. And it was basically processing connections between two telco components and whatnot. And we had this weird bug. And when we turned the debugging on, the bug didn't manifest itself. And when we turned the debugging off, we had the bug all the time. And eventually, we figured out it was a bit of a timing issue. I love, generally, how eBPF programs work is they're not really changing what's happening inside the kernel. They're just being notified when something else is trying to make a process and acting on it, usually in a notify or deny but notification. This debugging stuff, it's like instead of having to change your code and change the timing, you just say when my code triggers this kernel process, I want to know about it. It really just changes the way we could do observability, which is just awesome. kilometry

Bill (08:11): Yeah, I was actually having a similar conversation at KubeCon. I was also talking with a telecommunications vendor. And I was talking with some people on their 5G observability team. And their problem is they're deploying out to thousands of locations, they want to be able to have observability into those systems, how they're working, how they're running, this is really important to understand the performance of network to make sure we actually have this call right now. And the problem that they were running into is they needed a consistent way to do that. They didn't have 50 different systems, and it creates this operational nightmare. But then say they want to go for an industry-standard way of doing it, something like open telemetry. Well, then they have to go to each of their vendors and convince them to add open telemetry into their actual code base that they can draw that out. And so, when you're trying to convince all of your different vendors to add something to their code, and support it and do things over the long run, like that's a really difficult conversation and can take a really long time. But eBPF since it's already part of the Linux kernel, it doesn't actually require any code changes. It gives you that instant observability and now they don't need to go back to their vendors. They can automatically just have that observability. And yes, it's quite cool for them.

Andy (09:25): Yeah, I spent a couple of decades working in telecoms and then I moved over to more traditional IT consulting and whatnot then. And when I talk with telecom people, my old colleagues and my old mindset is telecom is so special because we have all these special things. And now I'm realizing that it's really not that different. The biggest difference is there is such a mixed match of different technologies at different levels of maturity, and we have to be able to integrate with all of them all at the same time. Then something is you just described that instead of going to every single vendor and every single hardware type we have, and saying, we need to make this change, say, just keep running the way you're running. And we're going to notice when the kernel calls go through and trigger on that, then it just makes so much better user story for us to install that observability and set up observability tools, without really having to change what's actually doing the kernel calls, just watching the kernel calls.

Bill (10:30): Yeah, I think you nailed it exactly. Especially in the industry like telecommunications, where they're going from the copper wire all the way up to Kubernetes. And maybe even Wasum. How do you create a consistent experience across all of that? And you can't unless you're using something that's available everywhere like the Linux kernel, like eBPF.

Marc (10:48): I think this is an interesting segue into platforms. One of the things that we've known for years and if you look at like Simon Wardley's work, all the telcos are basically just becoming more commodity and more commodity all the time. And 5G was one little bump in the cycle that everybody thinks if they're going to get there faster, that if all the standards and all of the tools were open, if the platforms were more open, then they would be able to leverage one another and get there faster. And then still have to do something else to differentiate, but this platform revolution is something that's quite interesting going on. What are your takes on how you see the platform revolution coming up?

Bill (11:29): Yeah. I think platform is a funny word. It's new and it isn't new. We've seen this whole evolution from sysadmin, to DevOps, to SRE, to platform. It isn't new. But I think platform is trying to capture is what you're creating is this foundational layer that other teams are able to leverage. You want to create these easy paths for developer and give them the right building blocks to build on top of. And I think if we're thinking about how platforms have evolved. What it says to me is that there's been things before platforms, and there'll be things afterwards. Technology keeps on changing and evolving. But what I think we should take away from this, I guess, platform era, is what are the foundational technologies that will enable you to do your job today, and also for the future, for tomorrow, and whatever is going to be coming after platform. And so, when you're thinking about how you should build your platform, I think people should be looking at what is our use cases today, but how may they evolve in the future. And that will help them inform their tooling decisions or what they want to focus on. And I think that's why a lot of people I see right now are actually moving to Cilium, and fall in love with it. And I've done a lot of case studies and user stories. And I think the thing that always sticks out to me is people say I adopted Cilium because I did networking layer for my platform or for my Kubernetes clusters or whatever they're going to call it. And then once I had it installed, I realized that there's these great additional features that solve my problems. And my use cases as my scale, my complexity, my compliance requirements changed. And I think if you're able to have a technology that moves with the pace of your business, that allows you from getting stuck in this treadmill of our requirements have changed. Now we need a new tool to cover that instead of adding new things and figure out all the integration, it's just turning on this new feature. And so, people start with networking, then they want to do something like observability, well, there's just helpful for that. They start with one Kubernetes clusters, and now they have two. Now you can mash those together with cluster mesh. And so, when you're building out your platform, I would think about what technologies are setting you up for the future to because technology is going to keep on changing. We're still going to have jobs because of that. I guess, Eficode is going to help companies continue to transform it. I think you're probably pretty safe. And I think that's what's cool is when you can help companies choose technologies that are going to set them up for now in the future. 

Marc (14:07): It's interesting you use words platform revolution. Actually, when we talked before the podcast, and then we've talked a lot about platform engineering. It's one of the trends that we've talked about all year. Is there a connection between Cilium and developer platforms? Or the kind of platform engineering as we look at it and the DevOps space is creating those enablers? Do you see it as like an important part of an internal developer platform?

Bill (14:37): Yeah. This is actually quite a funny thing for me because I think there's actually multiple layers of the platform. A lot of people talk about platforms. I was actually thinking of the Developer Focus aspect. Things like backstage, what's your internal developer platform, IDP? But there's another part of it too. There's the actual what is it made up of? What are the foundational building blocks for that? It's great when the developers can be like, here's my coding environment, here's how we integrate with the rest of the applications. But there's these building blocks that need to be in place for the developers to be able to do that. I think when you're thinking about networking, and observability, or security, these are the foundational building blocks. And that's where Cilium comes into play. I think Cilium in a lot of way is technology like eBPF. It's at its best when it's completely transparent to the user. And so, when developers don't know about Cilium, in some ways, I don't think that's a bad thing. It's a technology that keeps on working. It's the same thing if I go to the faucet right now and I turn it on. I'm not surprised when water comes out. I'm surprised when water doesn't come out. Or the same thing when I flip on the light switch. We're surprised when things don't work. And I want Cilium to become such a ubiquitous and transparent technology that people are surprised when it doesn't work because they just assume that I'll be there and it'll work. And I think that's what platforms set you up for is having a consistent experience that allows you to do your job without having to think about all these implementation details.

Marc (16:14): It's funny because then I keep thinking open source versus enterprise partners. One thing that I'm curious is, are their companies building sophisticated observability tools or something? I know there's some things with eBPF, but based upon Cilium or are there some partners that you work closely with maybe or open-source projects? Can you can you tell me a little bit about the ecosystem, I think is the word I'm looking for.

Bill (16:53): Yeah. In terms of partners, obviously, we work with you. All of you at Eficode, I'm super excited to have you and also to be on the podcast right now. I know it's been a great partnership so far. But in terms of the ecosystem around eBPF and Cilium. I write a weekly newsletter covering everything in both the Cilium and eBPF ecosystems. And it's cool for me to keep track. And I think what I'm really starting to see is more people leveraging for both of the projects for unique or interesting use cases that I hadn't thought of before. This is the power of open sources, you can learn and leverage things from other projects and see what other people are doing and build upon the work of others not standing on the shoulders of giants, some people like to say in the industry. The original use cases were things like networking, observability, security, now we're seeing things around tracing, we're also seeing crazy new use cases. I know there's stuff about rebuilding the Linux kernel scheduler with eBPF. There's also stuff around doing things with human interaction devices like infrared sensors and stuff. And eBPF is an enabler for an ecosystem because it allows people to transform the Linux kernel to their specific use cases. And I think that's why we're seeing the explosion around eBPF right now. And then on the Cilium side, I think we're seeing a very similar thing where it's like this foundational layer, and then people are building platforms on top of it. And you see this in all the major cloud providers now have chosen Cilium as the default like networking solution for their managed Kubernetes service. It's this transparent thing that is available everywhere. And I think the interesting thing I'm seeing from this is people are actually demanding the pieces that they expect there like Hubble for observability. And they expect that to be part of the experience of having Cilium. I think that's really cool when the users know what experience they should have, and are demanding it from the people that are providing it to them.

Andy (19:10): And then we have people like Grafana, who's the de-facto monitoring dashboard stuff, saying, well, this is important enough, we're going to have some ready-made templates for monitoring the Cilium stuff kind of built him that you don't have to build yourself, just here. Take these and use them. It's like not just that people are using it, but other open-source projects are saying, hey, we need to have stuff available to integrate with this out of the box. 

Bill (19:37): Yeah, absolutely. 

Marc (19:38): Cool. Hi, it's Marc again, if you'd like to hear more about Cilium and eBPF. Not only did we have Liz Rice on the DevOps Sauna podcast, but we also featured her at The DEVOPS Conference 2023. I'll leave a link for you in the show notes. Now, back to the show. Could you tell me a bit about the community?

Bill (20:06): Which part of the community?

Marc (20:08): Good answer. That reminds me of a story. Neils [inaudible] from Finland is one of our EU representatives. And so, he comes to companies and he gives talks and he meets with people all the time. And one of his stories is when people ask me about how's your son, and he says, which one, sir? But tell me a little bit about the size of the community. I'm always interested in the ratio between contributors, or direct contributors versus users or discussers or the greater community. And then how do you work with your community? How do you grow it and take care of it?

Bill (20:55): Yeah. I think community is a very nebulous thing. And it's a lot of times hard to pin down and define. That's actually why I like to call myself a community pollinator rather than a community manager because I don't think you can actually manage your community. In this open-source world where people are just volunteering their time out of what they're interested in doing, you can't tell people what to do. You need to lead through influence rather than management. I think this is quite an important distinction for communities. And then in terms of the communities around like eBPF, and Cilium, I think it's interesting to see the growth of the eBPF in the kernel. First, it was Daniel and Alexei, as the maintainers of it. Now, they brought on new maintainers. I've seen some graphs of the explosion in the mailing lists, and like the number of patches that are coming in. And so, you're seeing these growth needs metrics around it. And with communities, it's, I guess, you can put metrics on different things. But I think what I like to track more is maybe not is like harder to pin down is the sentiment that's coming out of the community. As a way to understand the communities around Cilium and eBPF, I actually track all the social media mentions of both of the projects every single day and this gives me a sentiment about like, are people viewing it negatively or positively. I think this is the type of data to, and being able to understand that. And really diving into this helps you understand what's happening in the community. One of my more fun facts about my history is actually did my master's in social science of the Internet. And what I learned there is this technology, if we'd like to joke, it was internet 101. And looking at how society and technology interact with one another. And one of the things that we like to do there was like these mixed methods approach the quantitative and the qualitative. I think if you're really trying to understand how people in technology interact, you really need to do both of them. And I think what's super cool for me, of working with the eBPF, and the Cilium communities is just the positive sentiment and momentum behind both of the communities. It's really impressive to see all the positive things and all the excitement that people have for it. I've worked in a couple different communities. And I also do it like outside technology in my free time too. And the positive sentiment around both these communities really blows me away every day. 

Marc (23:42): I'd love to hear that. I grew up in the early days of the Internet and when things were not exactly so friendly and we always tend to focus on how vitriolic sometimes forums and other places on the Internet can be. To hear that your community and to see it is so healthy and friendly and positive is really fantastic. But on the pollinator thing I actually found the quote. There's a book called The Prophet and Khalil Gibran and I just wanted to share with you two lines from the chapter called on pleasure. And it says, for to the bee, a flower is a fountain of life and to the flower, a bee is a messenger of love. It's an interesting thing for you as a pollinator that you're bringing the connection between others and this community that you've created it's a fountain of life. It's a fountain of good and positive things. I absolutely adore your title. What do you see coming now? One of the things that we've we talked about a little bit is in the platform space and change is the only thing that is given or a constant. What do you see up and coming? What do you see changing over the next few months or a few years?

Bill (25:03): Yeah. I'd actually echo back to the conversation we were having earlier about the telco space. What's old is new and what's new is old. And also, once you put something into production, it never goes away, for better or for worse. And so, I think we're let's say it's maybe eight years right now into this cloud native revolution. And I think like a key point where we're looking both backwards and forwards. How native and Kubernetes are deployed at massive scales. But these things aren't done in isolation. We need to integrate with legacy systems, and people are looking at what's the new hot thing, like what's coming after cloud native? And so, I think this is an interesting point to understand how like cloud native and Kubernetes fit into the rest of the overall technology landscape. Going back to, I don't know, things written in COBOL, Fortran, two things now being implemented in Wasum. There's a lot of different technologies and infrastructure that we need to integrate with. And one of the things that's exciting me about Cilium is it's continuing to innovate this state in this place. It's not a project that's just standing still, and provides one piece of the platform, but is thinking about the what's coming next. And I think this is why a lot of people stay excited about Cilium is it's always pushing the edge of what's like needed and what's on the horizon. And so, the thing that I'm most excited about right now is the recently launched Cilium mesh. And what this allows you to do is to integrate the rest of your infrastructure into this Cilium network. You can add anything else as essentially like a network device in the cilium managed infrastructure, or the cilium managed platform. This is going back to say you want to integrate VMs or other types of systems and want to have them seamlessly mashed into the Cilium network. You can now do that with Cilium mesh. I think the terminology might need some work because you're throwing around all these meshes. But what it allows you, or what it actually enables for businesses is to have a consistent networking observability and security experience everywhere that they need to go, whether that's going back to legacy systems, or going forwards to whatever is coming after cloud native into Wasum or whatever the new hot technology is, and creating consistent experience wherever you need to go. That's what we were talking about before. The real operational overhead is when you have an inconsistent experience, when you need to keep on context switching. We always talk about what's the single pane of glass that you can have. And this is the Nirvana that nobody ever reaches. But I think with Cilium mesh and the other things that the project is giving, we can actually come a little bit closer to that where all of your infrastructure is within one consistent layer in terms of networking, observability, and security. I think that's quite exciting.

Andy (28:02): I've been using Cilium for a few years already. And I really loved how easy it is to just write a little network policy and say, these things can talk with these things. And it works fantastic. And you get observability out of the box and everything powered with eBPF. There's very little overhead. And it's fantastic as long as you're running inside of Kubernetes. And now just that things are becoming more and more moving outside of Kubernetes. But we still get these very easy to define consistent behavior, consistent expectation, single tool to manage multiple things inside and outside of a Kubernetes cluster just makes it so powerful that these wonderful, fantastic ideas and interesting and cool new tools, we can start to use also on already existing legacy or whatever we want to call it infrastructure and devices. We really build up this experience for everybody, and not just the new things, but still have the capability to be ready for the new things when they come. I think it's really exciting.

Bill (29:09): Yeah, absolutely.

Marc (29:10): Cool. Help me out here. Andy, when we worked on a previous development platform project, did we use this to get connection all the way to the developer desktop?

Andy (29:21): This had not been announced yet when we were doing that.

Marc (29:26): But is that a use case? 

Andy (29:28): Absolutely. Yes. 

Marc (29:30): Right. Can you open that up a little bit for us?

Andy (29:32): Well, one of the things we struggle with on that project was we were deploying things in Kubernetes. And it was fantastic. And even working with some of the other cloud services and whatnot or cloud-based services. We were able to still use Cilium as a central networking policy engine to define what services are able to talk with what services and we extended this Cilium or the service mesh a little bit outside the cluster already. We had this possibility to define how all the services deployed, were talking with each other. And it worked really, really well. The one place where this fell down and was troubling or a bit of a difficult spot was when the developers were developing something inside their own laptop, and how do they get connection to stuff. Of course, when you're deploying something new and trying to make a new platform, having the developers on your side and using your stuff from day one is key. And we didn't have an answer for that. It was a bit of a struggle. And I don't think there was anything announced officially in the Cilium mesh announcement about actually deploying stuff on a developer's laptop. But the idea of how we have these different types of connectors, which you can deploy anywhere, I don't think it's going to be long before there's an out of the box solution to when you're developing something locally, use this and this, which is already built into your template, and you can automatically be connected with the mesh and use that back-end service, which is secured with Cilium. Instead of setting up some well, you need to have this SSH tunnel and make sure you have this version installed on your laptop. And if you're using Windows go over there. It can just be part of the package and part of the same policy engine that everything else is running on. And I think this could be really exciting in the very near future. All the pieces, I think are basically there, it's just a matter of a little bit of maturity around them. And then looking at it from this angle and saying, okay, we take this piece, this piece, put it together, and it could be really cool. 

Marc (31:44): I absolutely love it when you do that any. We used to talk about these things where when you're a user of a system, you oftentimes know a lot of interesting things about it that the creators of the system hadn't ever thought of. Bill a few more things, we have to talk about AI, it's the mega trend that's going on at the moment. What do you see in the AI space or creating environment for the AI space now?

Bill (32:14): Yeah, so AI, people talked about, like AI Ops, like self-driving clusters, those types of things. What some people don't think about is it's not just some magical system that just knows everything from its creation. AI models are created based on data. And that data has to come from somewhere. And what I think makes eBPF interesting in the AI space is the amount of data and the types of data it can collect. It's seeing everything that's going on within the Linux kernel within your whole infrastructure. And it can collect all that information and like store and export it for you. And so once you have this data about the present state of your infrastructure and the anomalies, malicious activity, and you can create a historical log of that, you can start to do some interesting things in terms of training models, and starting to move towards AI in your operations or understanding of your clusters. And a part of that that Isovalent is working on is timescale which is able to collect and aggregate this data across Cilium across Hubble across tetragon. And correlate all that data together. Matching different security events with different things that are going on in the network. And once you are able to have that historical view of everything that's happening, you can do quite some interesting things with AI going forward. I think a lot of people, a lot of customers are going to be looking towards that capabilities with an eye on AI for the future.

Andy (33:49): I was looking at a tool just the other day that was built on eBPF. And basically, it was doing like this application profiling, heat map style of diagram showing all the SIS calls made by the different processes and when they're happening, and mapping out when your application is used, here's what's actually happening. And here's when it's getting busy. And here's when it's getting slow. And just showing you all of that information based on nothing, but what the eBPF is kind of seeing happen inside the kernel and throwing events on it. And then just taking that idea and thinking okay, what if we have millions or billions of those feeding into an AI model? What kind of predictions can we make and what kind of observations we can make based on that data?

Bill (34:36): Yeah, was that Parkar or Periscope? 

Andy (34:39): It was Pixie, actually. 

Bill (34:40): Pixie. Okay.

Marc (34:42): Parker, Potter, Schofer, Pixie.

Andy (34:46): It starts with the P, though.

Bill (34:46): Yeah, close.

Marc (34:50): Cool. All right. We've got a couple of extra questions that we like to ask everyone that comes on the podcast, Bill. And the first one is when's the last time you tried something new? And what was it?

Bill (35:06): I'd say even last night. I got invited to this venture capital dinner. I've never been a founder, I've a bunch of friends that are founders. And suddenly, I was thrown into this very different space where people are talking about fundraising rounds, and different companies that they founded and the problem that founders have in businesses. That was something that was quite new and interesting for me. I got invited and I said yes because I think it's always important to expand your horizons and try something new.

Marc (35:37): Excellent. 

Andy (35:39): And what's the last thing that really excited you?

Bill (35:45): I'm a very outdoorsy person. I'd say two things. They're both related to sports and the outdoors. One, I've recently went to Tuscany to go biking, and I got to ride the route of this famous cycling race called strata panache, which is like the white road in Tuscany. I was super excited because I think one of the cool things about cycling is that you actually get to ride the same routes like the professionals are doing. It's not like there's some stadium somewhere that you'll never even touch the grass. It's like they're out on the actual roads and to be able to have ride some of those gravel roads and know that people were racing across these and understand how it was. And I think that's that that's super cool. And the route was just spectacular. It almost seemed like it was a cliche, you're riding on this gravel road with poplar trees. And there's a villa on the hillside. And you see on off in the distance with it's like towers and stuff. I was just waiting for someone to pride stress and ride through on the horse. It's awesome.

Marc (36:50): Fantastic.

Andy (36:51): I can totally picture that. That's great.

Marc (36:53): Bill, it's been wonderful to have you I really appreciate your energy. And I love how you look at things. And almost every question that I asked, no matter how smart or dumb my question, your answer would begin with, yeah, and continue from there. Really, really cool. The takeaway that you told me as we went along, and as with increasing scale and complexity and compliance issues, with Cilium, you can get faster networking, more observability and more security and a whole bunch of other things that are coming. I think that's really fantastic. It's been a pleasure to have you on the DevOps Sauna podcast today.

Bill (37:32): Thank you for having me. It's been great to be here.

Andy (37:35): Thanks a lot. It's been really, really fun. I'm really glad we got to do this.

Marc (37:40): Fantastic. All right. Thank you. We'll see you next time. Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

Bill (37:54): Hi, I'm Bill Mulligan. I'm a community pollinator at Isovalent. And my job and my goal is to help make the Cilium and eBPF communities grow flourished and really come into full blossom.

Marc (38:07): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (38:13): My name is Andy Allred and I'm doing platform engineering at Eficode.

Marc (38:17): Thank you for listening. If you enjoyed what you heard, please like and subscribe it means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.