 Hello, everybody, and good insert appropriate time zone response. For me, it's good morning. Welcome to the Kubernetes by example insider show, where we talk to people who are involved in Kubernetes kind of on the ground. What we find is with open source projects, sometimes talking to the management teams around the project is not always sufficient to figure out where the project is going, because the beauty of open source is that, you know, if an engineer decides they really want to see a feature in, they can put it in nights and weekends, you know, assuming it gets accepted. And so we try to get insights into what is planned for kind of coming up in whatever component, but also what the individuals that we talked to would really like to see happen. And so that you can have a better understanding of what's going on. Today, we're going to be talking about Kubernetes and IoT. And if you're unfamiliar with IoT, it is Internet of Things, which is kind of a shorthand for all those devices that often do like a single task that are kind of independent, you know, so, but do various useful things like thermostats and lighting sensors and things like that. In fact, the new building that I'm in that I'm sitting here, we have something like 300 scales for all the trash cans. And they measure all the trash that goes out of the building and it all ends up in a dashboard. And so those are all IoT devices. So obviously that is a orchestration issue to put it nicely. So today I'd like to welcome, oh, and I don't know if I said my name. Did I say my name? I'm Langdon White, but I would like to also thank my co-host for joining me. Savita, do you want to introduce yourself? Sure. Hi. Hi, everyone. My name is Savita Raghunathan. I am a senior software engineer at Red Hat and I was a guest once and then I loved the show so much and then I got the opportunity to co-host alongside Langdon. So here I am. I am excited to talk all things IoT today with Deon. Would you like to introduce yourself? Yes. So my name is Deon. I'm a software engineer at Red Hat. I've been in open source for 15 years in different roles and different projects that are involved for some time IoT as well and edge computing. And that's the topics I think we're going to cover today, right? Yeah, pretty much. One thing we do like to kind of open up with though is like, what brought you to open source? Like why did you get involved in open source in the first place or how? Yeah, yeah. So, yeah, I mean, previously open source I was working for a company building internal products like a lot of people but, you know, especially today and it was the true 15 years ago, you know, you depend on a lot of open source packages and projects out there and that's where all the innovation is coming from. So as you grow, as an engineer, you get more and more involved into things that you're using. And at some point, yeah, I got an offer to start doing that full time. So I started in the Apache Foundation community, a project called Apache Act MQ which is a message broker still in use today a lot. Yeah, I like messaging and event-driven architecture. So that was a really interesting thing to do. Then more and more people start trying to use, I think you for IoT use cases. So trying to use MQTT protocol, trying to connect devices to the broker. And we had more and more customers trying to do that. So I kind of went a little bit more into specializing into that because I like the IoT topic in general. So we worked on that for a while and then we joined Eclipse IoT Foundation, Eclipse Foundation IoT community. There was a lot of work going on there. I don't know how deep you want to go. No, that was pretty good. I mean, it's kind of, I think what pulled you in, right? It's basically like that's where the innovation was happening. Yeah, it's a natural progression because we figure out after a while that scaling message brokers for IoT use cases, trying to connect hundreds of thousands or millions of devices, it's a hard thing to do. So another approach was needed and we tried to dazzle into a topic of trying to figure out cloud connectivity for IoT use cases. So how can we build this infrastructure that can scale horizontally? And it was even before the Kubernetes days. So right-hand partner with Bosch, we were working a lot on a project called Eclipse HANA, trying to provide this connectivity layer for IoT. And more and more as Kubernetes became popular in the sense we, yeah, first of all, make Kubernetes first class cities and for our stuff, but got more involved with the Kubernetes community. And then there was the idea to start like a Kubernetes IoT working group, which from the beginning started to be like an IoT Edge working group, because once you start talking to people that they're trying to do things with Kubernetes outside of the pure data center, you can see that everybody has a lot of different use cases and that's a group like that was a good thing to discuss all these use cases and see how to apply different technologies for those different use cases. So I'll stop with the introduction for now. Yeah, one of the things that I'm, you know, what you made me think of is, so what is kind of unique about the kind of IoT world with regards to messaging? Like, you know, I think, you know, most people, you know, who've worked in enterprise industry systems, right? You know, have done something with message brokers at some point, right? Whether it's Apaches or one of the others. But so like it's just another message. Like why is IoT special? Different, yeah. Well, I think the best thing to say is that communication patterns are different. So for example, in a typical enterprise use case, you would have dozens, maybe hundreds of sites, bank retail offices and things like that if you want to connect, right? And those connections would be stable, fairly stable. And so you have like a couple dozen to a hundred streams with large number of messages coming in. Then you come to use case like, okay, how did I scale that to support hundreds of thousands of devices, which may be sleeping most of the time, wake up every five minutes, send one small message and go down, right? Or things like that. So you have a scale of connections, much different. So it doesn't mean that the scale of messages or volume of data is much different, but it's coming from a much wider array of sources. Right. Yeah, it's kind of more like it's more like the like almost like that fabric or like the makeup of the messaging that's going around, right? Like it's more maybe more sporadic, smaller messages and a very high volume from or a very high volume of sources as well as like potentially a high volume of messages. Which are constantly coming and going. Then there's there's a thing like a large number of different protocols which are already there and not going anywhere. So instead of using your own plan for library, you know, written in a one or two languages, you need to support MPTT cops, maybe something's coming over UDP. And so that wide array of different protocols that needs to be supported. Security is also quite different because these things are usually not in your network. So if you think about enterprise messaging, you know, you control your behavior, your environment, right? You know, you can trust things much more than than in a typical IoT to cloud device to clouds. So to say scenario. And then we have a different things. So, so, so we are they identified basically to to general patterns. So this is the first pattern saying telemetry is going from the sensors into the cloud for for further processing. Right. That's one stream. And then you have the other stream going cloud to devices, which are usually called commands. So sending commands to like a shout out, you know, shut this door or stop this AC, things like that. And also that has a completely different pattern of communication, which might not be the best thing to support with existing technologies. For example, one thing. So, going back to telemetry, like, doesn't usually fire and forget kind of messaging patterns. So if you miss a couple of readings of a sensor, it's not a big deal. You can, you know, you should be alerted after a while, but it's not like it doesn't need reliability really. It's not financial information that you don't, you know, you, you, you mustn't lose at any cost, right, which is, which is most traditional message broker are built around. So it's more like having a huge pipe pipe to get most of the data through that pipe, right. But on the other hand, commands going back are also kind of different because you're sending that comment and you don't know that there's a lot of point of failure that can happen in the system, even in the cloud, but even if the message reach to device, do we know if, if, if actually the door has been shut or not, you know, based on just sending the message, we can't say that, right. So, so using something like a traditional queue for that is, is again, not, not a good option. We don't know whether device will be available now or in a, you know, six days or something like that. So some kind of like creating, creating layers of communication on top of the messaging is needed. Anyways, some kind of digital twin that that feel that we are entering slowly into the Kubernetes land like like this operator pattern that that you are trying to reconcile the state of your device with something that you have in your system is becoming more natural pattern to do these things instead of just shoveling everything in a queue and praying that things will work out in the end. So you're, you're kind of, you know, eventually consistent config management, in a sense, for, for the, you know, for the door, which I think is, yeah, that's really interesting. Because you also the IoT is like, you know, distributed system to the max, right. So because you're actually, actually communicating with the external environment and physical world in a sense, right. Right, right. And how, like, what I also imagine, right, is that you also kind of end up with, with quite different patterns for lack of a better term, or different constructs that you might need depending on kind of the use case right so like a thermostat needs to have a different kind of relationship right to the rest of the environment either because, you know, kind of like in the thermostat case right pushing it up a degree or down a degree is, you know, probably not the end of the world. But if a door is supposed to be locked at 6pm, it better be locked right. And then kind of the other scenario I was thinking about is one of the things that I've, I've also seen a lot of kind of in the edge IoT space is also things like car automation. You know, so like the computers inside cars. And so I wonder how much does that impact the for lack of better term like the protocols or the tool chain or whatever, or is it really just or is that just a matter of like how you program that individual scenario. Yeah, so I think, yeah, in my mind, so one of the good things of IoT is that, you know, the use case has been known for like a 20 years. So it's nothing new. Right. So we're just trying to do it on a completely different scale. But all these things have been, you know, taught about by a lot of people or many phases of technology development. So, so, so the basic building box are, I think, well defined. So, so, you know, how you go, you know, to do, to do these kind of things are, are similar. So, so it's basically just, just implementing that kind of like on another level, how your application will deal with, I can, I sent three messages. So I tried to reconcile to close this door for six times. And I still didn't get a response back that that are they're actually closed. No, so that's alert for someone to take a look and go to see what was going on there. But there's nothing I think on the technology side that can be done at that point, right. Right, right. Yeah, I think, yeah, human in the loop on kind of a weird level, right. I have to tell us something that when Alan then talked about the cars and when you said about the security and all I could think of is that I just think the past and previous movie where they will control all the cars and they will like make them like that is this one. I forgot the part and they remotely control the cars. And that is my nightmare. That is my worst nightmare that I always like think of cars driving. I mean they already drive by themselves but someone remotely controlling that is the worst nightmare that I have. Like, when you are developing such protocols are like working with devices, do you like, get concerns like this, like someone says that, yeah, how do I trust this device, you know, yeah, my washing machine or my dishwasher is just going to do a tool thing and I have this little app and it's going to come to my mobile and say like status and whatnot but how do you and then I also have like a security system, but the security system could also use, I don't know if they'll use IOP or not or the IOP or not, I have to go back and check now that I think about it but. Yeah. So, so I think that's where we are entering the topic of edge computing and because not everything should be connected to the cloud and not immediately controllable by the cloud, so to say. So, so, so that's the next step. How do we, and that's the whole goal of edge computing in general. So how do we bring compute closer to the source of data and how we close these control loops in a more secure way and it's not just the security but security is one of the big use cases. The other use cases is like bandwidth, for example. So, talking about sensors is one thing but if you're trying to send a video feed up to the cloud and then process it there and then return results back and try to do that for for 1000s of cameras and things like that. Obviously, the solution will not scale and end up, you know, so so the edge computing is the idea that we bring another layer into this device to cloud connectivity so that we have some workloads running, running locally, geographically locally so locally in your car and some things that can be influenced by, by the, by anybody outside of that environment, right. That makes sense. Thank you. Yeah, well I was, I was actually going to kind of bring up is like, you know, there's, there's a relatively famous Twitter handle with a name I won't repeat but you know internet of we replace things with the bad word. Yeah, one of the things that we hear a lot about right is that a lot of devices do not have good security. Do you, you know, you're a lot closer to it than I am right I just go kind of by the rumor mill. You know, is that still true is it getting better. I mean I know it used to be really really bad but you know is it is it getting better you know can, can you still hack a thermostat very easily. It's getting better in a, in a, in a lot of ways. So, so I'm not that much into like a consumer IoT and automation. And for a reason, right, because I think, you know, for a lot of people it's just a gimmick for auto manufacturers is just a gimmick so everybody is doing, you know, poster that it's that it has a Wi-Fi so we'll do it as well right to be competitive but it's not really a necessary feature. But, but, but looking at it from the open source perspective, there's a lot of things going on that that's getting that that's getting better in terms of security for for for IoT so one thing is that I was involved for the last couple years so the rust programming language is is a is a big deal because it allows us to build even the firmer, you know, you know, with a with a memory safety kind of environment, and that should help a lot with with exploitability of of firmers and the small things in general. And I think, yeah, as times go goes by as like looking at the overall systems where more people are realizing that yeah, connecting everything to the cloud and then, you know, not being able to turn on the lights if you don't have Wi-Fi. Yeah, not not very much fun. Yeah, actually, I was, I had a fairly decent or like kind of long conversation with one of the people who like kind of manages our building. And, you know, it's a really new building right so there's a lot of that kind of stuff in place. And I didn't even really cross my mind. One thing that I thought was super interesting was like how much he knew about technology right because of having to deal with like that, like, because, you know, in my office alone, right, I mean, I have a thermostat, you know, and then I also have, you know, the lighting is also controlled right. And, but you know, I didn't even think about the fact that those are both PoE right their power or ethernet overpower or whatever it's called. And, you know, which reduces a huge attack vector right because they're not going over Wi-Fi right they are hard lined into the system. Yeah, I mean, on the flip side, you know, because that mean I can plug into the power and, you know, and, you know, and try to access it that way. But it is kind of a, I think it's a really interesting space and there's a lot of really interesting stuff going on there. So, so I think, yeah, the solution for that kind of particular problem is using technologies like Bluetooth, Matter and Thread, which are getting popular now. So these things that are basically local. So you need to provision them locally. It's all secured by the proper cryptography and you need to onboard them on your network. And then have some kind of the gateway to be able to, you know, get the basics of the whole system on your phone or over the cloud externally. But that should expose only a fraction of the whole functionality and not in any way make it critical for that system to function properly, right? Right, right. Yeah. All right. So as much as I like talking about the IoT devices themselves. So kind of what's going on with that kind of IoT working group with Kubernetes? Yeah. So, yeah, at some point, so it's IoT and Edge working group. And because, yeah, we started with this idea, I was coming from this world and to me, IoT and the cloud was a big thing. But as soon as we got people in the room, you could see that that's not the only use case. And that's not even the primary use case that people had for IoT and Edge, right? And then we spent a lot of time trying to decide and what is now three or four years later, like a common knowledge, like what are the different tiers of the Edge and different applications and different use cases. So that was one big question to just for starters, figure out, you know, when somebody comes to you and say, I'm interested in Edge computing, like, okay, you know, what do you mean? Like make a common vocabulary for everything, right? And today, we have that. So, if you go like from the cloud down, right? So you have first what you call like a service provider Edge. So that's the Edge that Telcos and other providers are interested in. So basically putting a smaller data centers on their point of presence kind of things, right? Then you get into the space of the user Edge. So the Edge of the customers that are having their own infrastructure and that can be quite different. So you again can have like a small data center to like a three node cluster to like a single node cluster. And, you know, I think that's where we're stopping with the Edge, right? Anything that's, you know, you can say like the device of the power of Raspberry Pi that can run Linux and containers and things like that. That's something we would, you know, consider Edge, right? That's something that can be integrated into the whole this Edge-to-Cloud spectrum in a similar way. But then you have, as we said, like a smaller devices with firmer and things like that. That's usually not considered Edge, part of the Edge, but the external devices connecting to our system. And so the working group is intended to define those things? Is that kind of the step you're kind of working on? Yes. So that was the first step. And then we tried through different, you know, papers and talks and demos. Try to figure out and show to other people where Kubernetes and other cloud-native foundation technologies fits in that picture. So, different use cases. One use case is, for example, what we talked in the first half of this session is like, how do we connect these devices? Because it's not, you know, traditional Kubernetes and cloud is HTTP. You know, we are using browsers to connect to everything. So now it's not. It's persistent MQTT connections or UDP connections. So how do we onboard this traffic there? Then how do we, you know, so how do we, there's a different kind of challenges. But to take one step back is, so what is Edge computing and how it is different from like a traditional on-premise computing, right? So why we are not talking about all this? Because, and I think that's significant saying that we want to people, developers have the same tooling and same experience they are having in developing cloud-native applications to be able to develop workloads that can extend to the Edge as well. So extending cloud infrastructure and the workloads basically with a similar tooling to the Edge. So that was one of the main goals. I must say that I think three or four months ago, so the Edge Working Group has moved from the Kubernetes community to the more broader CNCF community. So we are now under take runtime because in the last few years, we covered all these. So you have all these kind of projects that popped up in the Kubernetes land like QBedge, like K3S or MicroShift and OpenEurt. So people have figured out how to deploy Kubernetes on Edge and operate it there. But then I think the next step is to figure out all these other things as well, like in a more broader sense of how to do observability, how to do CICD and GitOps and automation and how to make things easier for people to do Edge computing. One of the things I immediately thought of when you were saying that is if you want to bring the experience of a normal cloud-native development to IoT or whatever, how much are you having to deal with the difference between traditional cloud applications and every other kind of application are not event-driven. And it is a pretty serious mind shift to think about your development in an event-driven architecture. I think I had a huge advantage actually being a Windows developer many, many years ago using COM, which is actually an event-driven architecture inside the operating system. But an event-driven approach to your application is quite different. I think you can even tell with something like Node.js, which was built as an event-driven architecture, and then immediately had a plug-in slapped on top of it to make it into a web server called Express. And never shall we see event-driven in Node again. But I guess that's kind of one of the big things I would wonder about it, or are you kind of skating away from that by saying all cloud-native is event-driven, or how do you deal with that in kind of the development style or talking to people that, you know, hey, you have to think about the architecture quite differently. Yeah, so that's one of the things. So we released a white paper a month or two ago. So since you have edge-native principles, where we try to, like for starters, again, just help people, you know, put things in focus. What's important for application to be successful in the native landscape. So it's not just event-driven. So when you start thinking about it, there's a lot of things. First is resource constraint. So, you know, a promise of cloud is, you know, unlimited scalability, right? Which is not the case if you have a three-node Kubernetes cluster. So you need to be aware of that. You need to be aware of your networking connection and the bandwidth. So it's not guaranteed that it will be there. That's where we're coming to these kind of things. Like you need to have a local cache and local feedback loop to be able to function while you're disconnected from the center cloud, right? And there's also heterogeneous hardware there. So it's not just a unit protein. So you need to think about this. If your application will run on ARM or X86 or both, right? And how are you going to approach that? Then the big difference is that you usually put your applications to the edge for a reason. And one of those reasons is to communicate with the external world, right? Which is rarely case in the cloud. With the exception of the GPUs, you really don't use any external hardware, right? But here you want to be able to access Bluetooth or USB cameras or whatever you're interested in to communicate with, right? And then you need to think about those aspects as well. So how your containerized image will access all those resources. And that leads to another issue that's like a workload placement. The typical cloud applications, it's mostly about horizontal scaling. So you just want to scale out when you need it, right? But for the edge application, you need to be much more deliberate about where you're placing your workloads. So is this service make sense if this device doesn't have a Bluetooth or is it not connected to a proper camera? So it's not about just scheduling microservices wherever we have a place, right? It needs to go to this exact location for this application to make sense. So, yeah, at this point, we try just to summarize all these things and make sure that people are in a good shape when they're starting to plan to develop things like this that they plan ahead. Yeah, I think I actually threw the white paper, I hope, in the chat. And yeah, I mean, I think that's hugely important because I think people don't realize how different, you know, kind of developing for event driven scenarios is to, you know, kind of traditional development, you know, I don't know what the opposite of event driven is. But Savita, I wanted to ask you, you know, what was, you know, did you have anything you wanted to ask about? Sure, so I was wondering, like you said a lot of you explained a lot of concept to us and it is half the things are new to me so that has been like so helpful. But what would be the one advice that you would give for a contributor who wants to get started with one of these tags and the working group or something other than bringing their passion, of course, you know, and sometimes that they need to unlearn to relearn, right? You have to unlearn certain things to like actually do something good. So is there any kind of advice that you have for a new contributor who wants to get started with IOT and H? Yeah, so let me think about it. Yeah, that's a very good question. I think, yeah, learning by doing is the best thing and failing along is a good thing too, right? So what I would do is, so there's a lot of people doing their own home labs, right? That's a good topic. So you have whole groups dedicated to that. So, you know, if you're interested in the infrastructure space, I think that's a good starting point. Trying to build a Kubernetes cluster out of three Raspberry Pis or Nuke kind of desktop computers at home and see how it goes. That's for the edge part. For the IOT part, there's a lot of things like there. So there's a lot of existing boards and projects. So it'd be best to take one that it's most convenient for you and just try to connect it to whatever infrastructure you want to be. It can be just a single HTTP server for starters. Then you can start thinking about, okay, you know, now this is working. How do I go to the next steps? How do I put that web server in a container and deploy it or on a K3S or microchips or whatever. And, you know, try slowly because it's a, on the one thing, it's a very good topic because it's so wide. But on the other thing, that's the difficulty because there's no single answer. It basically spans from the firmware to the cloud. And you get to decide what parts are you interested in and what other parts are you just going to pick from the community for the starters until you get interested into that too, right? Because eventually you will. Yeah, yeah, I agree with that. And that's been very helpful. The information that you provided, I do have like five or six Raspberry Pisces just sitting there. So I'm hoping that someday I'll just take it out. And I have been wanting to make my own mini Kubernetes cluster like a home map and I have articles pinned that I want to do. So like one day I'm going to give it a try. So thank you for bringing that up. It's a little bit of motivation that I needed. Yeah, I think I saw a speaker at a conference actually build one live on stage out of like five Raspberry Pisces, which I was very impressed with. Like there's like demo gods and then there's like demo gods with hardware. And you're like, oh my God, you're just asking for trouble, right? But yeah, totally. So I guess the other part of that question rate is like, how does somebody kind of get to, I don't want to say where you're at, but kind of like where, like how do you start to be a person who really is deeply embedded, especially in the IOT space, right? I think edge kind of as the topic sort of encompasses IOT sort of doesn't it's like a Venn diagram, but I think edge is getting a lot of press, right? And I think IOT, there's a lot behind the hype. Yeah, it's after the hype cycle, right? Yeah, well, that's I mean, and I think there's going to be a lot more, right? I mean, because, you know, every single thing is going to be able to do something with tech, right? And so how do we, you know, how do I get plugged into that space? So I build a little myself, but like how can I kind of go to the next step? Yeah, yeah, just, I think not just for IOT and this and I think we're getting back to the beginning of this discussion, like, why do you get involved into the open source? That's the correct answer, right? You're starting where you are. You figure out what you don't know and you want to know and you'll find the projects and people who are doing that. I never had an issue connecting with the people and all people in open source and the communities are usually more than welcome to, you know, get you on board and you just, yeah, find the next thing. Right, right. Yeah, missing piece. So, you know, a couple of things I would, yeah, I mentioned we played with Rust a lot. So if embedded and system programming is your thing, I think a lot of things is going on there for the future. Wazem is also one of like if you're going, if you're talking about the topics like where the hockey puck is going, right? And you want to get ahead of the curve. Wazem is also a very big topic for all these use cases. And, you know, I would advise people to start looking there. So can you elaborate actually on that specifically? Like, what's the correlation between Wazem and kind of IoT? Like, what's, you know, like, how do they affect each other in a sense? So I think it's, again, very early days still. Should we go a little bit about what Wazem is? Yeah, a little bit. We've actually covered it on the show a couple of times in the past already. But yeah, I think it's really interesting. You know, now I just need a lot of free time. Yeah, yeah. So I played just a little bit with it. So I wouldn't call myself any expert in that field, but like comparing Wazem binaries and containers, for example, there's a lot of potential benefits there. For example, we're again talking about constrained devices, constrained networks and bandwidths and things like that. And when you, like, consider a typical container of hundreds of megabytes of size and Wazem binary, which is a megabyte or two, and with a similar functionality, you can see how it can have certain benefits for bringing it up to the constrained computing, right? The other thing is the sandboxing and security, back to the original question about not messing with the cars. So I think there's a lot of work being done in the community. So originally Wazem was made for browsers and not meant to communicate with anything else. And that made it a good sandbox security environment that can't mess with anything outside of it. But for edge and IoT use cases, and use cases on the edge, as you said, we need to have permission to access our devices or access other things. And there's a thing called Vazi, where we have assembly system interface, which defines how the Wazem binary can communicate with the system resources in a very constrained, again, it's only can access something that you explicitly give it permission to access, right? So in that sense, but in that sense, that could be a much better proposition for those sensitive areas of accessing and running the workload on edge devices, so to say. Right. Yeah, that's cool. Savita, did you have any other questions you want to ask about? I was gonna, because we did want to save a little bit of time to talk about KubeCon EU. And, but I wanted to see, was there anything else that we should talk about, or Deandre, is there anything we didn't talk about that we should have asked you about? Yeah, I don't know. I talked a lot. Yeah, I think that's good. You are our guest of honor today, so. I don't have, I think I, this session has so far been like so useful, but so much information passed into it already. So I don't have anything, any other questions to ask, other than what we covered. Yeah, I can give you a segue for KubeCon stuff, because there will be a co-located event, a Kubernetes on edge day, which are working group is helping to, you know, a program manager for that. So if you're all interested in that topic, you should consider that as well. It's specifically, I think, this time, how they went just about edge computing with Kubernetes. Yeah. The one thing I wanted to also kind of bring up, because I actually recently kind of gave a talk on campus, right, about just kind of a very brief introduction to edge. And, you know, when I give a talk, I tend to do a little research first. And I went to do the research and I was just blown away by how much has changed in the last like four or five years. You know, so if you think you know what edge computing is at present, or IoT, right, or any of these related technologies, I would really recommend doing, doing some research and see how much has changed, because there is a lot more going on there than certainly I realize, you know. And I think so, so our working group has a biweekly meetings. I think it's Wednesday, 9am Pacific time. And it's a good place to hang out. So we try to source speakers from all these different products, open source that they're doing something related to it and edge in the, you know, C&CF area. But even if you don't have an agenda, it's a really, really good, good source for like a better conversations and, you know, exactly questions that you ask where do I start, you know, I'm interested in this to do anybody knows, you know, how to approach that it's a, it's a good community to get involved into the whole topic. Nice, maybe a link to our. I was just looking for one actually. Yeah. But yeah, so we'll, I'll try to find it and I'll put it up but I'm also going to put the co located event. So, I think Gordon, are you here. Are you able to join us. I am here. Hi, that was amazing stuff. Thank you for sharing all that. So, I definitely learned some things this morning. Although I'm like Savita, I think I am a little terrified of cars taking over and I think I remember Savita that show you're talking is it so there was a show on my laptop say Amazon prime. Yeah, of course. There's no one prime called upload. Do you remember that so I haven't seen that I started in the fast and furious movies. I like that franchise so like I started but I won't make it out and go and yeah, but that happened in upload and it was like the car took over and I'm like, oh my gosh, no, no, I don't know this IOT stuff this edge. There's a lot of joking saying that there's no much difference between the smart house and the haunted house. So that's the future. That's terrifying but thank you. Thank you for that. Well guys good to see you all. Wow. QCon is three weeks away. Can you believe it? Yeah, right. So I was just looking at my counter this morning going, it is three. So I'm trying to, I think we're all trying to get everything wrapped up before that. But first and foremost, so, Jason, you're not going to be there in person, right? I don't believe. Okay. Unfortunately, not this this time. Yeah. Yeah, that's well next time, hopefully, but then Langdon and Savita what I'm excited about is we actually get to meet in person. Yeah, for that. For all these endless virtual meetings with you guys, I get to see you face to face and maybe even share some fun while we're there. So that'll be tons of fun. But yeah, Langdon, I don't know where you want me to go. I can give you some updates. In terms of some exciting new KBE news, some fun things, some conveyor things which I know Savita as well tapped into as well. Where would you like me to start just kind of give a I was going to also mention the I don't know if anybody else has had this experience, but I have now discovered, you know, when you're on virtual calls with people all the time you can't remember if you've actually met them in person. And what I what I discovered is when I meet them in person, if I'm wildly wrong about how tall I thought they were. That means I have not met them before. And I only know that which I think is kind of hilarious. But yeah, so to get started. Let's maybe talk about the event itself and maybe some of the, because I know we're sponsoring at least one co located event. You know, and maybe that first. We've got several things going on. I can tell it's just some bare basics. Right. So was it April 18 through 21 in Amsterdam. So the RAI exhibition center there just outside of downtown. So we're looking forward to that red hat does have a heavy presence there KBE conveyor other upstream projects that were involved with will all be there. So that's what we're really excited about. But from a KBE stamp, let me start there from a KBE standpoint, I don't reveal everything, but I do want to reveal some fun things. So, so we've got a couple more than a couple of fun things going on. So first and foremost, if you guys are familiar with our KBE learning paths, and you might know that we've got 17 learning paths that we've created over two years almost two years time now. So a pretty broad realm of a pretty broad library. We're adding to new learning paths that I'll bring us up to 19 almost 20. But the two new learning paths are going to be kind of fun to convert. That's one of what we're going to announce that should be ready in three weeks time and up online. So, you know, you guys know orchestrating the ends on the same infrastructure that you would containers. So obviously picking up a lot of speed with with the community. So that is something that we've been asked by customers by by heck just people in the community itself. Hey, is that something you can add to KBE. So yes, we can and that will be there. So that's coming. Another learning path. No JS. So no JS. You guys know so what what's has the best way to describe no JS JavaScript runtime environment and execution and more right. So yeah. And we were joking about it earlier is that it actually supports event driven architectures and is just never used that way. There you go. So Dejan, we could have used your your help with with this, I'm sure. But maybe, you know, going forward, you can you can always add your your input to it. That's the fun thing about KBE is these learning paths are always evolving and updating and speaking of evolving and updating. So we've got several learning paths, some of which folks on the line here are involved with that are being updated kind of in a real time and you know in the weeks ahead as well. But everything from what Kubernetes security, I know we've placed a big emphasis on that on bringing some enhancements to that learning path. We've got Tecton. I think you've been involved with the Tecton learning path. So we're furthering that and adding some enhancements and even migrating to Kubernetes and Savita. I know you've been involved in that. Yeah, so lots of lots of fun work going on. So some good stuff going on with our learning paths. We're always trying to obviously update those and create new ones where where the community needs them. And that's what we're doing with with KBE. So that's going on. I would say at the event itself, that's probably the more fun stuff. So yeah, so a couple of things. So KBE, well, OpenShift Commons. So on the day zero, we'll have a big OpenShift Commons that several of us will be involved with. Our friend and colleague Karina Angel is responsible for that. But we're involved as well at KBE is sponsoring the reception. So we'll have some fun, you know, after, after events, socialization and food and wine and more, right? So that will be there. Swag will be there. Conveyor will be on hand. SMEs from Conveyor, including Savita and others, I believe. So that's all going to take place. We're excited about that. Booth presence. We've got a heavy booth presence for KBE, of course, in the Tuesday through Friday event on the booth floor. But also, you might want to, you know, give us two cents on this, but there is a conveyor kiosk for the first time. So that's going to be kind of fun, right? Yeah, so I'm excited about that. So this is the first time that we have a kiosk for our sandbox project, which is conveyor. And if you are interested in modernization and migration of your white loads to Kubernetes, and this is the place that I would say it starts with, because I'm biased and I'm a maintainer of conveyor. So it's just going to get that out. But it is a great project. And like, last coupon, we had this theme of cars and what parts I came up with this conveyor is like the lane assist system for your modernization journey. And I've been sticking with that for a really long time, because that makes sense to me. So if you want to learn about the project, we have a project kiosk in the project for the pavilion, I think booth number 24. So you can come on over there for some swag, learn about the project, see some cool demos that we have got. And if you're interested, you can even know about how to get started with the project. And they can even meet you. Look at that. It's better and better and better. But I was just looking for like an episode or whatever about conveyor in case people are unfamiliar with it. We actually haven't done conveyor on this show because when we interviewed Savita, we actually interviewed her about release engineering. But on my old show that I used to do for Red Hat, the level up hour, I did end up, I know I interviewed some people, so I'm going to look for a link for that. But yeah, I just thought it was kind of maybe we should do a conveyor episode at some point. That's a good idea. Yeah, we could bring on some engineers, you know, have it like a panel, and you know, that would be like cool. And we briefly, Landon, I don't know if you remember, we briefly talked about it in our car interview. Oh, right. I thought we had covered it somewhere. That's right. Yeah, so if you check out the Detroit car interviews, which is I'll throw that link in the chat as well. But when we drove around in the car and interviewed people about Kubernetes in Detroit, which was really entertaining, no geese or other birds were killed. I did not go to Canada by accident. All of these were deep concerns during the trip. So it's definitely worth checking out. But I'll try to link that particular conversation in the chat. Okay, good segue, Landon, into the final point I wanted to make about the fun stuff going on in Amsterdam. So, okay, without revealing the actual brand, because I promised Tam, I wouldn't. I will tell you that, okay, as Landon finds these fun Detroit car interviews, which we called KBE Insider on the road, right? Because it was basically taking this episode and giving it, you know, on the road and people like Savita and quite a few others. There you go, Savita and Landon talking about conveyor. There's a perfect example, right? So we've got several of these lined up for Amsterdam as well. And we do have, and Landon, I don't know if you know this, but 700 horsepower. This is supposedly the fastest car that this particular brand makes. That's what I've been told. And I've even been asked, can Landon handle this horsepower? I don't know. I'm a little, you know, it sounds very interesting. I think I would much rather be driving it in, say, the middle of nowhere, the U.S., right? Rather than kind of the outskirts of Amsterdam. But yeah, this should be exciting. I have driven a large number of different types of vehicles, you know, from moving trucks to, you know, I used to do a lot of theater work and small cars and big cars and minivans. And vans and so, so hopefully it should be all right. I just want to be able to have plenty of practice. There you go. There you go. Well, I did ask specifically for the minivan version for you and they said, no, we're giving Landon the E and then I want complete the rest. I'll say I'll wet the appetite of the audience here. Tune in and I guess it'll be three weeks time and we can officially unveil what we're doing in Amsterdam. What car manufacturer we're working with. What I'll say is it's a major German car manufacturer with their high production. BW Golf. I don't know. Yes, it's going to be exciting. And Landon's going to wear a crash helmet and everything else. It'll be tons of fun. So we'll have lots of folks there. I think, yeah, we're finalizing the roster as we speak of who will be interviewed. But we're all looking forward to that. So that's if we thought Detroit was was fun with the Ford, which it was, I think this is going to be equally fun. So lots, I guess, bottom line. I'm really looking forward to QCon. Lots of great stuff coming up. Can't wait to meet some new people who I've only seen virtually for three plus years now. And yeah, that's a QCon update. Yeah. The only thing I'm a little, you know, it might have been kind of cool if we were trying to figure out a way we could do the interviews on bikes. Being Amsterdam. But you know, how do you talk to somebody on a bike? You know, if you do a tandem bike, then you're like in front of, you know, and obviously it got very complicated very fast. So we went with the more traditional driving mechanism despite Amsterdam and its love of bikes. We did. And we were even considering like the little, you know, hey, maybe we'll get like a boat in the canal or something and have it that way. But and they were all kinds of fun ideas. But in the end, you know, I think we found our spot, I think, especially with this auto stuff. And plus, I mean, again, Langdon 700 horsepower, you can't, you can't match that on a bike. Oh yeah, I'm pretty excited. I will say I'm pretty stoked. Those electric cars, man, they drive so differently if you haven't tried one. It's really very weird. So cool. Well, with that, why don't we call that a show? Thanks everybody for coming. And we hope to see you either in Amsterdam for a cube calm or at the next episode. And, you know, have a lovely day. Take care folks.