 So we are here at KubeCon and Cloud Native Con and we have with us today Tim Hopkins from Kubernetes. So tell us, you know, first of all, okay, this is just a funny thing. What are you doing at KubeCon? What am I doing at KubeCon? I'm here to talk to people. You know, a big part of what I do in the community is work with developers and people who have ideas and people who have needs, users, and try to find ways to solve those needs. This is a great meeting point where everybody comes together where I can actually meet face-to-face with people, which is infinitely higher bandwidth than GitHub, and talk through problems and get details about what sort of issues they're facing, what their use cases are, and try to help, you know, ideate and come up with some solutions for them. And also to meet with developers and just say hi, thanks for all the work you're doing and, you know, socialize and build sort of team conradery because what we have is a worldwide team of thousands of people, which is sort of amazing. But you're involved with Kubernetes also of different levels, so can you just talk about that? I mean, I've been involved with Kubernetes sort of from the beginning. When we first had the idea to do Kubernetes in around 2013, I was working in Google's infrastructure teams and working on Borg, and we had this idea of like Borg for everyone else. Wouldn't it be neat if we could make a Borg product, but we didn't really know how to do it because the technology really wasn't there in the upstream kernels and weren't sure people were ready for it, we were going to adopt it, people were very into their VMs, which is something we just skipped over in Google, we never did VMs. But the more we talked about it, the more sort of passionate we got about this idea, we started writing some product ideas for it, and then Docker happened. And Docker took this idea of containers and it just planted a seed that really took root and lots of people all over the world started talking about Docker this and Docker that, and we said, how can we use this, right? How can we leverage this into taking the ideas that we want to push even further? And so some of the folks at Google and Google Cloud did a prototype of this thing that eventually became Kubernetes, and they took these ideas and they slapped it together and they put together a demo, and we said, that's it, that demo's amazing, let's do that. So we got some permission to work on it, a few people, very small, like four people, we worked on it for a few months, the team grew a little bit, but not very much. And then we sort of announced it at DockerCon, the same day Docker announced their 1.0 release, and the response was sort of overwhelming, people immediately they got it, they wanted to be part of this, they knew what it was doing, and we got involvement from folks like Red Hat and other community people, and it just took off from there. It's been on a rocket ship ride ever since. When you look at open source word, things come up as an alternative to something that exists, but Kubernetes, the case was sort of different, there was nothing that existed. At the same time, enterprises are kind of hesitant in adopting these kind of technologies, so what magic happened with Kubernetes that suddenly everybody is behind it? It's like only less than four years or whatever. Yes, it's true, and it's something we were very concerned about at the beginning of Kubernetes, who are we targeting, what were the use cases we were willing to try to tackle, and how did we think we could get adoption? So one of the big important strategic things that we did was we didn't start with a big drop of code from Google, right? Let's open source Borg. Well, that's millions of lines of code that nobody would be able to decipher that really wouldn't be useful, and I don't think it would have gotten an uptake. We had a lot of arguments about what language should we write this in, should it be C++ or should it be Java, should it be Go. We decided that Go had a really nice community around it, had really nice tools, libraries, and most importantly, Docker had been written in Go, so there was a community in this space already. We'd like to tap into that, and that all talks a little bit to how developers approach it, but how do you get into enterprises? Well, you don't at first, right? The first few group workloads that we targeted were stateless. They were web servers. They were startups. We did a lot of touring around Silicon Valley, talking to startups about how communities could maybe make their lives easier. And there was a lot of reluctance at first, for sure. People, you know, they don't want to bet on a new horse. They don't want to get in. They don't want to be the first consumer. And I think what was really a huge leg up for us was some very early adopters like Box, Sam Goads from Box, came to one of our really early meetings, and he took a look at what we had done, and he said, you guys are crazy, but I want in. And he stepped up, and he helped us rewrite our command line tool and really said, Box is in. Like, we're committed to making this work. And they've been a great partner ever since. And as sort of a high tech forward enterprise, they've been an awesome example of things you can do with Kubernetes. And then from there, it becomes a snowball, right? Little enterprises, and then sort of more technology-focused media companies, especially web-centric sorts of things. And then before you know it, you're talking to banks. And last year, even Docker, they adopted along with Swarm. So that's impressive. And for this Docker, when Docker 1.0 came out, then you announced Kubernetes. And Docker 2.0 came out. And the highlight is that it supports Kubernetes. Kind of, yeah. That's kind of a cycle, isn't it? When you look at all this massive adoption, Open Stack Committee went through that. They saw the use cases. So they kind of narrowed their focus. They learned from their mistakes. So what has Kubernetes, because your use cases are also just all over the places. So what are you doing to ensure that? So we talk regularly with Open Stack people. In fact, we do this every KubeCon. We sit down with Open Stack veterans. And we have a sort of War Stories session, where we just trade experiences. War Stories? Yeah. So we have this War Stories session, where we meet with some of the Open Stack veterans. And we talk about the things that went right and things that went wrong in Open Stack. We talk about problems that Kubernetes is facing. We talk about the technology that they built around Open Stack to make continuous builds and those sorts of things. Successful, we talk about how you manage plug-ins and how you manage APIs and how you manage vendor relationships and those sorts of things. They've been really insightful, really helpful. A lot of people compare Kubernetes to Open Stack, sort of the same rocket ship adoption, the same media frenzy around it. And we want to be careful, because there's some things that we think went wrong with Open Stack. So one of the things we're doing is we're focusing really aggressively on extension points and making sure that the extension points are not go replace this whole subsystem, but you can tie into those lifecycle moments when you need to do things. And making them possible for vendors to go off and do the vendor-y thing that they want to do, but also encouraging community participation and encouraging open source, but not necessarily demanding it and not putting ourselves in the way of every change that a vendor wants to make. Another place is we really are aggressively focused on setting the limits for what the system is. We call them swim lanes. We're going to stay in our lane. This is all we're going to do. We're not going to do things outside the box. And over time, in truth, the swim lanes will change a little bit, but so far, we're four years into it, and we're pretty on track with where we set out the swim lanes at the beginning. Yeah, it's more like, no, it's also about what we will not do or what we cannot do. It's really important that we leave room for the ecosystem to thrive, for companies to grow and make businesses on the back of Kubernetes, because when they're successful, we're successful. But it's also important that we provide a consistency of experience and some guarantees of portability that are actually meaningful. Users really, really should be able to take their workload from their on-premises cluster and run it on their Google Cloud cluster and have it just work. Because also, when new use cases come with, that's what happened with OpenStack. Everybody was doing everything, and they lost track of it. So that's good. OpenStack, I think, tried to be too much to too many people. Because there's so many use cases were coming on, they did not even know where to go. So they're like, oh, let's do that. Let's do that. And it's only it was. And to be fair, it's challenging. And that's actually good because they did not have a play book to follow. So they have to make mistakes and learn. The good thing is that they learned from the mistakes and they're evolving. Yes. We're now facing use cases as we get bigger and more adoption. We're facing use cases that OpenStack solved and that Kubernetes doesn't have an answer for you. And people are coming in saying, well, OpenStack solved it this way. Can we solve it in a similar pattern? Or do we need to solve it in a different way? What's the cloud-native way of doing this? And the sort of Kubernetes style instead of infrastructure style. And some of these are really hard discussions. Because sometimes it's a good idea, but I don't know the answer to the solution. And sometimes I don't know that it's a good idea. And so we have these discussions. It's always case by case. And we try to keep it very technically focused and very user-oriented. We really want Kubernetes to be an application system, not an infrastructure system. At the same time, as I said, there are lanes. But at the same time, you also want to leave the room for further evolution of the project. Absolutely. We're tool smiths. We can't tell people what they use the tool for. What are the new use cases that either you're excited about or worried about? I mean, to stay on topic with the OpenStack question, like the topic of NFV, network virtualization, is a really challenging topic. There's a lot of people out there who have built solutions around the idea of NFV and a lot of enterprises who are building their security policies or their infrastructure stacks around how NFV works. Kubernetes doesn't have an NFV model. It has a very flat network model. So we're having a lot of discussion for quite a long time about should we adopt a multi-network model? Should we model it as networks? Should we model it as resources? Should we model it statically or dynamically? Well, how does hardware fit into this? How does virtual software fit into this? It's a very challenging topic where, basically, for every feature intersection, there's somebody who wants that. And we're trying to limit the scope and figure out should we do this, how should we do this, and how deeply should we do this. Right. When you say that these discussions happen, the Kubernetes is hosted by CNCF, which is part of Linux Foundation. And you have different governing models. Anybody can become platinum or gold member. So the decision about the code, where does it happen at the top tier or near where developers work? Much near developers. There's no influence from CNCF on the Kubernetes technical process. So no company can just become a CNCF member and buy influence? You can't buy a seat. No. You can buy a seat on the CNCF board, and that will help CNCF decide. I'm not saying you can buy a seat on the CNCF board. You buy a membership to CNCF. But you can help the CNCF decide which project it wants to govern and how CNCF will run. But it's very explicit in the charter that CNCF has no technical influence over Kubernetes. And what Kubernetes has is our own steering committee, which was bootstrapped by myself and others who've been around the project for a very long time, but is also augmented by a bunch of people who were elected, literally elected by the community. And we set forth rules for who's allowed to vote and how the voting would work. We advertised it like crazy. We had great turnout. And we had a bunch of people elected. And so now we have a group of 13 of us who meet on a regular basis. And we work through retooling and redefining and clarifying how the community's governance works and how the delegation of responsibility works. And so, for example, delegation of technical authority is granted to our SIG architecture. And SIG architecture is run by a small number of people who have very deep focus on the background. But it's an open group where we have recorded meetings. And anybody who has technical issues, they bring to SIG architecture. You want to create a new subsystem, you bring it to SIG architecture, and you talk about it. You want to change the API? You go to SIG architecture. Right. And also, I think CNC also decides where to have these events, what kind of... So it's totally different. Because sometimes there is confusion. People believe that, oh, somebody can buy and influence the company, but that's not how open source work either way. The only way open source work is like, if you want to influence, give more contributors. Give more developers. We have this conversation with, especially companies all the time, who come in and they see communities and they say, how can we get our changes adopted more quickly? And it's the wrong question to ask. The right question to ask is, how can we be part of the community more? How do we earn cred? How do we chop wood and carry water so that people know who we are so that when we propose features, people say, oh, that's an idea that's worth considering. When I started my journalism career back in 2005 and I was covering open source from early on, one of the challenges was to tell companies why you should use open source, what are the benefits. Today, everybody's using open source. But the reason I was asking is that, but today, all these companies who use open source don't know how open source works. So do you come across this problem? I mean, you gave an example, so what's your message to those? Well, it's important to differentiate between people who are going to consume the product and people who are going to participate in the product and try to sort of make money or build business on the product, right? I don't expect the consumers to participate quite as heavily as I expect the partners or I call them partners. Spotify's keynote today was fantastic. And I sort of feel bad that he feels bad for not participating more because Spotify is mostly an end user. I expect orders of magnitude more end users than partners. They're not expected to have to participate. Exactly. That said, they're welcome to and I'm happy to help them and anybody else be successful. On the flip side, you've got all these businesses who are trying to be part of the Kubernetes ecosystem, right? The hardware vendors and the software vendors and the security vendors and they, yeah, you want to play in the Kubernetes space, come to the community meetings and talk with us. I mean, I come to KubeCon and meet with us. Exactly. When I talk to Linus Torvalds, you know, and the basic question I ask, you were like, a lot of people, they are just using the, I mean, if you're not making any changes to the kernel, you don't have to be, you know, just go out and you shouldn't be aware of the process. Exactly. Red Hat, different story. Susie, different story, you know, or Google different story, but so if you're not making any changes, you don't have to. You should not feel bad that you're not contributing. Exactly. Any other, you know, from this conference, what was the, because first of all, this is one of the biggest, I think. This is the biggest one yet. So what was your kind of, you know, feedback you got or? I mean, so far it's been a great conference. We're only day two. We had our contributor summit the day before, which was great. It's like a party with hundreds of my best friends. It was great to talk to people and go over sort of what's new in each piece of the ecosystem and catch up on things. The project is far too big for me to read every pull request at this point. The conference itself is great. I go to the Google booth and I just talk to people and I get such great insight just from hearing people on the ground. What are you doing with the system? What problems are you having? And some of the problems are real and really hard. And those are the problems I wanna be able to focus on. And in truth, you know, I work at Google. I don't work at a bank. Banks have different problems than Google does. And so when people come to us with these enterprise problems, these hard problems that I've never seen before, I love it. I wanna think about it. This really excites me. I think this is what makes the project successful is the ability to just sit and talk with these people very frankly, very openly. And again, to reference the Spotify keynote this morning, the fact that they're willing to publish what they're working on and talk about it in great detail helps everybody because we're, you know, all of us are smarter than one of us. And we're all facing the same problems. And honestly, there's really not that much business to be had on building your own infrastructure. It's just a money pit. Let's all work together to get past the money pit so you can focus on actually making money. And then yesterday CERN was also there, you know, to young- CERN keynote is awesome. It's amazing. And so when you talk, as you said, you met, so what was the, like, you're like, okay, this is the use case that you're like, oh, this is a kind of interesting use case for you or the problem that somebody you met here and you're like, oh, this is interesting. You should be looking at it. Anything you can point out? I've had a few that have come up today that are mostly around networking. Networking seems to be- We already discussed about NFV, yeah. Yeah, I mean, networking seems to be the hardest problem sort of in the space because every network is different and everybody uses it differently. You know, we have some long-lingering issues around networking, not even just around NFV, but around legacy applications and sort of bridging the divide between things that assume they have static addressing and containers which sort of assume you don't and how to make those worlds map together. Yeah, because a lot of things exist before communities came into existence. So they expect a lot of things from you. Anyway, I think we had a great discussion and hopefully we'll see you again in the future. We're running short on time, but we'll catch up with you again in the next Q-Con or maybe some other open source. We'll see you in Seattle. Thanks for your time.