 Thanks for joining us. Can you give a brief introduction of yourself? Yes, so I'm Joe Beda. I'm a principal engineer at VMware now, but we just joined VMware through the startup and acquisition of our startup, Heptio. We were in business. We joined about three months ago, so really been integrating for about two months. And then Heptio was in business for about two years, Craig McLucky and I with the mission of bringing Kubernetes to enterprises. Awesome. Yeah, you're one of the creators of Kubernetes. Can you give us some background on how Kubernetes came to be? Yeah, it's, you know, the real story is that, you know, there were a set of us that just wanted to be able to hack on some stuff and not have to go through all the process of shipping stuff at Google. But there was a lot of other thinking behind it also. At the time there was, we at least released GCE, but then internally Google had a bunch of systems based on Borg and there was a real question of how do we start bringing these things together. And so it was really either we take all of Googlers and try and get them to start working with raw VMs, which would have felt like a huge step backwards, or we have to take the Borg model forward. And so then it was just a matter of how exactly do we get these ideas out into the world. And open source, you know, you play a different game when you're the underdog, and really it was more important for us to sort of reset the playing field between clouds. And so Kubernetes became a way for us to start doing that. Awesome. Did you ever expect that Kubernetes would transform the industry like it did and like become the default for cloud native? You know, I don't think any of us expected that it would be what it is today. You know, when you start something like that, you have a sense that, hey, this could be something that other people find interesting, but you know, we don't have, you know, it's hard as humans to understand the scale of these things once they take off. It goes from being something that you can feel to just, you know, numbers in terms of number of deployments who's actually using it. It's still impressive to me when it'll be like at KubeCon or something and it'll be, you know, some company in Brazil that I've never heard of will come up and say, hey, we've like re-platformed everything on Kubernetes and it's working great for us. I'm always waiting for somebody to say, hey, we started using Kubernetes and it's horrible. I'm sure there are stories out there, but we haven't heard, nobody's actually said that to me. So, so far, it's been really great to hear all the stories of everybody using it from all over the place. Yeah, it's amazing. And it's still accelerating. I heard that like the attendees of the next KubeCon, it was, it's going to be double the number than they anticipated. There's still so much interest and new people flowing into it. Even now that Kubernetes is maturing, everything, it's building a foundation for everything else to be built on top of that. And that's, I mean, that's one of the things that we really wanted to do on multiple levels was really build something that could be built upon. Both in a technical sense, but also, you know, we very much had the idea from the start that we wanted to build a community. We wanted to enable other people to own it, to be part of it, to really feel like they were instrumental in making it happen. And that's what happened. I mean, so it's easy for us to say, hey, you know, look at how successful it is. But the reality is, is that, you know, there are so many people that put so much time, so much effort, so much, you know, blood and sweat into it to really get it to where it is. And so it's really a product of the community then of any, you know, single group of people. Yeah. For GitLab, Kubernetes came just in time. Like we were looking forward to doing operations with GitLab. And if it wasn't for Kubernetes, we'd have to support very many standards. But it's, at that time, everyone was super excited about Kubernetes. And all those APIs were there to do incremental rollouts and all those things that are very difficult to orchestrate otherwise. What do you think, are those APIs meant to be used by humans? Or are they meant to offer a platform for people to build additional tooling on? Very much the second one. I mean, we really wanted Kubernetes to be something that really sat in the middle. Because we knew, I mean, there was this feeling that there was this middle layer that could be relatively widely used and applicable. But we also had this feeling that there were going to be sort of flavors of experiences that could be built on top of it. And so something like GitLab that's very much focused on more traditional type of applications is one thing. But then you look at something like, say, Kubeflow for doing machine learning also can build on top of this base. And I think with the fullness of time, we're going to see, you know, big data also start to really find a home on top of Kubernetes as we continue to improve the capabilities. And so, yeah, so very much. And in terms of being used by humans, I'm horrified that people are still editing YAML by hand. Yes. Thank you. The idea there was, let's do something very verbose, machine readable, so that at least there is sort of like that base layer with the idea that tooling and that the community would find something that they could agree upon that would sit on top of that. I think one of the things we didn't foresee is the fact that there's, it's very difficult to find something that everybody can agree upon for actually that higher level abstraction, which I think speaks to the fact that the set of problems that people are trying to solve, how they're approaching these things is really fractal. And there is no one size fits all solution for a lot of the things that work on top of Kubernetes. Yeah, what do you think the holes are in Cloud Native today? We're still, where should we still do work? You name one thing. Is that something that's top of mind? Are there other things? Well, yeah, I do think that with respect to 80 or 90% of what developers need to do around sort of deploying applications, I think we can find sort of a common ground there. And I think it starts looking like a decomposed or an exploded platform as a service type of thing. And so I look at projects like K-Native and I think that they're starting to make a down payment on building that tool set for building those higher level experiences on top of Kubernetes. And I think one of the key learnings from looking at more traditional platforms as a service is that those things are great until they're not. And so with a well factored layered platform, which I think as a community we're starting to build, once you hit one of those walls, you can degrade gracefully. You can actually use lower levels without having to sort of throw it all away and start from scratch. Yeah, I think that's something that we aspire to. And we call it graduate gracefully. When you graduate, when your app becomes super popular and you have to customize more things, you don't have to leave it. You can just start customizing more and more things that you took the default off beforehand. And thanks for K-Native. It's- Well, I'm not involving K-Native heavily. I am a fan of where those folks are going though. Yeah, and I think one of the things that came from the Kubernetes authors was making sure K-Native worked not just with its own build process, but you could also point it to a Docker container. And the K-Native server and the K-Native build process are separated. And that's really a boon because GitHub has its own build system. With K-Native, we're using for deploying serverless. And we're going to use it for deploying pass applications. So making that split a bit more composable or a bit more flexible. That was a great thing that I think the Kubernetes offers to help with. Yeah, I think we really wanted to bring this sort of the Unix philosophy to this world where there were smaller components that you could wrap your head around and these things compose into a larger experience. And so there's pluses and minuses to that. I mean, there's a reason why Windows is so successful. It's this well integrated, well tested, happy path type of thing. But I think that as we look at all of the sort of environments that something like Linux has found its way into everything from a phone to a main frame, that sort of componentized view has served it well as we've seen it spread to all these different environments. And I hope that Kubernetes can be as adaptable as that over time. Yeah, it certainly feels like the OS for the data center. We're here at the open source leadership summit. What are your thoughts on the state of open source today? I think it's a turbulent time. I think open source is evolving and it has been. It's never been something that's set still. One of the lessons from Kubernetes more than anything else is that open source today is about community and as much if not more than code. I think if you look at say something that's like the typical open source library or Linux itself, the kernel, that's generally not something that's usable in and of itself. And so you end up with companies building distributions, which means that they take this raw technology and they figure out how to make it usable. What we find though is that with most open source projects today, there is an expectation that the project will be usable out the gate. Whether that be a database or node or NPM or Kubernetes. And so the line between project and product is really starting to blur as open source projects start to compete with each other and compete in the marketplace and become much more user centric versus just code centric and the community ends up being a really, really big part of that. Figuring out how to fund that, figuring out how to motivate it, figuring out the business models around it. I think there's still a lot of experimentation, a lot of interesting work and thinking and experimentation to be done yet. What open source projects are you excited about today, things you see coming up? I mean, I think I'm still blown away with just the diversity of the projects that are building on top of Kubernetes. I mean, our idea was that, hey, once you have this basis, you can do all sorts of interesting things with it. It's difficult for me to identify any sort of single projects. I think I look at some of the stuff that's going on around how we think about build pipelines and decomposing a lot of the CICD space and something going from sort of the traditional type of like, hey, it's one single big system to can we break this apart and find fault lines and sub-components? I think it's interesting to see that evolve and so I think that's an interesting space. Every Friday, me or Chris Nova do a TGI Kubernetes. It's a YouTube live stream where we play with new projects and find things that people are doing and get hands on with it. And so I really do enjoy just opening up the box and playing with the new technology and understanding how it works. And there's always something new, which is super exciting. Cool. What do you think of the development of non-compete licenses? Open Source projects that say, look, you can use this for free. But please don't compete with the SaaS service we're offering. I think that that is, it's a tricky thing. One of the things that I think makes open source communities healthy is to be very explicit about your motivations, what your business is. And I think one of the tricky things as we look at these types of licenses is that to some degree if you do this with a mature project, you're essentially rewriting the contract with your community, right? People invest more than just code when they get involved in open source projects. And if you change the rules midstream, it can very much feel like a betrayal. And so I think I understand why people are doing this, but I think there's actually a difference when you do it with a mature project versus when you do it from the get go. Where if that license is already there when the project starts, then everybody knows where you stand. But I think this transition of doing it after you have a mature project, I understand why people do it. But I think it's very much tricky waters to navigate. Yeah, I think what you're referring to is that for to contribute to some open source projects, you need to sign a contributor license agreement. And that transfers the copyright to the company and the company can later on change the license of the code. And it's something that, for example, the Debian project already was seen. So when Debian started to use GitLab, they said, hey, we're not gonna accept. Or we're not gonna, they were much more kind about it. They said, we're uncomfortable with that. So we can't accept it, but would you consider changing it? And we change it for GitLab in a statement that, hey, you keep your copyright, which is allowed to be licensed under the current license. So it's not possible for GitLab or would be very inconvenient for GitLab to now change the license on the open source project. We'd have to go to all those offers and either get their permission or replace their code. And I think that might be something that becomes more prevalent in the industry. So that the rules can be changed down the road. Yeah, I think that was one of the reasons why when we did picked how we were gonna deal with contributions to HEPTIO open source projects, we picked a DCO. With something, I'm not a lawyer, so we can all play armchair lawyer on this stuff, but I think with Apache too, I mean, what's out there is out there, which is the license that the bulk of our stuff is under, but it's really about sort of what about forward looking new contributions to the code base. And so it's something to consider, I think. But again, it's like there's the code and the license for the code and then there's the community that builds around it. And even if it's not a legal contract, I think there's a social contract between the leaders of an open source project and the people who are members of that community. And I think you have to be very respectful of that social contract. I agree. And at Good Lab, we have our stewardship promises. And we only added one so far. And we intend to stick by those nine promises to the community. What do you think of the initiative of Amazon to fork and commoditize Elasticsearch? Man, there are two very legitimate sides to this. On the one hand, it's open source. And part of open source is you are giving something away. I mean, and it's a very real sort of letting go. The second thing is that Amazon is adding real features that benefit real users. At the end of the day, people want security for Elasticsearch, right? And that was something that wasn't available in the open source version of Elasticsearch. On the other hand, we do need to find sustainable business models so that people continue to invest in these things. And for, I mean, my advice to anybody who is building a company around open source is to understand sort of where are your levers, where is the value that you're adding and try and be creative about finding ways to add value where something like this can't happen. I feel, I understand sort of the motivations on both sides of this. It's very hard to say that, hey, there's a right or the wrong on either side here. Totally agree. Kubernetes has become very popular and it seems that there's some almost defaults developing on top of Kubernetes. Using Envoy for the data plane, using Prometheus for the metrics. Do you see that too? Do you think those will become defaults or do you think it will always be a heterogeneous thing on top? I think it'll be heterogeneous, right? You can use Linux without sort of G-Lib C, right? But two great tastes that taste great together. I think we look at the Linux community. There is a symbiosis happening between sort of system D and the kernel. And I think that that's something that gives a lot of people pause, right? And so as we see Kubernetes develop, we may find that there are components that are just so part and parcel that they might as well be included as part of the kernel. I'm not sure that we're actually there yet. There's a lot of folks that use Kubernetes without Prometheus. There's a lot of folks that do Ingress without Envoy. In fact, I would probably guess that the NGINX Ingress is probably the most popular Ingress out there. So I don't think we're there yet. But I think this is part of the excitement is that there is a really vibrant set of projects that are experimenting trying things out. And it's gonna be the users who decide what's successful here. What do you think GitLab should do better? You know, I, oh, man, I think... Is that long of a list? No, I'm not sure. I mean, like, you know, part of the, you know, as I start my career as, you know, and develop, I think one of the sort of, you know, technologist diseases is thinking that you have to have an opinion on everything. And personally, freeing myself from having to have an opinion on everything is actually, so I really don't have an opinion. I mean, I think, you know, you have, you know, an intimate relationship with your customers. You're listening to them. I mean, that much is very, very clear. And so it's, you know, I don't think I have enough data to really, to really sort of speak to it. I'm not sure one of GitLab's values is to have an opinion on everything, but we do like strong opinions, weakly held. So we'd like to change our opinion in the face of new data. Is there something else you'd like to talk about? Oh, well, you know, I think it's worthwhile to talk about our motivations for Heptio joining VMware. You know, Heptio's point of view is that we really see ourselves as a cloud independent ally for enterprises as they look to adopt Kubernetes. And I think that as we start to see, you know, these, you know, enterprises start to adopt cloud, understanding the power dynamics and the relationship with cloud, I think that there's a lot of concern about, you know, how do I get some independent advice, independent thought, independent support that's going to actually stay with me as I, you know, figure out where my position lands as I move from on-prem to cloud and beyond. And that was a big part of Heptio's value proposition to companies. And so, you know, when we look around the industry, I think VMware is in a unique position to continue that. You know, I'm continually impressed with VMware's connection to their customers understanding the needs of enterprise IT and then also being really thoughtful, you know, about how do we partner with those folks as they go through their cloud journey. And I'm really excited about Heptio being a part of that and then understanding how VMware can, you know, use Kubernetes as they continue to help customers on that journey. So, Heptio, I think, was one of the first ones that had, like, a free Kubernetes distribution that came with all the upgrades and everything bundled. Is that the case now? Is that the case going forward then? Actually, you know, our take on it, and this goes back to what we talked about earlier around open-source projects and products are actually starting to blur lines. You know, we have invested and we continue to invest in parts of the Kubernetes project, which traditionally would be part of a distribution. So, you know, Tim St. Clair, who works for us, is the SIG chair and does a lot of work around SIG cluster lifecycle, which is essentially the upstream install in cluster lifecycle and management. A lot of the tools that you'll often find in a distribution, we're working to implement those things upstream. And so, one of the things that we wanted to do with Heptio was not to have our own distribution, but instead make Kubernetes be the distribution. And so, it was an interesting path for us to take because to some degree, like, it's like, well, what is the unique IP that Heptio is bringing? With respect to the core Kubernetes stuff, the answer is, like, we don't want, we want to democratize this because if Kubernetes is everywhere, if it's available, then there's this higher level platform that everybody can benefit from. And I think we at GitLab encountered the same thing when we sold consultancy to install and upgrade GitLab. We took those lessons, put them in the documentation, put them in the installer, and people didn't need our consultancy anymore. So, you kind of, if you hope for that to be your business as you start contributing back, you kind of strangle that business. And I think one of the interesting things is that the most valuable software company, enterprise software company ever sold, was Red Hat, which was pretty fanatic about never having any IP if they bought a company with unique IP, they would open source that. So, there is a business to be built on that and it was super great to see that VMware recognized like the value of haptio and acquired you guys at a considerable price. No comment on that one. But yeah, no, it's been a great journey joining VMware, really have enjoyed meeting everybody around the company. And I think that there is a, there's a real sort of desire within VMware to evolve the business, move forward, and adapt to the new world that we're all living in. Yeah, and I think VMware embracing AWS and Azure and building the VMware services on top of the clouds is live and prove of that. Exactly. Thank you so much for this interview. All right, well thank you.