In this episode Rich speaks with Lukas Gentele from Loft Labs.
Topics include: Running Kuberentes on top of Mesosphere, how Kubernetes killed DevOps, why Kubernetes multi-tenancy is a challenge for platform teams, the origin of vcluster, speaking at KubeCon, and the fear of breaking k8s changes.
A podcast about Kubernetes, and the people who build and use it.
Rich: Welcome to Kube Cuddle, a podcast about Kubernetes and the people who build and use it. I'm your host Rich Burroughs. Today I'm speaking with Lukas Gentele, the CEO at Loft Labs. Welcome Lukas.
Lukas: Hey Rich. Thank you so much for inviting me to your podcast.
Rich: Oh, I'm uh, excited to have you here. For people who might not be aware of this, we work together. Um, I'm an employee at Loft Labs, a Developer Advocate, and we've been working together since, I guess it was April 1st, 2021. So it's been like, no so, uh, I think this is gonna be really fun. This is the first time I've actually like interviewed someone for the podcast that I I've worked with.
So, uh, I think that, like, I know you better than I do most of the guests that I've had on.
Lukas: it was not a April foods joke, but yeah,
Rich: Um, so. Did I pronounce your last name right? Because I, this is a funny thing, but I never, I hear it pronounced different ways and I never know if I'm even saying it the right way.
Lukas: Yeah, no, I I've heard it a million different ways as well. I, I personally like when people go for the French one, I, I feel like that sounds, you know, it sounds like music to my ears, but
Rich: Wait, what's the French one?
Lukas: Uh, they go like Jean-tel-e something like that, right?
Rich: Oh, wow.
Lukas: Yeah. It always sounds like really musical, but actually the, the, you know, the original like German, uh, pronunciation, I guess it's originally actually more Italian, but, um, you know, in Germany it sounds, uh, a lot harsher it's, uh, Gen-til-a.
Rich: Oh yeah, yeah. Yeah.
Lukas: don't, I don't make anyone say that in, in the states
Rich: All right. So to start off with, how did you get into computing?
Lukas: Yeah, I think, uh, I started building my own little, uh, website when I was like 13 or so. Uh, I think that was like the first microsteps, you know, like, uh, taking, yeah, I had, you know, I started with this homepage, uh, builder thing that, you know, they, they started becoming really popular, uh, at that time. And, uh, you know, everybody built their own, like even a MySpace page or stuff like that, you know. But I, I did the more like customizable kind of things.
And, um, then I was wondering, yeah, how can I. Automate certain things I don't have to update update that manually. Right. And then I started, uh, you know, learning a little bit of like PHP scripting, you know, that's, that's kind of how it started originally. I actually, you know, the, the site became pretty popular in my high school because I used to, uh, you know, upload like funny stuff from the school.
Um, even the recording of a teacher, which people loved a lot. Um, but the teacher didn't.
Rich: Oh, wow.
Lukas: So that got me a little bit of trouble, but yeah. Um, I made up for it by, you know, I actually built the school website, uh, about like two years later or so, and I had a little more experience cuz ours was from like the, I guess like early nineties, bare minimum school website.
And I think that's, that's kind of how I started, you know, in that kind of web design, uh, you know, sphere.
Rich: That's really funny that you kind of started doing fronted, stuff like that. And, and lo and behold now you're way on the other side
Lukas: Yeah, absolutely.
Rich: of it. So what brought you into using Kubernetes specifically?
Lukas: Yeah, I think, uh, we were essentially building, a lot of custom software, uh, throughout college. It was part of, this like chair, uh, they were, the chair of artificial intelligence at the University of Mannheim. Uh, there was obviously a lot of, um, compute intensive workloads, uh, that they were working on.
So that whole like sphere with, you know, containers, Kubernetes, uh, was obviously super interesting. And then I was running, uh, a little company on the side, uh, throughout my college years where essentially, you know, uh, hired every good engineer I met in in college. And, you know, we did contracted work, uh, was basically, it was a services company.
We didn't, you know, build a product or anything, but we build a lot of products for other companies, you know, even for, you know, we build the e-learning platform for a venture backed startup. We built some,
we build some stuff for, you know, uh, mid-size companies. Um, it was really, really interesting work. And, you know, as a contractor that you always have like new projects starting over, so you can essentially, uh, you know, it's a lot of greenfield.
Um, so you can explore new technologies. And we started, uh, working with Kubernetes and it was just super fascinating. And then, um, there was an opportunity to get a research grant, uh, just at the end of, you know, my time in college when I was wrapping up my Master's degree. And that allowed us to purchase some hardware.
So I actually physically bought servers, put them in a data center, uh, and build a, you know, Mesosphere cluster and ran Kubernetes on top of Mesosphere and stuff like that. And, you know, that was
Rich: Okay. I was gonna ask you about this because this was a, this was a story that came up. We were, uh, you and I and Fabian Kramm, who's your co-founder and the CTO of Loft Labs, where we work. We all were having dinner, um, in Valencia. And this story came up about the fact that you, you guys ran, ran Kubernetes on top of Mesossphere. And every time I think about it, it just makes me laugh
because like, like where did that come from? Where did you get that idea?
Lukas: Yeah. I mean, we, we had, when we started, uh, with, with Kubernetes and, the whole, uh, container orchestration world back then, it was super, super young and it was really hard to get any kind of reliable information about how to actually, you know, operationally run that stuff at scale. And I think there was a lot of marketing floating around in terms of like, people want, didn't want, you know, Kubernetes to succeed, I guess, and were kind of spreading things like, Yeah, it's not really scalable, and stuff like that.
And, you know, Mesosphere was, uh, Mesos was a lot more established, I feel like, and had a lot bigger, you know, like marketing engine and presence and bigger companies already. Um, so, that seemed to be the scalable solution. But Kubernetes seemed to be such a better interface. So, you know, there were actually some tutorials out there that kind of helped you, uh, you know, get the scalability of Mesosphere while at the same time, get the great API, uh, interface that, you know, Kubernetes provided.
And we were like, yeah, that actually sounds like a great idea. So we did that on bare metal, which was a pretty terrible idea.
Rich: Wow. Even on bare metal. Wow. So I, I should, I should dig around some and see if I could find like one of those tutorials to throw the show notes.
I
just it's so
Lukas: has some of these servers
Rich: Oh, so, but, but I mean, this is funny because it's come up before I've talked to other guests about this. Um, there was a time, like very early on for Kubernetes, where if you baked off Mesos and Kubernetes, Mesos was the choice.
Right. And I don't think that was just all marketing. I think it just, it just got an earlier start. It was more mature, you know, and, and, um, it didn't take too long to get past that point. It, it pretty soon became obvious that the, that Kubernetes was the choice and, and that was, you know, years ago. But, um, but yeah, it's always funny to me that, to think about those times where it's almost like the, the VHS/Beta thing, right.
It's like, there's, there's a time where, like, you would've bet on the technology that didn't end up being the best one in the long run.
Lukas: Yeah, it's pretty interesting. I recently talked to, uh, a pretty large financial institution and there are still financial institutions out there right now, which are in the process of migrating from Mesos to Kubernetes at this point, just because they had really large
deployments out there in, you know, You know, that that institution I was talking to, they said that, um, they even ran experiments as well with Kubernetes on Mesosphere, out of the same, you know, thoughts
and the same rumors that they heard and stuff like that.
And I'm like, oh, really? So it wasn't just us doing that kinda stuff. Like, even like major companies were doing this, you know, crazy stacked approach. Um, it's really, really funny, but I think, uh, one, one thing that that manager I was talking to, uh, told me, so she said the best thing, uh, they kind of, uh, have as a, as a mantra within the company and the it org is,
they just make a call at some point. Um, because you gotta move forward. You will have migrations. That is just inevitable, right? You can't always bet on the right thing, but you can't also evaluate and wait forever because there's just a business need for more compute, more scalable infrastructure. And then you just gotta fulfill that.
And if you bet on Mesosphere and then, you know, that company is not doing so well a couple of years later, and Kubernetes is obviously the, the winner in the orchestration war, you know, then you just gotta have to make that migration. That's that's fine too. Right? At least you had a solution in place that worked for several years.
It's not like, you know, Mesos was a terrible thing that didn't work at all right.
Rich: Oh, absolutely. Absolutely. And I, I think that's a great point. And, um, I think I'm one of those people who tends to, like, I could get caught in that trap where you overanalyze things instead of just like making a decision and moving forward. Um, yeah. So then you, um, you founded a company that makes Kubernetes tools. Uh, what made you think that the Kubernetes space was, um, where you wanted to put your energy?
Lukas: I found it really fascinating. Uh, just that there's so much, um, you know, I think it, it combined two of my favorite things. Uh, one is, you know, pretty deep technology and really thinking about how to build systems the right way and designing APIs the right way. There was a lot of thought in that, in the Kubernetes space.
And then the other thing is it felt really like startup, like, right. I think the CNCF did a great job at drawing into, uh, their band, you know, kind of like all of these interesting companies and interesting projects and it's super vibrant and there's always something new. Um, and then venture capital got really excited about the Kubernetes space as well.
And that was just for me, both two really fascinating things that I always, you know, like I was always entrepreneurial. I was always had a love, uh, for, for technology and, and innovation. So I think that's a, that was a perfect com combination for me where I said like, oh, this is cool. I
Rich: That's really, really interesting. So, um, you, you talk to a lot of folks in your job who are using Kubernetes. Um, a lot of them are people who are in roles like a, a platform engineer, or maybe a platform engineering manager. Um, I know that, uh, you talk to them a lot about multi-tenancy and we'll get back to, we'll get to that later.
But, um, what other things have you heard from people that they struggle with when it comes to
Lukas: I mean when it comes to Kubernetes, there's probably like a thousand different challenges. I think, uh, a pretty hard number challenge is cost. I think that is definitely something, uh, that you hear everywhere in terms of like just, you know, accountability for cost, uh, tracing things back to who did what, and why is this getting out of hand, and do we still need this?
You know, all of these things that are even, uh, they're even hard in, you know, things like AWS where you spin up just regular virtual machines. Right.
Um, but they're just amplified when everything now is in a way ephemeral and dynamic and automatically rescheduled. It just makes that whole tracking and accountability so much harder.
I think it's a really fascinating, uh, problem to, to, you know, make sure that that doesn't get out of hand.
Rich: Yeah, absolutely. And you're completely right. Like this, this isn't a Kubernetes specific problem, right? Like, like my last SRE role was at Puppet, you know, several years ago. And, we one day somebody found a bunch of, a bunch of, um, machine, virtual machines that we had running in Europe or something that like nobody had looked at because they were in a different account.
You know, it's just, it's just really, it's really hard. And it's hard to know like what, what is actually being used, you know, as opposed to just sitting there idle, you know,
Lukas: Yeah, no, absolutely. It's definitely a huge problem.
Rich: Are there other things that you hear about a lot for people?
Lukas: I mean, uh, it was kind of interesting to see, um, you know, in, when, when I started out in the Kubernetes space and we built that first tool uh DevSpace, as a, as a developer tool, we were kind of experiencing that pain ourselves. Cuz the reason, um, as I said, we were using Kubernetes was as a platform to built things on top of right.
Not just, uh, you know, I mean it's not Kubernetes for the sake of Kubernetes. It's really, you wanna build things on top of it and you have to build them in a certain way so that I actually run really well on Kubernetes. Um, and I think there was a certain, um, unawareness, uh, back then when we started, that we released that project DevSpace and I think Skaffold was like in its, in its early days as well at that time.
And there was a Microsoft project which had, which had been retired by now called Draft. Um, and I went to conferences and started talking to people about, uh, you know, that idea of like, Hey, people should actually be building things on top of Kubernetes rather than with, you know, Docker Compose. And then later on, you know, Ops have to figure out about Kubernetes. And people are looking at me where kind of like, We don't know what you mean.
Kubernetes is a Ops thing. It's literally like that.
Rich: So you're yeah. So you're talking about like an, an engineer, like even their development environment,
Lukas: Yeah,
exactly. Yeah. I mean, you know, even things like Minikube, local clusters, kind, you know, uh, they've, they've brought that a lot more closer to, to the engineers. Docker Desktop integrating, uh, Kubernetes, having a one click button to spin up a local cluster. Um, all of these things are really great to actually, uh, you know, bring really Dev and Ops closer together.
Cuz I think, uh, Kubernetes, like in a way, Ducker made DevOps more of a reality. And then Kubernetes destroyed that a little bit again, unfortunately by, you know, Ops moving towards Kubernetes and Dev somehow being stuck at the Docker stage. Right. And not knowing, how do we transition this over at Kubernetes?
Is that image here, is that, you know, is that all we need, is that good enough? Is my application now distributed? Cuz I can package it in one image. It's kind of like, uh, you know, those challenges, I think that that was one of the problems I, I saw, you know, in 2017, 18 when we really started digging into the space for the first time.
I think that unawareness of that problem, that, that, that this will be a big problem, is definitely, or was a challenge. I think now, uh, a lot more companies are realizing that they need tooling around this. That they need to, uh, make sure that there's no like gap in terms of like tooling and delivery from Dev over to Ops and stuff like that.
Um, so there's definitely, yeah, a lot more awareness today than, than it was, you know, four years ago. So.
Rich: I only title the episodes using the person's name, but now I wish that I used like a clickbaity title, because I would call this one Kubernetes killed DevOps. I think that that would be super catchy. I would, I would get some, some traction on Hacker News, I think.
Lukas: Yeah, for sure.
Rich: But, but it is interesting that you bring that up because I do see people nowadays having a lot of the same discussions that people were having ten years ago.
Right. When everybody was like, we've gotta do something about this. And, and that's where, you know, DevOps initially came from.
Lukas: Yeah. I think, you know, as I said, I think Docker was actually a really good step in the right direction. And then, with that disconnect and a little bit of that, you know, uh, I guess rivalry in the beginning between, you know, is, is it gonna be Swarm or is it gonna be Kubernetes or is it gonna be Mesos?
I think that made things a little bit more complicated than, uh, yeah.
Then unfortunately, uh, it was in the very, very beginning where there was just literally Docker all over the place and then a few, maybe other smaller container solutions. Um, but I think ultimately we're on a good path now to solve that. I still think there will be no, I mean, there will never, especially when you talk about engineering and, you know, developers themselves rather than just operations, I think there will always be less standardization then there is in operations. Um, just look at like IDEs or look at programming languages, you know, everything is so opinionated, you know, people love their language and their framework and, uh, their IDE, right. They're never gonna move away from Vim, you know? And I think that's, uh, you know, I think that's a, that's just a thing that, that happens for, uh, engineering a lot more than for operations.
Um,
Rich: Well, that's
Lukas: and I think there is, uh, just a, there's just a plethora of like solutions, uh, and people love whatever they're picking. Um, but I think there will be more solutions in the space. Um, I definitely see a lot more attention, uh, going in that direction, uh, to kind of streamline things for developers, um, you know, driven by the organizations themselves because ultimately that productivity and also like developer happiness, um, is, is pretty important.
Mm-hmm
Rich: I saw Kelsey Hightower speak at this little meetup here in Portland, um, years ago. I mean, it had to be like, at least like probably four years ago at this point. And one of the things that he was talking about was, um, that he thought the interesting thing was not Kubernetes, but what people were gonna build on top of it.
Um, like what those sort of. , you know, PaaS platforms and things were gonna be that sit on top of Kubernetes. And it's been interesting to me because it, like, I think I expected that to happen faster than it has. It seems like we're still figuring a lot of that out. Although there definitely have been some strides with things like GitOps.
Lukas: No, for sure. Yeah. I think when we, um, after we launched DevSpace, uh, Fabian and I were. Uh, kind of thinking, you know, should we continue this services this business or do we wanna. Apparently there's a need for this, apparently people like this, right. Um, there's a need for this creating better developer experience on top of Kubernetes.
So we built, uh, DevSpace Cloud out of, you know, uh, the experiences of DevSpace and that was effectively a PaaS solution that was supposed to be like a Heroku, but for the Kubernetes era. Um,
Rich: Right.
Lukas: and yeah, although we had a couple thousand users on that platform, you know, I don't think any bigger company, uh, would've started using it.
And I think that is a matter of, um, You know, in a way like evolution of, compliance and restrictions and things that, IT has just been a lot more smarter about these things than they were at the times of Heroku. I feel like, you know, when, when Heroku, you know, Heroku had the same thing, like hobbyists started out and got excited and stuff like that. The difference
was people just brought it in their organizations and deployed stuff with it.
That's kinda the, the story of how Heroku ended up in, in large companies, right. Um, and I think today that just doesn't work anymore because like, as soon as you knock on the door and say like, yeah, can't we deploy this on, you know, this random tool that I've found, it's so much easier. Then IT's gonna say no, this has to go through GitOps and it has to go on AWS and we have these security constraints in place.
Right. I think there is a lot more guard rails, uh, today than there were, uh, back then. So ultimately DevSpace Cloud was something that failed. I think that Platform as a Service on top of Kubernetes is attractive, but in a way, people are afraid of that lock-in and of that not having the control that they have, if they have, you know, the direct way to, um, manage their own Kubernetes cluster on, you know, with EKS or any of the other providers. Uh, it's definitely a different, different mindset today.
Rich: Yeah. It seems like compliance has a big impact on that stuff too. Right. That, um, that audits and, you know, all of those requirements and, and that all evolves over time. Right. And those things are, you know, a response to incidents that have happened. And as time has gone on there's more and more incidents. So, so it makes sense that like, that, that compliance world would be of getting tougher and tougher as time goes by.
Lukas: Yeah, no, absolutely. Yeah. I think even, you know, if you are series A funded startup today where things are still a little crazy and wild. Um, a lot of them still have like SOC 2 compliance, right. And they are really careful of like picking their vendors and where they host things and who gets access to what.
And, uh, yeah, there's just not as much, um, I guess individual autonomy for, you know, a few developers just doing something random. I think people are more thoughtful and that's
actually a really good thing for, you know, end
users and storing data somewhere in a service. You know, actually, not saying this is a bad thing.
It's totally, it's totally actually, a actually necessary evolution that, that we are more mindful of. Like where do we host things and store things.
Rich: Yeah, I, I worked at a place, uh, in the 2000s that, um, that underwent PCI audits. And there was, there was one year where our auditor basically said, Hey, I'm gonna be really hard on you because there have been so many breaches, right? There's been all these breaches and it's been making the auditor, the companies doing the audits look really bad.
And so I'm gonna be probably a lot harder on you than any auditor that you've had before. And it was, it was really funny to see, that, you know, up till that point, it seemed like it really depended on who you drew as an auditor, some of were like, they would just basically sign off on whatever you told them.
And some of them would dig a lot deeper, but, but I expect that in general, they're, they're probably a lot more thorough nowadays.
Lukas: Yeah, definitely. Yeah. That sounds like a very interesting methodology. Uh, but, uh, yeah, I think, I think processes are in a way, a lot more streamlined as well. There's also a lot more expectation from, um, you know, uh, IT decision makers from buyers, uh, that you have to, you know, fit certain boxes and on that end, um, yeah, I think that that is a, is definitely development in the right direction.
Rich: You and I were on a live stream with, uh, Brett Stevens, a while back, who's a Docker captain and a pretty, pretty awesome guy. He teaches folks a lot about Docker and Kubernetes, and, and there were all these questions that were coming in that were about IT, you know, like, well, the IT department provisions a Kubernetes cluster for us.
And it just blew my mind because I'm so work, so used to working with like open source and startups and everything. And it just like didn't occur to me that people were like going to their IT department and putting it a ticket to like, get a Kubernetes cluster.
Lukas: Yeah, absolutely. Yeah, it was, was pretty interesting how the, uh, you know, conversation about vcluster turned into, how can you use that in a way that we can do shadow IT? You know, like how can we get Kubernetes without asking IT, with this it's actually great. um,
Rich: It was, that was pretty funny. I'll, I'll put a link to that stream in the show notes if, if folks wanna watch it. Um, so DevSpace is still around though. Um, it's still an open source tool. You didn't, um, DevSpace Cloud got discontinued, but, uh, the tool itself is around it's open source. Can you tell us just like on a high level, what DevSpace does.
Lukas: Yeah. Um, yeah, DevSpace is client only, uh, it's literally just a binary. You download it, put it in your path. You, I mean, obviously you can install it via brew or, you know, even npm install or, you know, just downloaded from the GitHub releases page, and then it streamlines your dev workflow with, uh, Kubernetes.
So effectively, um, you bundle all the information about a certain, you know, microservice or whatever you're building, this application, into a DevSpace YAML file, um, similar to a Compose file for Docker Compose. Um, and it's a declarative definition of, uh, you know, how a certain project should be deployed.
So it tells you, you know, it's like it has two, uh, images and there are two different Dockerfiles located in these folders. And this is how that should be built in, uh, then. This Helm chart should be deployed. And this config map as a separate manifest needs to be deployed. And you know, all of this logic is in a simple file.
And then beyond the simple, you know, build and deploy, it's also defining how do you develop this project. So how do you launch the debugger inside one of these containers? How do you, um, open a terminal to dive in? How do you start the container in a, a dev mode? Right. So you don't have to, um, so in DevSpace what we do a lot differently than other developer tools is we actually tell folks, skip image building, cuz that's the slow part.
Um, you know, when you're thinking about the classical development and Kubernetes is the process is like you build an image or you make a change, right. You build an image. Then, uh, you tag that image, you push that image to a registry, then you deploy something to Kubernetes that pulls that image again. Now you need a pull secret in Kubernetes so you can pull from that registry. There's a lot of complexity. And then you make another change. Well, guess what? You gotta gotta build another image, tag it with another tag. You know, it becomes really, uh, really complicated. What we do in, um, DevSpace is we tell you actually deploy your Helm chart with production images, or with stable images, you know, from your, uh, main branch.
Um, and then. Instead of, uh, building a new image, what we actually do is we swap out one of your containers. We patch that one pod so it runs a prebuilt dev image. So you have a dev image that is optimized for Python or for certain Java framework, et cetera, but it's always the same thing and you can use it across your organization.
And then, um, that container starts in dev mode. That means it doesn't really start the application. PID 1 is essentially sleep. It opens a terminal. So you can manually start the, the, you know, uh, start command. That means you can now pass different arguments, set different environment variables, and make changes to that one container.
But all the other 50 containers that you need are still running in prod mode. You can develop against them. There can be, you know, network interactions, everything happens inside the cluster. And then for the hot reloading part, we sync this local source code into the container so that you can even rebuild your application inside the running container.
Um, but in the end, everything runs inside of Kubernetes and you get this really realistic environment, just like you would have it in production.
Rich: Yeah. That's really interesting. So you're talking about like running multiple containers to like, you know, a bunch of different microservices that your service depends on or something like that.
Lukas: Yeah, exactly. I think the DevSpace really shines when it comes to microservices, because there's not just a way to spin up an individual application. What DevSpace YAML also allows you to do is define dependencies to other Git repositories or to other folders in the same repository. So whether it's a microservice that is in a monorepo, uh, with other microservices, or it is a microservice that depends on other Git repositories, DevSpace can create these links and then it can resolve dependencies. That means with a single command, you spin up your entire stack and that can be five microservices or 15 or 30. We have some customers that literally spin up, you know, depending on if you're hitting the right microservice in that dependency graph, you may actually have to spin up 20 other microservices to, you know, run the full, like end to end or integration tests.
Right. And that's what you wanna be capable of as an engineer, because the worst thing for engineers is really to have to change everything in Git, and then wait till your Jenkins runs for like 45 minutes to tell you, well, that one test fail, right? And then you
don't even get direct access to the, you know, container to be able to debug it. Here you can run that one integration test instead of having to run all 500, cuz you know what changed in the code. So you often know, Hey, I just need to run this test to be sure it didn't break anything here.
Obviously you should still run all your integration tests and everything later on when you put to, uh, when, when you committed to Git but having that, you know, certainty beforehand and being able to quickly iterate over things and making sure you don't break any tests and you know, everything is, is running as you expected, that is really, really helpful to improve software quality.
So when it comes to microservices DevSpace really shines.
Rich: That's really cool. So What do you, what do you see? So there's a lot of folks out there who still are using local dev environments. I think that, like, that was definitely more the model that I was used to being around. You know, I worked with a lot of Java engineers and they would, spin up their, their, you know, Java apps locally.
Um, uh, but that does get harder, when you're having to provision clusters and maintain those and all of that. So I, I've hearing more and more people talk about using, you know, some sort of remote development environments, whether that's in their cloud provider or, or somewhere else. What are you seeing?
Like in terms of, um, what people are doing there?
Lukas: Yeah, I think it's actually super interesting. There was the whole like cloud IDE space, uh, that was really popping up around, I think it was like 2016 or so when that market got hot and a lot of companies got funding. Codeenvy that later on got acquired by Red Hat and then Coding and Cloud Nine got acquired by AWS ultimately. None of them were a major success, to be honest. It was it, I think it was still too early for that wave. And today we see another wave of new cloud IDEs come in. And I think VS Code is obviously contributing a lot to making that, you know, happen, um, as a, as an IDE that makes it relatively easy to run in the browser and to, you know, have these workspaces on, and Kubernetes as something backing that actually lets you spin up a container where you can have your work environment inside of.
Um, I think that makes these things more pleasant and easier to work with. Um, and I think that is definitely accelerating things. Also that you can port things easier. Cloud IDE back then was very different from your local IDE. Today, if I have VS Code in the browser, versus if I have VS Code on my machine, It's almost identical.
You, you even sign in via GitHub in a lot of cases where it stores your preferences in a, uh, in a, I think it stores in a repo, in a personal repo, in a Gist or something like that. And, you know, that creates a lot of comfort for, uh, users and definitely accelerates adoption of these environments. But I still think, you know, we're still at like 90 plus percent, uh, of folks using local environments.
And I think the, you know, what we're doing with DevSpace is kind of like, um, independent of where your IDE runs, right? Because ultimately you still need to connect to a Kubernetes cluster. You still need to be able to stand things up, whether that cluster is Docker Desktop, and you're running your local, um, IDE, or if you're using your local VS Code to connect to a remote EKS cluster, or you're using Gitpod with, or, you know, GitHub Workspaces with a remote cluster, um, for DevSpace it's ultimately all the same. The only thing you actually need is a kube context. Right. That's the only required.
Rich: yeah.
Lukas: And I think that will probably be, uh, that will probably be around for, for a while. I think Kubernetes will just be more predominant, uh, when actually people are building applications in the future.
Rich: Yeah. So I definitely want to talk about multi-tenancy and Kubernetes, and that's something that I think of you as an expert on, um, it's something I talk about a lot as well in my job, because that's a big focus of the company. Um, can you kind of give us a, a high level view of like what some of the problems are with Kubernetes multi-tenancy.
Lukas: Yeah. I think in multi-tendency there is roughly, uh, you know, two scenarios. One is, um, you are hosting, uh, tenants from within your organization. You're hosting trusted tenants in the same environment. Um, so you have the same Kubernetes cluster and you have a hundred engineers or 50 teams that need to share them.
Right. Um, that's kind of this scenario. And then we have the other, multi-tenancy where it's about, um, untrust tenants, right? So you're essentially, um, you're hosting, uh, customers or you're hosting managed software that your customers get access to and they need to be isolated in a way. Um, and I think obviously there's, uh, you know, that is even a step further than that internal use case where you can trust a little more and it's mainly about preventing accidents, but even that is really, really challenging because a lot of things can go wrong.
You know, people can over-subscribe resources. Uh, if you, if have RBAC configured wrong, you know, things can get deleted or, um, you know, there can be, uh, collisions, you know, just think of like same ingress names and stuff like host, same hostnames, for example, right? In, in ingress, there can be a lot of things, uh, wrong when you're operating in the same cluster where you work on top of the same, you know, shared monitoring, logging, network, storage stack.
Um, just because that is kind of the benefit of Kubernetes, that you can share things, but then you gotta make sure you're drawing these lines and you're putting these guard rails in place between your tenants. And that isolation, um, is really challenging. And when you're doing that, uh, when you're really strictly isolating your tenants, you may actually hurt their capability to do things in Kubernetes, um, because they may not be able to access certain things, manage certain things.
And that is a huge problem as well. So that balance between being restrictive enough to ensure service availability versus being not too over restrictive so people can't do anything anymore. That's a really fine line in that scenario. Right.
Rich: Yeah. It's interesting. I feel like a lot of, um, a lot of what I think we talk about as a company and I think it's very important is, is, um, You know, self-service the ability to, you know, in the end, people just wanna do their jobs, right? Like, like they've just, you know, an engineer has gotten hired to write an application or a service or something and they just wanna do that.
Right. They don't wanna, you know, have to mess around with opening tickets up for other people to do things for them or, anything like that.
Lukas: Yeah, I think the most common complaint I hear from folks that start using our, uh, you know, vcluster project and then, uh, our commercial product Loft, um, is that the platform team, uh, is put in that situation, that they are responsible for uptime and are responsible for the stability and security of a cluster.
Um, That means they lock down, um, the tenants and then they suddenly now become responsible for managing a lot of things for these tenants because the tenants don't have the permissions anymore.
Exactly. And that's pretty much the worst case scenario for the platform team, because they're now responsible for even more than than they wanna be responsible for.
Right. They're not just responsible for Kubernetes. They're also responsible for all these different CRDs and central services. And, you know, there's so much they have to deal with that's actually application specific or rather, would be better managed by the application teams who are deeper into, you know, how that specific Kafka message queue should be in acting.
Right. Cause the platform team can't do it right for everyone in the company, especially when that company is large and you have these large multi-tenant clusters, it's really, really hard. And that's why we see a lot of these companies, especially when they, you know, are large, um, and have the financial means to do that, to just say like, well, we'll just spin up individual clusters instead, uh, rather than bother with, with multi-tenant clusters. In, um, that is a solution, but it's a really expensive solution, which obviously the company doesn't like either.
So they're really in a pickle, you know, no matter what decision they're choosing, uh, it always has a huge downside for them.
Rich: Yeah, it's interesting because I, um, I'm somebody who, um, you know, during my time working in operations, I worked a lot with engineers very closely, and I was one of those people that engineers would open up a ticket for and be like, Hey, I need you to like, do a thing for me so that my app works. And, and, you know, obviously the engineer would rather have the thing done immediately, right? Like they don't wanna have to wait around for several days for you to do the thing for them. But, uh, but like you said, it is extra responsibility for the people doing the operations stuff too. Like if you do have something that's higher priority that you're working on and you have to put off somebody's request for a few days, that doesn't feel good either.
Right. Like even if you're the person like who's, you know, prioritizing that request like that doesn't feel great. Um,
Lukas: No, absolutely. Yeah. It's a, it's a, it's a tough spot these platform teams, uh, are in, in, I think that, you know, it makes me really happy when we, you know, see when we see a customer who is running a POC and we kind of make that platform team the hero of the story, right. Because they suddenly enable engineers to do their work like 10x faster because they just have the freedom to do certain things. They themselves are a lot more happy because, you know, obviously they're doing a better job by creating that autonomy for, for engineers. But at the same time, they have less responsibility for these application specific things, can focus their attention more in the, you know, platform, specific things that matter.
And it's just so much better, uh, for, for both of these groups. And then at the same time, you know, the, the cost things that we are addressing by essentially allowing them to go that multi-tenant route versus going down the separate, uh, you know, spinning up a thousand EKS cluster route, you know, uh, that's obviously a great story to tell as well, you know, where even the CFO in the end is happy.
And, uh, that's, that's really great to see the platform engineers, uh, you know, uh, be in that central role that can actually deliver on this promise.
Rich: not only are they dealing with this kind of stuff, but they're on call and they, they, yeah, it's hard.
Lukas: Yeah,
Rich: Um, I do wanna talk, I do wanna talk about vcluster, um, because I love it. So it is, um, an open source tool that, uh, that was created, by Loft Labs. Um, so you and our CTO, Fabian, I think created it together.
Lukas: Yeah. I think Fabian, uh, obviously, uh, spent most of the coding, uh, on vcluster at that time. you know, I'm usually involved at this point, yeah. I don't get to code as much anymore. Unfortunately it sucks, but
Rich: you're you're you seem to be more kind of like the product
Lukas: Yeah. Yeah. I.
I.
Rich: more in that kind of
Lukas: Yeah, right now, I'm usually involved in like the specs and like, how should we, you know, structure a certain CRD, how should the syncer do certain things when we're, you know, syncing pod? You know, that's kind of, kind of the things I'm involved in. Um, and unfortunately I don't ever get to get my hands dirty with them coding on it, but, um, you know, I'm really, I'm super happy that that I have Fabian on the team who is actually 10x better at the coding part.
Totally
makes a
ton of
Rich: be, he may be literally a 10x engineer. Like I, I don't throw that around, but, uh, when, when I joined the company, it was literally like you and me and
him and a designer and, and he was just, uh, just cranking out so much code. It was amazing.
Lukas: It's pretty crazy.
Rich: about, yeah, let's talk about vcluster on a high level.
Lukas: Mm.
Rich: what, what does it do?
Lukas: Yeah, vcluster essentially solves the problem of, uh, multitenancy for Kubernetes, where you can, you kind of want everybody to have the full cluster, but then you need to lock them in somehow. So with vcluster you can essentially, um, create a namespace for a tenant. And then inside that namespace, launch a virtual cluster. And that virtual cluster is essentially a control plane that runs inside of a pod.
And then instead of talking to the underlying cluster's API server, the tenant now talks to that containerized API server. So through a service that can be exposed via an ingress or just via port forwarding, they're talking to this virtual cluster API server, and that's a regular Kubernetes API server. And that cluster is a regular Kubernetes cluster, right?
It behaves a hundred percent like a real cluster. It's a certified Kubernetes distro. Um, so you can do anything with it as you could with the real underlying EKS cluster. But the difference is pretty much everything you do is confined to that virtual cluster and doesn't ever reach the underlying EKS cluster. In a, in a nutshell, the only resource that really matters that the EKS cluster and the virtual cluster need agree on is what, what is a pod?
Because pods get synced from the virtual cluster to the underlying cluster so that the underlying EKS cluster or GKE or whatever it is right, is gonna launch that pod. So you don't have a performance hit, right? It runs if, if you were just running the pod directly on there, um, it would be the same impact.
The huge benefit of having the virtual cluster is all these other resources that you're creating. You can now have custom CRDs, a custom Kubernetes version. You can manipulate RBAC and network policies and all of these different things, deployments, StatefulSets, right? All of these higher level resources.
They only live in a virtual cluster's data store. In the easiest case that data store can be a SQLite database. If you're using k3s, uh, as the API server in your virtual cluster, but you can also use vanilla Kubernetes and a full blown etcd in a pod, right? Or in separate pods, um, to essentially, uh, host your virtual cluster.
But everything you're creating in there is confined in that data store. And you essentially, inside a single name space, in the underlying real cluster, where all your pods end up, including your, you know, virtual cluster control plane. Um, and that's really cool because inside the virtual cluster, you're complete admin, you can do whatever you want.
You can manipulate the cluster, you can see what runs in kube-system, right. You can have your own CoreDNS and, you know, install CRDs and everything, but in the underlying cluster, um, you don't have any permissions. The only permission that your virtual cluster really needs is creating pods, right. And ideally you also have admission control, etcetera, that prevents you from, you know, launching things like privileged pods and stuff like that.
Rich: right, right. So, so in essence, you have this big shared cluster and you've got a bunch of these, potentially tens, hundreds, thousands of these virtual clusters running inside of it. Like it's basically an API server and some other tools inside of a namespace.
Lukas: Exactly. Uh, I think the, um, the virtual cluster use case is kind of like, you could think about creating individual EKS or GKE clusters for your tenants. And instead you just have like one pretty stupid cluster that you can now scale up, and inside of the cluster, you're creating namespaces and launch virtual clusters, and that's a lot cheaper. Um, that means you can share things. So for example, when you're thinking a Prometheus stack or an Ingres controller or any of these services. You can now run them, you don't have to run them in each individual virtual cluster, right? If you have separate EKS clusters, you, you don't have a choice. You have to run them in each cluster, monitoring, logging, storage, backups, right?
All of that. There's a lot of replication, a lot of CPU and memory just for that base stack that you need in each cluster. When you're in a virtual cluster, you run at once inside the underlying host cluster, and then the virtual clusters can use these resources. So you can create an ingress inside a virtual cluster, and you have 50 virtual clusters and all of them use the same ingress controller that is managed by your central platform team.
That obviously makes operations a lot easier. Uh, especially at scale when you have a large number of these virtual clusters, and it makes it a lot more, uh, you know, costly, uh, cost efficient because you're essentially, you know, consolidating things into, into single instance or single underlying cluster.
Rich: you all had already invented this thing before I joined the company. So it wasn't open sourced yet. But, but you already had come up with this concept of like what a virtual cluster was and, and how it worked and had a working implementation. Um, so I'm curious, because I don't know that I've actually ever heard this story, like whole story of how this thing got invented.
Like, like how did you all get this idea and, and how did the early version of it like, get, get built?
Lukas: Yeah. I think it started with the experiences that we had from, uh, building DevSpace cloud. Um, you know, DevSpace cloud, was this, uh, namespace as a service product, right. So we were essentially, um, You know, renting out name spaces in a shared Kubernetes cluster. Um, so we had to have a lot of security constraints, everything in place.
And then there were people that are like, Hey, but I need two namespaces, and they need to communicate with each other and then we're like, dang, our network policy, we kind of need to you know, make exceptions to that. And like all of these things. Right. And
then obviously CRDs were not possible. Right. That's like user managed CRDs just don't work.
Cuz it's a global resource. It's not namespaced. So there's no way to give a user access from just what, within a single namespace, right. Cause that's all they've gotten DevSpace Cloud. Um, so we were thinking about solutions on that end and then we were literally like browsing GitHub and looking for alternatives.
Um, and then we saw, uh, Darren Shepard, uh, launched a project, about like two and a half years ago or so, um, that was called k3v, which is a k3s based, um, virtual cluster approach for Kubernetes. And it was like a, I think it was like a weekend project. He only worked on it for like two or three days and never touched it again.
And it was kind of like, this is how you could theoretically do this. Um, you know, host the k3s inside of a pod inside of a namespace inside of another cluster. Um, and then deploy workloads to that. And then we were like, cool. So he went like 1% of the way, how about we put some effort in and go the rest of the 99%?
And I think that's how that whole, uh, you know, journey around vcluster started. That was a really, really interesting project. Obviously vcluster today, um, is a lot, uh, different from that initial, uh, approach. Uh, and there was a lot of, lot of challenges to solve along the way.
Um, but that was, I think the initial spark where we were like, oh yeah, that may be possible.
Rich: I mean, it's interesting because Kubernetes is so complex. Like we're still like all the time people are opening up issues and they're like, oh, I'm trying to use this particular software and it's not working for whatever reason. Like, there's, there's so much to deal with, but it does seem like you all had done a lot of the work by the time I showed up in terms of like getting a usable initial version of it out there.
Um, yeah. That's interesting about Darren I'll, I'll definitely like link to his Twitter in the show notes. I know that he is like a fan of vcluster. Like, I think he's happy with how our, our sort of extension of the idea turned out.
Lukas: Oh, yeah, absolutely. I think after we launched vcluster he was pretty much the first person we reached out to. kind of like, Hey, you know, we took k3v to, to the next level. What do you think? Uh, and yeah, he was, he was pretty ecstatic about the work we've been doing. And since then we've been, you know, regularly catching up with him.
Um, he recently joined as an advisor in, in the company. Um, so I think he's, he's definitely rooting for, for vcluster and you know, likes to see, the spark that he gave us, uh, to unfold. Uh, now at a, at a larger
scale, it's definitely fun.
Rich: There's been a lot of excitement about that project and I'll definitely link to it in the show notes. You know, It is open source. Um, you know, people can use it, uh, play with it. I think it's really worth taking a look at, like, I know I'm a little biased because I work for the company, but , but I, I joined the company because I believed in what you all were building.
Right. You know, including this idea. Um, so yeah, so I'll, I'll definitely link to vcluster. Um, I also will link to the talk that you gave at KubeCon Los Angeles. So you did a talk about the future of multi-tenancy and these virtual clusters and, and all of that. And that goes into a lot more detail about how vcluster actually works if people are, are looking for more information, about that. I'm, I'm just curious, like what your experience speaking at KubeCon was like, how, how was that?
Lukas: So the first time I was supposed to speak at KubeCon was supposed to be 2020 in Amsterdam. Um, but unfortunately, you know, due to the pandemic. I was actually already in Europe I think, uh,
you know, started cancelled etcetera. And it was like, it was really frustrating cuz I was so excited, you know, to be speaking at KubeCon, I so looking forward, had so many meetings set up and stuff like that.
It was supposed to be a great trip. And then I landed in Europe and you know, it was like literally like every day, new news about things shutting down and everything got canceled. And I was actually kind of stuck in Europe for like four months or so, because it was so hard to, you know. I was supposed to, I had an apartment still back then, uh, in Germany I was supposed to kind of, Uh, get rid of that and, you know, move the furniture out, all that kind stuff.
But I couldn't even rent a rental, uh, you know, kind of land to move furniture, cuz like everything was like locked down in a way. So that was like a really crazy experience. Uh, yeah, I think the, the Amsterdam, uh, KubeCon Europe got, um, you know, turned into virtual and that was the most awkward experience ever because I literally gave a talk while just speaking 30 minutes into a camera with no feedback or audience, it was all prerecorded.
Rich: it's definitely, it's very different. It's very, very D.
Lukas: Yeah. It was super different. And I joined live for, you know, watching the talk and then Q&A afterwards on Slack I think. And then, yeah, that was just a pretty surreal experience. And then, uh, being, live on stage back with an audience in, in, uh, Los Angeles, um, For for KubeCon in 2021. Um, that was a lot of fun. Just having an audience, seeing reactions of people and being able to connect with folks after the talk.
There were so many people that had questions afterwards and, you know, so many more people that came to by the booth the, the next day, um, that was so much fun. And unfortunately, you know, obviously LA was a lot, um, you know, was still very restricted in terms of like, people couldn't travel to the United States and stuff like that.
I was
really
unfortunate.
Rich: weren't, that many people there
Lukas: Yeah,
Rich: certainly compared to San Diego, you know, before the pandemic, it
Lukas: Yeah. San Diego was so vibrant. LA felt so bad at some, some points in time in the exhibition hall. It was still, it was still a fun experience. I, you know, I like giving that talk and it was also great to, um, see that it was like, you know, live streamed and a lot more people were able to access it, um, and can still do that on, on YouTube.
Um, and I think
that's, that's super cool that CNCF is, you know, putting effort into, you know, making these events hybrid as well.
Rich: I think that hybrid model is the way to go. I really do. I'm somebody who like, I'm maybe more cautious about COVID than the average person, you know? And so, so there are parts, there are times when I get a little concerned about in-person events, but, but I feel like, we do need them, you know, and, I think it's great to like give people that option to attend remotely if they want to. We've seen that disabled people have benefited from it. You know, people who, are maybe students or earlier in the career and don't have the kind of money to, you know, to travel. Um, uh, you know, not everybody's employer covers their, their travel expenses to go to a big conference. And, and, um, that's even harder when you're in US and the Europe one happens, right.
Because all of that is even more expensive. So, so yeah, I think it's a, it's been a great, um, sort of middle ground to have that the hybrid events and I really hope they continue with that.
Lukas: Yeah, absolutely. Oh,
Rich: So based on like your experiences with Kubernetes, um, if you, uh, if you could speak to the Kubernetes gods and, and make a request of them, like, like what would you like to see change in Kubernetes itself? Yeah.
Lukas: that's really interesting. I think there's actually a lot of ask in the Kubernetes community around not changing too much anymore. Um, so I think the, when I look at myself, the, it is really a big problem when things change in Kubernetes, like even, uh, you know, I mean, certain, like we all remember that like, uh, ingress is obviously now in a, in a different API group, not better anymore.
Right. And that, those kind of changes. They seem small, but they're really massive, right? If you have an application like ours that is dependent on these things and, uh, has to consider all the different cases, and we have so many like version checks in, you know, like DevSpace and vcluster and those kind of, cause we obviously want them to be compatible with pretty much any Kubernetes version. Um, so yeah, my ask would probably be similar to a lot of other vendors don't change too much. It could break things
Rich: Code freeze forever.
Lukas: yeah. It's a dangerous thing. Right? Kubernetes is so big. It's so many things depend on it, but you also obviously want it to to on thriving, which requires to make changes. Right? It's a, it's a really difficult situation when a project becomes so fundamental.
Rich: Yeah. I think that you're, I think you're right though that, like, I don't think it's just the community, but I think that the maintainers and people too, that there's a, there's a pretty heavy bias against making breaking changes. And, and I think that's, that's the way it should be. And, and I think that when it comes to things like changing these really, really important tools that are part of a platform like that a lot of people are pretty hesitant to do that, you know? And so, um, not everybody is running the latest thing. Right. A
lot of them are a few versions behind, you know?
Lukas: No, that's very, very true. I think making that upgrade path as smooth as possible is really, really hard. Um, but it is something that is important for users because they are inherently afraid of upgrading, uh, because they don't wanna break anything and upgrading a large Kubernetes cluster with thousands of nodes and lots of workloads is a really scary thing to do. And especially when, you know, there are certain things, you know, when, when already, folks are calling it out in the release notes and blog posts are being written about certain migrations. It's like you're dreading that day when you're hitting that final, okay, let's do it now. I think we can do a little contribution with that with, with vcluster as well, because we are trying to make that underlying big cluster less important and that, you know, virtual cluster, more independent of it independently, upgradeable and stuff like that, and more lightweight and easy to touch and more ephemeral in a way.
Um, I think that is definitely something that can, you know, hopefully contribute to users being more, uh, you know, closer to the latest release closer to getting all their security patches in. Um, yeah. I, I definitely hope that can, can make a difference long term as well.
Rich: Yeah, for sure. Um, I think, you know, that I'm not someone who engages in a lot of startup founder worship, right. I'm not somebody who puts founders up on a pedestal, but, but, um, you know, I've really enjoyed working with you. And I think that you have a, a really interesting style of leadership. And I wondered if you kind of talk about what you've learned about like being a leader and, and
like what kind of values are important to you?
Lukas: Yeah. Being a leader always sounds so weird to me. Cause you know, literally I'm, I'm trying every day I'm figuring
things out. Right. it's
uh, I think that's the, that's
the
Rich: you're not supposed to say
Lukas: right.
Rich: out loud. I
I'll delete that. I'll edit that out.
Lukas: Yeah, I think the, uh, you know, that's a, that's a part of being a, a first time founder, right? I mean, I, I did run a company beforehand, but it's completely different, uh, from running a, you know, services based business where you, you, you know, do contractual work versus, uh, you're building this product, product strategy and venture-backed company, ultimately.
Um, it's definitely, it's definitely really interesting and being aware that it's okay to make mistakes. Um, and it's important to ask more experienced people for their opinions and for their advice. I think that's something, um, that is, yeah, that's definitely something that is very, very important to me. I think that was also, you know, it was actually a really big blessing to get you on the team with all your experience.
You know, you've been in big companies, you've been with startups, right. You've seen.
Uh, a bubble burst. Right. ,
you know, I appreciate all that, like, you know, insight that you, that you share with me when we have our one-on-ones right. And it's like, I, I think a lot of people that I'm hiring right now, you know, they've been with more employers and they've been, um, you know, burned in some ways and had good experiences in other ways in, I think, you know, being able to digest that and then find a way for kind of, as us as a team to build a culture that, you know, we, we wanna work in.
I think that is, that is probably the, um, yeah, that is the biggest kind of task for me to, to, to work on while building this
company, aside from the, you know, classical, you know, product development and sales and marketing, uh, stuff that I'm doing. Cuz I think that cultural part is
really, really important.
I
Rich: Yeah. One of the things I always tell people about you is that you're, you're not the, the stereotypical tech founder, right? Um, yeah. Um, what do you, What do you think about the Kubernetes community itself? What, what's your feeling about like it right now? Like, uh, I guess what, what
do you think about the health of it?
Lukas: think the Kubernetes community is still, I mean, growing we're definitely
still not at the point where, you know, I would say, Hey, this is, this is getting, you know, annoying and people are moving onto the next thing. Right. it's kinda, I don't think we're there yet. There's still so much innovation happening and, and so much.
Uh, to like conquer all of these problems, um, that I'm, I'm still really bullish and excited about, uh, about Kubernetes and, and the community. Um, I think what is really good about the Kubernetes community is that things are being so actively discussed. Whenever there's something that may be an issue.
Right. Um, you know, recently that was that discourse on, on, on Twitter about that conference that had like only male speakers. And then there was a lot of criticism and then literally over the weekend, they pulled together another lineup and they fixed things and they were really responsive to that, you know?
And I think all these things are super, they make me really happy to see that, right. Because like the community has a voice, people are raising their voice and, you know, issues are being addressed. I mean, obviously, you know, for some. Not everything can be handled in a perfect way, right. There are always gonna be things that go wrong, but I can definitely see in the Kubernetes community that there is more open discussion than, than there is in other, in other spheres.
For sure.
Rich: yeah. Totally. And yeah, I think that was like the
Kubernetes community days in Berlin is what you're referring
Lukas: Right. I think that
Rich: and yeah. And yeah, I have to say I was, I was super impressed by the way that they responded to that. The, for those who maybe like missed the story, you know, basically they put out this kind of all male speaker lineup.
And of course, a lot of people were like, Hey, you know, what is up with having an all male speaker lineup in 2022? Right. Aren't we,
or we passed this, you know, and, and,
um, they really took that to heart, you know, and instead of like getting defensive, they were like, Hey, you're right, let's fix this.
And they went and, and, you know, got some more speakers, from some different backgrounds to, to join the conference. And, and I think that, like, it's really tempting for people to look at those things as like a criticism or an attack or something like that and get defensive, you know?
Um, so it was really, it was really awesome to see somebody take that as like a learning experience. Right. As opposed to, as opposed to something negative.
Lukas: Yeah, absolutely.
Rich: Um, alright. I think that's, uh, all the time that we have today. Um, it's been super fun to have you on Lukas. Um, usually I ask people if they have something to plug, but, um, I know what you have to plug. So, uh, so, uh, I mentioned your talk that you did at KubeCon. You're gonna be doing that talk again. We're doing a meetup, um, down in San Francisco on July 26th.
Um, we're also gonna have a talk from, um, Mike from Adobe. Um, who's gonna be talking about vcluster, um, and, um, some other announcements and stuff. So it's gonna be a lot of fun if you're in the Bay Area and you are free, uh, July 26th. Um, I'm gonna be down there as well, so I'm, I'm flying down and, um, it's gonna be a lot of fun.
So if you wanna meet me or meet Lukas and, and hang out and chat about Kubernetes, I will put a link in the show notes to the Meetup page where you can sign up for that. um, and of course I'll link to your Twitter. Um, is there anything
else besides that stuff that you
Lukas: No, I think that's, uh, that's pretty much it. I think I'm really excited for that event as well. Uh, and then there are a lot more, you know, fun things to come out, uh, in that time as well. Uh, so, you know, watch out for what's happening around DevSpace and vcluster, there's a lot more, uh, to come in the next couple months, uh, you know, with, without wanting to spoil a lot here.
Uh, there's definitely gonna be some news in the, in the next few months, so yeah, definitely, you know, follow @loft_sh on Twitter and, uh, make sure, you know, uh, you, you see the latest news around vcluster and DevSpace and yeah. If someone is around for, for the meetup, um, that's gonna be a lot of fun in person.
Uh, and I'm really excited. I think we're gonna stream this, uh, live as well, um, on, you know,
YouTube and Twitch and stuff like that. So for folks who are not in the Bay Area, you know, uh, still subscribe to the, to the event, um, and will share the, the links, um, on, on Meetup.com.
Rich: Oh, that's great. So I'll, I'll definitely pass along that, that page and yeah, do, um, I'll put a link in the show notes to the Loft account, the Loft Twitter account, uh, following me on Twitter is a good way to stay up to date with what's happening with the company too. Um,
Lukas: Yeah, thank you so much. Rich.
Rich: Kube Cuddle is created and hosted by me, Rich Burroughs. If you enjoyed the podcast, please consider telling a friend. It helps a lot. Big thanks to Emily Griffin who designed the logo. You can find her at daybrighten.com. And thanks to Monplaisir for our music. You can find more of his work at loyaltyfreakmusic.com Thanks a lot for listening.