 Hey, thanks for coming on the show. Shannon and Darren, I really wanted to call you Sharon there for a second. Get the two names together. Thanks for being on the show, doing our little drive around while we do the interviews. And it's great to have you. And we were just talking about driving stick. So I think we should, you know, props to drive and stick, right? Like, yeah, I really miss it. But we're in the electric Ford Mach-E, right? And, you know, the electric, I don't think really work if you, you know, I don't even know what exactly magic happens somehow. But yeah, so what I want to talk to you about, of course, is Acorn. What are you, you know, what are you all up to over there? Yeah, so we just released Acorn. We just publicly announced it, what, August? Yeah, just like a month or two ago. Yeah. So Acorn is focused on the application experience on Kubernetes, basically making it easier for people to package up applications and run them on Kubernetes. So something the developers can like and use. And something the ops people can also like and run. So it's like trying to make both sides happy. Yeah. So that's kind of the high level of Acorn. And so, what does it do that makes it easier for developers? Yeah, I mean, so it starts from a developer perspective, it starts a lot more towards a Docker-like experience. So we very much were big fans of Docker and the original Docker from way back when. So it has more of like a composed-like experience. So there's something called the Acorn file to describe the application so it can do a full microservice with, you know, volumes and secrets. So you define the entire application. Gotcha. But then you can build that with Acorn into a single asset, like an OCI artifact that gets pushed into a standard registry. Yep. And then so from there, once it's in it, it's an image, basically, then you can just deploy that on any Kubernetes cluster and then just run that on a Kubernetes cluster. Gotcha. Gotcha. So we have a little Acorn operator that runs the Kubernetes cluster to assist that. And is there like some, is there like a registry or something? Or like, where do you, where do you push it? So it just goes to any Docker registry. So we're using all the regular OCI Docker technology. So it's the standard stuff. Yeah. So the same way, like, today you're building Docker images and pushing them to a registry. So now you build Acorn images for your application and then push those to a registry. So your Acorn image actually includes like the application metadata plus all of the, like it links in all of the Docker images. So it creates one big artifact that you can sign that defines your entire application. And then you can move that between like DevTest, Prod, whatever, whatever you want. So what's particularly funny about your story is, have you ever heard of an application or a project called Atomic App? A little bit. So I worked on that in 2013. Oh, yeah. Which did what you're describing. You know, probably not as well, right? But it was the same kind of concept is like, ours was slightly different in that what we wanted to do was more like the container that you pushed around was a description of the application. And so then it would go and kind of get the pieces because we weren't sure we wanted the big thing. And to be fair, right, like it never saw a customer. We just kind of rolled, you know, we're building it and because we thought it was a problem in the space. So one of the things that's unique of what we do is because we don't actually like copy in the Docker images, we're just because an OCI registry is really just a link to a bunch of digest. So we just link to the existing Docker image digest. But if you do like kind of like a push or pull, since it's all linked together, it kind of appears as one asset. But it's just this kind of this big tree of layers and manifests and indexes. And so we link it all together. And so you can sign it, which is super awesome. Yeah. And then also like if you want to like, because a lot of times let's say you're moving to like an air gapped environment or something, it's really easy to just pick up that one asset because it looks like an asset, even though it's all these links. And just like kind of push and pull that. So you get your whole application. So you don't have to deal with like, because that's what like, you know, you can do that already with the helm chart, you can push that to a registry. But it will not, it doesn't include all the Docker images. So then you have all these references to different images. And then those might be mutable tags. So things have changed. But like one of the key things that we've done with Acorn is like, because there's been a lot of efforts to kind of address the developer experience on Kubernetes. But we've like, we're trying to embrace like the full power of Kubernetes, but present it in a way that the actual developers, whoever's building the application, does not need to know Kubernetes. So we're not using like Kubernetes style YAML. We actually have kind of like our own markup language, you know, it looks a lot like a Q or Jsonnet. But it's so it's something like really tailored much towards like, that it's more abstracted concepts. So it's like, you just deal with kind of describing the application and then Acorn just makes it turns it onto all the Kubernetes stuff. Right. So we're not like, you're not going to see like, you know, Kubernetes manifest and stuff in our, in your description. Yeah. So does it, does it feel more like, I mean, I think it's a part of the appeal of a Docker file, right? Was that it's basically bash, right? Yeah. Yeah. And that's, and so it's like, we mimicked it. It's like very, very, so we have the, the Acorn file is like, it's, the level of abstraction is very similar to Docker. So it's like, you're just defining some, some containers with image and arguments and those use some volumes and secrets. But like under the hood it's using all the, you know, it's like deployments and, you know, and PVCs and all the, you know, ingress and services. And so we just wire up everything kind of like best practices while just kind of respecting the, the kind of the intent of what the Acorn file, like the way they describe the application. Right. Right. Okay. It's a pretty high bar. I mean, if you think about like though, you know, I mean, Kubernetes works great and Helm works great. It's not like people can't do everything. Yeah. Our whole principle is, okay, can we make this way easier? Can we make this way easier for a lot more people? And, you know, and at the same time, it's like, how do you avoid all the mistakes of all the passes that have come before because at some level that's what we're building, right? It's a new pass. It's another layer of abstraction that, you know, takes away Kubernetes. And that's typically been really hard to get right. Right. I mean, you've got Heroku's and cloud boundaries and even early open shifts and stuff that were very, you know, Pazzy. And for the most part, you know, we saw most people migrating towards just, no, just give me Kubernetes, give me, you know, give me native Kubernetes, give me Helm. But nowadays when you go, you know, we were at Rancher for eight years and working with so many of these companies that had built Kubernetes, were managing Kubernetes in the cloud, had Kubernetes everywhere. They're, you know, the platform teams were building these massive, effectively platform as a service themselves, right? Helm templates and scanning and GitOps and all this stuff. And everyone was a snowflake. Everyone was heavily maintained. So I think our, our inspiration was what if we did an open source project that anybody could use that sort of simplified that whole process and was continuously being maintained and just got better and better over time. Yeah. I mean, in a lot of ways, right? It's, I mean, it's kind of like the beauty of like Ansible, right? It's like, it feels in the same way as that, like, we're not, you know, versus like puppet and chef is like, we're not saying you can't get down and dirty and do whatever it is you actually need to do, you know, because you've got some bizarre use case. But if we give you a framework to put it in, maybe the overall infrastructure will be a lot cleaner. Well, in the administration, right? We found is like just upgrading clusters, you know, people are so afraid of what is in there. And whether it's, and that was, I think one of the things Darren really got right. And we've been getting really good feedback on just the sort of secure by design architecture of Acorn. Okay, you know, let's make secrets super easy so that everybody's going to use them in exactly the right way. Right. Let's, you know, not allow privileged containers. Let's, you know, automatically allocate namespaces and just really just, just think about the best practices and build those again into a way that, you know, I mean, we've been supporting thousands and thousands of Kubernetes clusters. And it just is like, well, if people just wrote their apps like this, it'd be a lot easier for us as operators. And I think that's where we're trying to get right with Acorn was. Well, I think it's one of those things too, where it's like, I still don't really understand why passes didn't stick around. Because like, I think there's, there's a tendency amongst engineers, right, to think that their, their thing is somehow special. And, and to then, therefore, you know, avoid things that feel like they have lock in like a pass, right? So I think maybe you're kind of hitting that, that, you know, sweet middle ground, where it's like, they feel like they can be a special snowflake, but because they're probably not actually going to be, you can actually, you know, capitalize on similarity of infrastructure and deploy. That's it. You nailed it. Because it really is that part where people are so afraid that something cool is going to come along later that they're not going to be able to use. I think nowadays though, what's interesting is when we're thinking about where Acorn's going, the cloud services are going to probably be the most important part of that because everyone wants access to, you know, these cloud data services, right? Different types of whether it's for machine learning or it's just a back end, you know, Mongo, they want Atlas, right? They want access to these services. And, you know, I think it's going to be less and less important, you know, like as a platform, I don't think we'll be doing data services the way that Cloud Foundry did. We'll be doing data services where we just assume that you're using cloud-based data services if you don't want to deploy, you know, it's like you can choose to use the Mongo image and bring up a Mongo server, but you're probably just going to use, you know, certainly more and more we expect people to use cloud-based databases. And so, yeah, it's really interesting with my students is that, you know, because they're, you know, they're taking computer science degree. And in a lot of ways, it's very traditional. And, you know, and so me and so we do all these projects for like third parties. And, you know, and so both the third party, oh, Squirrel trying to die this time, I've almost killed a seagull and a couple of geese. Please do not kill a squirrel with us in the crowd. I haven't actually done anything bad. Bad branding. So, but yeah, in getting, getting the look, so the client will present a, well, I basically want to make a website, right? And getting them to try to maybe think a little bit outside of the box for lack of a better term. But it's like, no, this one system, for example, it's a message banking for ALS patients, right? Or vaguely like that. And, and I'm like, no, what this can be is a serverless function that you upload these audio files. And then, you know, basically, there's a pipeline of where we can like interject audio editing of various sorts. We can either use a cumin, you know, in the mix, right, where we have an actual audio engineer, or we can go out to some service, you know, but kind of getting them to wrap their head around, you know, essentially cloud native development, right? Or even event driven architectures, when what they think of is this very serial or sequential development style is really difficult, you know, and, but I, you know, for me, at least, you know, I think what you were kind of describing like that's, that is what we're going to be doing for all development in the future, right? It's like, I'm going to write my one little bit, it turned into a serverless function, and it's going to get all of its data services, all of its file storage, everything else from somewhere else, you know, and, you know, magic happens here. I don't know. And I think when you imagine that future, though, you kind of realize, oh, yeah, that, of course, you know, we're not going to have the same types of paths as we had in the past, right? To do this right, you've got to kind of reimagine the whole thing. And yeah, it's a high bar. It's something that, you know, you're going to have to actually appeal to users. So we're just in that right now, we're kind of in the alpha phase of Acorn, we haven't pushed out, we're just demoing here at KubeCon for the first time, you know, cloud service that ties the Acorn experience to all the infrastructure stuff that hopefully will grow into what we build and we'll be able to start sharing with people. So I was curious, have you seen a project called, the nickname is Sochi, but it's a streaming OCI? I was just talking to Chris Short, he was one of my earlier interviews, he was talking about this project that they contributed to CNCF, it's Amazon, but it does it streams the layer getting of containers, which I think might be really appealing to the delivery system for... Oh yeah, so it's, yeah, that's like, it's a newer version of like this, the snapshot or the E-star or whatever. Yeah, but basically it's like kind of in the background and load all the layers rather than kind of having to get them all at once. Yeah, but it seems like it might be really appropriate that you can kind of, you know, then you can kind of get piecemeal. And then especially if you end up with an environment that is very PAS-like, you know, you have your PHP and your Python back-ends or whatever, but then if they have a shared sense of those acorn files, you know, or a lot of it, right, then you can just, you can also take advantage of the infrastructure optimization. I don't know, I just think it'd be kind of cool. It is, I mean a lot of it right now, it's these cloud services too that are getting into, you know, when we start to get requirements from people, a lot of them are about, you know, look, everyone's got OpenShift or Rancher and they've got all their cloud, they've got all sorts of Kubernetes and they've done a lot. I mean, they've just done so much work, like so much work on OPA, so much work on Helm, so much work on building around it. But I think that's going to be one of the big, you know, why I say the bar is so high. It's like, can you actually, you know, give enough value to replace all that work? Yeah, exactly. Like it's like, wow, I mean, you know, yeah, that sounds interesting, but you know, how much am I, you know, I've already got this thing sort of working. Yeah, I mean, I had a very similar experience when I was working at Red Hat, right? Because I would go to customers and see the massive infrastructure they had built to build RPMs. And I was like, you know, there's this open source project over here that does this already, you can just use that one. And, and you know, when I wasn't being facetious, I would, you know, they would explain, oh, no, no, we needed to do this weird thing over here, or we had this little part over there. And, you know, the system that builds RPMs for Red Hat, which is the same one as the open source one, right? It was written way back in the day, and it was really custom to what Red Hat needed, right? And so, yeah, I think, I think what you're trying to do is really interesting, but also I totally recognize it like super difficult. It's always what we try to do. One of the things about like Paz, that's always been, you know, kind of the restrictive nature of the, you know, it's great, you can just push some source code and it builds and goes to production. But it's like, everyone has a slightly different flow and how they do CI and CD, different points they need to inject, they do this. So it's like, you know, with Acorn, we were basically what we focused on is the easy way to basically build an asset. And then once you have that asset, you can easily move it around and deploy it. So you can really customize the CI and CD flow. Because those things, you know, it's like CI, for example, is get up actions, you know, like that's just taking off like crazy. So it's like, well, that's a pretty good tool. Like, you know, people are using that, you know, there's no reason to replace that and have to be stuck into like our specific view of how CI is supposed to be done. Yeah. I think that's the truth a lot of levels, too, because like you really think about, you know, to build Cloud Foundry, the team had to go build Bosch, right? Like they had to build basically Kubernetes. They had to do it. They had to build all of Kubernetes. And then all of a platform on top of Kubernetes. And it's the same for Heroku. They had to build all of that. Yeah, it's one of the reasons. Yeah, it's like to do it, you have to be experts at infrastructure and expert at development. And it's kind of cool to do it right now, because we don't have to think about infrastructure. It's like, we don't even really have to think about dealing with on-prem infrastructure. There's so many ways to get it. The beautiful thing, like, so with Acorn, it's like, we're just focusing on like, how do we take all of the Kubernetes ecosystem, like all these amazing things that are already there, and just basically put that together in a nice, like, make it very accessible to people, make it very easy for the developer, make it very easy for operations. So it's like, things like, it's like, oh, you want progressive delivery. It's like, Acorn, we don't have to do progressive delivery. I mean, it's like, that already exists, Flagger, you can pick up some run. It's like everything, it's like, the ecosystem is so rich. It's like, so it's like, we just need to plug into that. We're just basically trying to, you know, it's like, we have all this functionality, but people just struggle today in leveraging all of that. You know, so it's like, just make it easier, bring it all together. So actually kind of on that note, like one of the challenges, I think, in working as an engineer, a developer in the open source world, is knowing which projects I should invest in, right? Because, you know, there's often a competition going on, you know, should I invest in mesos or Kubernetes, right? Yeah, way back when. And so do you, because as far as I'm concerned, part of providing a better developer experience is how do you recommend stuff, or do you recommend stuff as part of Acorn? Yeah, so that's the idea of like, so with the Acorn and the Acorn files, we're trying to abstract the actual, you know, so you're just describing the application and higher level concepts. So then at runtime, at like, implement, like, when we actually deploy the application, we can make those choices. So it's like, Acorn, we have a default set of technology, but we are not looking to like, prescribe, you have to use this, you know, so it's like, we'll be doing like service mesh integration. So if you want link or D versus STO, that's fine. They both, you know, provide. The user shouldn't know. If I'm a user, I shouldn't know whether I've got link or D or STO. Right, right. And as long as the, you know, the end output function is there, and what I need from that service mesh, you know, it's more like, yeah, exactly, it's auto scaling, or it's blue, green, or whatever, it's canary, you know, I have a structure that I'm looking for. So we want to implement those structures. And that's why that, I mean, it's like, you know, this is opinionated by its core. It's like, if we're not opinionated, we're really going to be just making the same mistakes, I think is, we're just going to create another thing on top of Kubernetes that doesn't have any value. Yeah, you think of XKCD's, you know, yet another one, whatever it is. And that's not policy, but yeah, protocol. And, you know, people have tried, you know, there's so many people have tried this application layer of trying to get it right. So yeah, I mean, the bar's hard. Yeah, yeah, but I do like, I mean, I will say, you know, I really appreciate getting things that are opinionated and working with things that are opinionated, as long as, you know, if I can figure out how it's like well documented about how I can kind of do something slightly different, you know, where, where I can't, for whatever reason, agree with your opinion. And that's the great thing. So it's like by us, because like when we built Acorn, it's like, so the user experience is really through a CLI and it looks a lot like kind of Docker, like run and build. And but under the hood, it's 100% Kubernetes architecture completely following all the best practices that you built things. So the nice thing is, is that, you know, we can make it work automatically. But for all of those corner cases where enterprise like, no, I need to do this, I need to do that or whatever. It's like, it's Kubernetes, you can still plug in under the hood. But again, that's all on the kind of the operations side infrastructure. It's all, you know, that's an implementation detail of, you know, well, and particularly what, you know, like you haven't really mentioned it, but should be obvious, right, which is that when I have a change in my operational environment, I also don't need to hassle the developers, right? You can, you can just go and oh, we've decided we want to go this other route for this part of the product, you know, platform. So we can just change that and kind of re deploy, right? Yeah. And our guess is I think over time that those will become less and less, actually, like I think, right, like the probably winners. Yeah. Well, also, I think the analogy in our head is we're trying to build something more like GitHub than like, you know, a sort of a deployment platform or framework. We want something that's like, this is just a really, really easy way. If you use it, you don't have to think about any of that stuff. And, you know, hopefully it appeals to really, really micro users. Like we, it's like, I'd like someone who's one of your students to be able to come in there and be like, oh, this is sweet. Just boom, run, deploy. You know, I pointed at my EKS environment or my digital environment. Well, you're in that really weird, I think it's a really weird kind of marketing position, which in some ways, also had, right, which is that, like, your target audience is developers, but you have to make sure the operators are not afraid of it, right? Yeah, exactly. And I think that's, that's a really, you know, that's a really tough spot to get right. And one of the good, I mean, I think, I think that's an area where our experience at Rancher helps so much is like, having built for so many enterprise Kubernetes platforms, we kind of know what they need and what they don't need and what they care about. So it helps a little bit having that background, but not, you know, these days, I really think more and more we're going to be deploying against, you know, cloud-based Kubernetes. Like that's what's going to be the vast majority of the back ends. And it makes you realize, you're like, okay, if everything is, you know, if we're going to see 80% of the workloads running on, you know, GKE, EKS, AKS, digital, you know, anyone's hosted Kubernetes service, then, you know, really, I wonder how much their opinions are going to shape this as well as they make choices and they make set defaults. I think that will certainly be one of the key influences on the directions we take, because that's what it's like. For a lot of these things, I don't so much see that there's going to necessarily be like a winner in the technology, but it's like, if you're in AWS, you're going to be using their storage, their networking, their security scan or whatever. If you're on Google, you know, so it's like a lot of these things just going to be tailored to the environment, whatever makes sense. If you're on-prem and using OpenShift, it's going to be all, you know, Red Hat technology. Yeah, like, I don't know if it's a term yet, but I really feel like it should be, which is essentially cloud locked, you know, because you really do kind of get locked into those, the various clouds because of the services they offer based, and you kind of make that initial decision. Yeah, but I mean, I don't, like, I think you're still with Kubernetes getting the, that's the kicker, right, because it's like, well, yeah, here I use their version of all this stuff, but it's still a standard approach. That I can import, yeah. Yeah, so it's like, because we see that because it's like, when we were doing, you know, K3S and stuff on the edge, it was like, people love the idea of, like, I can use a Kubernetes, like, I can develop as though I'm running it on the cloud, but it's going to the edge because it's just Kubernetes there. Right. Even though it's like, my application is obviously not portable from the edge to the cloud, like, I'm not going to do that. It didn't make any sense, but like, it's the same approach across, you know, different teams or within a company. And it's just like Linux sort of taking over the world. I think now we're in the stage where Kubernetes is taking over and it becomes this ubiquitous backwind. It doesn't matter if you're in China and you're working on Oli Cloud or you're, you know, in the US and you're working on AWS. I mean, everywhere you go, you're going to get Kubernetes. Yeah. And everybody's going to have more or less the same core capabilities. And I think the nice thing is, you know, when we look at it, we're like, well, if we go somewhere and they don't have a good service mesh option, we'll bring our own, right? If they do, we'll use theirs. And so I think it'll be more, the hardest part for us will be supporting backends, right? It'll be like, okay, this is, you know, putting the work into like support, really supported too, because we could try to do lowest common denominator, but that's never going to really fly. I got to get in there and just really make the experience on a cloud provider fantastic. And if we get enough traction, you know, hopefully they'll help us. Initially, it's all on you. It's like those things like lowest common, like those solutions never work or whatever. And so it's like the, it's like with Acorn, what we're really trying to do is separate into like application concerns where this versus like operations and infrastructure. And what you find so much of Kubernetes right now of the kind of the ecosystem, it's, it's very oriented towards operations, all the technologies like the storage and networking and security and all the stuff that's all like from a developer perspective, like that's just a crapper. It's like, well, that should just run. Like I don't want to, like to just run, you know, I'm not involved in that part. So it's like, you know, leave Kubernetes to the, to the, you know, the operations people understand it and then, you know, leave the app and the, you know, that to the app teams. Well, I think that's, I mean, to be honest, right, I think it's been one of the really good things about Kubernetes is that it's kind of enforcing that separation you're talking about. It's really starting to make it real. Like, I don't know if either of you remember Delta cloud, which I had such high hopes for, but it was basically this, this library that would let you talk to any of the clouds at the time, which was basically AWS and Oh, that was like Libcloud and the way back. Yeah. Yeah. This is like open stack days. Yeah. Before that. Yeah. Oh, yeah. But it was part of it was to support open stack so that people could bridge from Amazon to open stack. Yeah. I think that's part of its original mission, but, but it didn't do a very good job. It did the lowest common nominator model, right? Which I think is why it never really took off because of that you got to separate those two sets of concerns. And that's what we saw it like with the open, the open stack. That was the kind of a major flaw across the board with the open stack was that they were trying to abstract and like every vendor who wanted to differentiate, they're doing the lowest common denominator. And that's what like, so this is kind of the beauty. It's like Kubernetes is just, the architecture is so good that like everyone's been able to kind of come in and do their differentiated features and whatnot, but all still playing within the same space, like the same ecosystem. And so, you know, yeah, it's like that. This is why, so it's like we're not looking to, you know, kind of abstract that and do lowest common denominator. It's like, no, you take advantage of the, you know, if you have this super great networking or, you know, AI system or something like that, you take advantage of it and Kubernetes allows it. Right. Yeah. No, that's, it's really very cool. I will definitely be checking it out. Like I kind of heard the name of the, you know, the company and what you were trying to do, but it's really been interesting. Especially for like, for education, like, you know, that, because I've seen, you know, like how quickly, like college and stuff can pick up with like Docker and get, you know, it's like, since it has a similar user, user experience and everything, you know, you can install, you know, Docker desktop and then be running an Acorn app right away. Right. So it's like, it's pretty, it's as simple, it's as simple to get going as like Docker compose. Right. Right. But it's the big difference between like what we're doing with Acorn and say Docker compose is like, we're still, there's no intermediary step. Yeah, we're connecting you still to the full Kubernetes ecosystem, that thing you can, you know, you don't have to switch to a different tech stack to then put it into production. Right. Right. And this is the same thing you can do on your, on your laptop, the same thing can run, you know, in the cloud, which is as, you know, if you've ever done any real production apps, it's a very nice. Oh yeah. Yeah. We know. I mean, it's like, so you switch to helm and then, you know, then you're doing go templating and yeah, yeah. Well, at least part of it too for me is like, you do the deployment type development work so rarely that you like to relearn it every single time you do it. You know, it's like every time I want to stand up an Apache and put a new web server in there, right? I have to remember how and figure out how to like rewrite the config files to get it to work because you know, you just don't do it often enough. Yeah. That's why it's going to be for most people with Kubernetes. Right. If you're on it and we were talking something the other day, they're like five person team of which two of the people were just working on the Kubernetes deployment elements. The other three were doing the application. Right. Is that the overhead? Is it 40% overhead? Is what we kind of cost right now for your sort of like? Well, I mean, I have the problem, right? Because I mean, you know, like, I, you know, I teach most of the time, but you know, I fool around developing, you know, various bits, you know, and I want to go and I've been messing with Tekton for one of the learning paths for a cube by example. And, you know, and it's like, I have to relearn all this stuff and, you know, and it's a whole different style of, you know, even pattern of development, right? Because it's the, you know, the more the promise style of development. And you know, so it's like completely different. So yeah, I totally appreciate that sort of thing. You know, it's like when we talk about like computer languages, there's like something that's simple like C where you can keep the whole language in your head versus like C++ where it's like, you know, it's as large, you know, it's kind of like Kubernetes is a lot more like a C. It's like, you can't possibly memorize all of the things so it's like me. I compare it to Python. We will have to go as far as C++. Well, also, do you really want to be labeled as like C++ forever? But Python is just as big. Well, I used to compare it to Java a lot. That would really upset me. But some of the things is like, because I've been using Kubernetes, you know, obviously day in, day out for the last, whatever long it's been around. I still cannot from scratch write like a like a deployment or I could not actually like, okay, I'm going to set up like a deployment with a config map and a service. I couldn't do that from scratch. Like I got to find some template or something like that. Yeah, I completely agree. Although to be fair, right? I mean, like, for the vast majority of almost anything I do that's related to like programming or whatever, I almost always start with something else and then like, that's it until it's right. Yeah. But that was one of the things I always liked about like Docker and Docker compose was like the, it was simple enough that for the most part, like after you just, yeah, you can memorize it pretty quickly, right? And it was pretty straightforward. And it was quick to look up the weird ones that you usually, yeah. There wasn't really, although I still would like someone to clearly explain to me the difference between CMD and entry point. But you know, like, I get it, but I don't get it. Yeah. So, I don't know. So what else, what are you, what are you doing at KubeCon? I mean, so you said you're demoing, you know, an early version of the product. Are you giving any talks? Are you doing stuff like that? We're, no, we're, we kind of are the last ones in. I mean, we booked a sponsor. We were like, all right, we should go to KubeCon about a month and a half ago. It was just never a good idea. So to find us, you just got to walk and walk and walk. All the way at the back. Just keep looking. You see Janitor, you went a little too far, but not too far. We know, we know if you find us, you're really interested. And the development team loves you with this. So yeah, by the way, you have a brand new deadline because we have to go and show it at the show. Oh, yeah, of course, of course. Oh, Darren, never, never, never fails to deliver. I never even worry. I was actually giving a talk of, you know, kind of demoing something or whatever in my like entire dev team was like in the audience. And I was like trying to like demonstrate something. I'm like, what am I doing wrong? Because like, you know, you always get flustered on stage and you know, you figure you mistyped something or whatever. Yeah. No, it turns out there was a bug. They fixed the bug while I was on stage. And so when I went back to it later on, it worked. And so I was like, I was like, I was like, my mind didn't I do exactly the same thing before? It was really very fun. Speaking of always being on time. Yeah, man. Well, we've had our experiences. Darren and I have been hosting meetups online for like, I don't know, eight years together. And I would say, you know, everyone, the only rule is we always do live demos and we always show real technology. Yeah. Yeah. I don't know what our batting average is, but we would not be hired. Like, we'd be like, we'd be like, double A at best. We're never we'd meet the majors. These things break all the time. You know, what's so interesting about that though, is that like, so this is kind of gets at why, so we started this Twitch channel, right, right around the pandemic. And programming on Twitch has been kind of growing in popularity. And my theory is, is that because one of the hardest or one of the things you get from experience, right, is how to like approach debugging, like how to approach fixing a problem. And when you don't have any idea, you know, what do you do, right? And so I think when you're watching somebody who's live programming, and they, and they're an expert, right, and they run into some problem, I think what's really interesting for the viewers, especially a junior developer, is like how they approach fixing it. And you can watch them do it live. And so I bet there was actually a lot of people who appreciated when you're demo. Oh yeah, we get lots of love. Like you get super stressed out. The best ones are they're like, no, no, no, you just misspelled that. Yeah, yeah, yeah. I get that in class all the time, because I live code in class. Sometimes I'll just stop. I'm like, did anyone see? What did I do wrong? It's worked in like 100 times out of 100. Yeah, I basically do that every lecture. So yes, I know exactly. It's the best though. I think people doing this is so valuable. Like, it's also when somebody who's really good at this has been doing it for a long time, screws up over and over again, it makes everyone feel like, wow, he's really not that good, or maybe we all just suck at what we're doing. Exactly, which is probably more likely the case. If you ever need a boost of confidence, just watch my demos. So bad. It will definitely make you really nervous to use any product he's built, but you know, it's great. It's really great. It's so easy. It works on the eighth try. Every eighth try. It's consistent. Yes, it's alpha. We'll fix it in beta. Right. Well, thanks so much for being on the show. We really appreciate it. Yeah, it was fun. Thanks for having us. It was great. We had a nice little tour of the town. Almost killed the squirrel. Almost killed the squirrel. Didn't actually do it though. Like I said, my ratio is pretty good. No animals harmed. Exactly. We think we might need that as a tagline, because the number of times I've had geese meandering across in front of me.