 Well, first, thanks, Kelsey, for doing this interview. First off, you don't really need an introduction, but would you give one anyway for the audience? Yeah, so I'm Kelsey Hightower, I consider myself a technologist, specialized in things around compute, that's Kubernetes, containers, and then all the way up the stack to like how people write software and the best patterns to use. When did you realize Kubernetes was going to be such a transformative technology? I don't know if I realized that until maybe a couple years down the road, but I think when it first came out, just my previous experience as a system administrator, this is the thing you were trying to build all those years. So when I saw it, I immediately knew, like this thing solves my problems. So I think I kind of attacked it as a contributor first, and someone who wanted to teach other people what I saw in it. Not sure if it was going to ever blow up or not, but it definitely had the right footprint when it came out. How did you become so good in teaching other people, like you're almost on the next level there? Was there some education you had, or was it a passion? How did you get so good in that? People ask me that question a lot, like how do you keep up with all this new stuff? How do you figure out and learn this stuff so quickly, and then how are you able to explain it? Explaining, like that's the hardest part. So I think it's the fundamentals, so I get the fundamentals, like there's compute, you write software, and you run it on a system. No matter where you do that through Docker, or you do it through Kubernetes, I stick to the fundamentals. So I usually try to explain things based on the fundamentals, and then break down the technology until we get to the bottom. So whenever something new comes out, my guess is it's not going to change how we do computing. That hasn't changed in a long time. So it must be implementing some fundamentals. Once you learn like the three, four, five basic fundamentals, then you just look at the new technology, and you just work your way down and say, that's how they're implementing this particular fundamental. So then I explain it that way to others. So for like Kubernetes, you're placing things on nodes based on a decision. So I'll play a game of Tetris live to show people the decision making that you're doing with Tetris, resource scheduler, Kubernetes does the same thing, and it makes it click for people. That's so smart. Did you ever imagine that Kubernetes would change the cloud computing industry as it has? No, I didn't think it would get this big, right? Because if you look at it at the very low levels, it's a pretty complex thing. But you also remember that Linux is also super complex. And then once people package it up and turn it into like a distro. So cloud providers have a managed service. I think once that took off, and then we saw Microsoft getting the game, Amazon getting the game, I think that just really made it like cemented its place where it's going to live. And it also works low enough in the stack where you can innovate on top. So given its APIs, given all those other things, it makes sense now. Kubernetes has helped people move higher up the stack and has helped with adopting things like serverless. There's a conversation that serverless is the new pass. What is your opinion on that? So I think forever people have tried to build a thing where most of the organization doesn't think about servers. So whether you're using Kubernetes or virtualization for that matter, the whole goal is that if I check in code, there should be very little interaction with infrastructure to get that deployed to customers. That has always been the case, right? So I think what people look at with Kubernetes is it was much better than just raw machines. If you've never gotten to the point where you had CICD, continuous delivery, then you looked at Kubernetes as something that's just much better than the manual stuff you were doing before, so you should just use it directly. On the serverless front, they're just reminding people Kubernetes is not the end game, right? We still just want something at a very high level closer to the software development process that more people can use without learning a full distributed system first. So I think that's the natural tension. The people coming from VMs will get Kubernetes as moving up the stack. People coming from the serverless world looks at Kubernetes as moving down the stack, right? It's going in the opposite direction. Do you think it's good for people to interact directly with Kubernetes? You have a lot of people now editing Gamble files for help charts, making different versions for different stages. Is that how it's supposed to work or should it be like a DevOps tool on top? So I think from a personal experience as a personal engineer, as an engineer that should know how these systems work, you should definitely learn Kubernetes if you ever plan to manage a Kubernetes cluster. So if you consider yourself someone that's an ops or doing DevOps or a cluster administrator, it might be a good idea to learn how the thing works because it may break. You're going to have to upgrade it and nurture it. But the whole point of infrastructure is so that people can deploy applications. And if you keep that in mind, then you have to ask yourself, do I just want to present all of this low level tooling to everyone in the organization? Or do I want to build some experience on top? So when I look at the YAML files, I always tell people that the YAML files feels like the raw assembly of Kubernetes. No matter what you use on top, Helm, case on it, all of that stuff is going to compile down to the raw YAML files. You can either write them by hand, you can use a tool to generate them for you. But in either case, at the highest level, the developer just wants to deploy their application. So figure out what interface makes the most sense for them to describe just that particular action and then hide all of this other stuff. So most people that just be done over time. You'll start with the YAML files, and then you'll progress until you have the own platform that makes sense. Net continuously moving up the stack, do you think there's already something beyond serverless? Are you seeing something that's even further abstracted? So if you think about email, for most people, you don't think about email spam rules anymore. You send email, and you assume it's going to get there. Matter of fact, if it doesn't get there, I've been on the phone with people, I'm about to send you this email, did you get it yet? So we've gotten so confident now that the email providers or the ecosystem around email is so solid. You start to see that for CDNs, you want to share a video or image globally, you upload it once, it's available globally. Databases are getting closer to that as well. Most people don't, aren't DBAs, but they use databases all the time. We never did that for compute. So most people are leaking all the details of how to run an application. So it's only natural that compute has to follow the trend of there's interfaces and there's infrastructure. Today we mixed them both, but they'll continue to separate. So then if you think about it, there'll be interfaces like functions as a service. I want to respond to some event. The lowest common interface you need there is a function to handle the event. And then there's other things you want to do like machine learning. You may be using things like a TensorFlow framework. And in that case, you're just going to write the rules that you need to evaluate or make a prediction, and that's going to run on some infrastructure. So to me, serverless is just a reminder to us that we should focus on a high level interface and hide the various infrastructure underneath. That makes a lot of sense. When you get so far away from the compute, is there a problem that you start using too much compute without knowing it? I hear, for example, people use serverless and functions, but they don't close down properly and they all run to the time limit and then they end up spending a lot of money. Do you think as we move further away, we need like better tools to see how much compute we're using? Yes, I think that's what the platforms will have to do, right? So for example, we just allow Cloud Run at Google and we implemented a few things. Number one, there's a time boundary on how long the container can run. I think it's like nine to 15 minutes. You can have concurrency that you can control. You can dial it up. You can dial it down. And then if you think about what most people do with virtual machines, they just create big VMs and they just sit there idle for the majority of the time. So depending on the platform that you pick, you have to decide how much idle spare capacity you want on board. If you look at the functions as a service, they easily implement time limits. Now, unbounded scaling is the problem. Hey, I'm using this function framework. And then if I send 1 million requests, it spins up 1 million functions and it multiplies that price by. So I think what you start to see is the platform starts to give you controls, like Cloud Functions, for example. We have a tunable that says no more than 100 concurrent functions at a time and that gives you the ability to rate limit your spin and give you cross control. That makes sense. Why do you think Kubernetes hits such a chord with enterprises that it's becoming an effective standard these days? It's a quick step from VMs up one layer. You don't really have to rewrite the entire app. You can take most apps as is, put it in a container. It's probably going to be a big container, but Kubernetes can run it. So I think there's a good setup with Puppet, Chef, and Ansible, the whole configuration management space, infrastructure as code. So many enterprises adopted a lot of those tools over the last 10 years. So most people got familiar with this idea of describing what they wanted the infrastructure to be. So then when you look at Kubernetes, it simplifies that model, right? You're not writing a full-blown programming language. You're just using a little bit of YAML, taking that application and packaging it. So for most people, it's a natural progression from running on a Linux VM to running on something that's managing a bunch of Linux VMs. So it's a natural step. Serverless, on the other hand, is like you need to rearch tick at the app. You can't necessarily run the thing unmodified. So if you look at the enterprise adoption curve, they can only take such a big leap and I think Kubernetes meets them where they are. That makes sense. Do you think there's still room for tools like Ansible in a Kubernetes cloud-native world? I mean, I personally wouldn't use Ansible in the traditional way people think about it, right? So I used to work at Puppet Labs. And all the configuration management tools follow this pattern around machines. You take machines, you put them in an inventory, and then you give them some identity. This is my web server, this is this other thing. And then you describe in very low-level details, this is how you install this package, this is how you update this config file. Kubernetes doesn't have the machine, it doesn't leak that necessarily, right? So you don't have individual machines that you're describing. So if you think about what configuration management tools could do, if they chose to, is decouple themselves from the full machine model. So then you look at Kubernetes, it's almost one big machine, and you describe all the configs that goes in there. So then you don't necessarily have an inventory of machines, you have an inventory of clusters. And then what you can do is start to define what does that YAML file look like as described by Chef, as described by Ansible. So you can definitely use those tools because guess what? They do configuration management. Kubernetes has configurations that you tell it what to do. So there's a natural fit, but there's an impenet's mismatch based on this whole, what node should this role have versus a cluster in namespaces running multiple roles? That makes a lot of sense if you have, every company I've seen, they end up with a ton of Kubernetes clusters with all different networking rules and things like that. So that's really insightful. Thanks for that. Where do you think there's holes in Cloud Native today? Where do you think we still need improvement? All patterns have holes because they usually work for the company that came up with those patterns or for those situations where those patterns were a good fit. For example, the 12-factor app. Remember that pattern? Like 10 years ago, Heroku comes out, writes the 12-factor manifesto, and it's like you should put configuration in environment variables. There was no support for config files. So imagine if you need a SSL certificate, you're putting it in an environment variable. We know that there are libraries that take the whole environment and just upload them somewhere. So that's not necessarily the best practice, but it's a good practice if you were on an app or a platform that only supports environment variables for configurations. Cloud Native is also limited in some ways. It assumes a lot. It assumes that the app can be resilient in order for the underlying infrastructure to be ephemeral. If you take your app that you wrote 20 years ago and neglected all this time, you don't have any of those kind of controls, and you just move that app into the Cloud Native type of design patterns, it's gonna be worse than what you had before. So I think people have to understand that there's trade-offs. You're gonna have to write more reliable code if you expect to be able to adopt these platforms that's going to be able to kill and move your stuff around at will. So it's just trade-offs. I think this is still a worthy trade-off because you should have been writing software to be robust anyway. Cloud Native is almost a forcing function for many people. What are your favorite examples of organizations embracing Cloud Native and being able to do things they weren't able to do before? So I think you look at some of the banks who have finally got over the, where can our data live, right? And I think a lot of times, depending on where your data is stored away, you tend to limit yourself to anything that's accessible. It's like on-prem. You may not have the ability to go buy all the newest hardware, install all the newest platforms. So you kind of regulate yourselves to what you've been doing for the last 15 years. Now that banks start to loosen the grips a little bit on their data, they found ways to be securely in the cloud. Now they're doing things like machine learning, they're doing advanced fraud detection, real-time fraud detection. So now that they've done that, they start to unlock all the tools and given that large data set, they can do things that most companies couldn't do. So I think machine learning has been the biggest leap for most companies. All these data stored away, almost sitting there idle doing nothing and then you unlock it and now you're building all of these features and capabilities that you couldn't program by hand. Most things you could program by hand, maybe some fancy for loops, but this world of like real-time fraud detection based on models, that is a whole leap for most companies. Makes sense. You've been vocal about Kubernetes not trying to be too many things. Is it currently expected to do too many things? Yeah, so I think there's two parts of Kubernetes. There's Kubernetes, the application container platform. It runs things that are in containers. The things that runs the best in containers, the stateless app. Not necessarily 12 factor, you still can have config files, you can still have a volume, you need to do some big computation. Perfect use case, failover all the things you need to do that properly. But if you try to bring in something like MySQL, who hasn't really adopted things like the cloud native patterns, if you take that traditional deployment and as is, no other tooling deployed on Kubernetes, it's gonna be a problem, right? Things get moved around, you try to upgrade it, you end up turning your Kubernetes cluster into some of that snowflake infrastructure that you're coming from. I don't see a real reason to force yourself into this pattern unless you're willing to update things like MySQL. So we have tools like the test that sit on top of Kubernetes that try to adapt Kubernetes for that environment. You know what I mean? And I think that is a lot of complexity that most people don't assume is required to make that work. Then you have people that just like, I'm going to rewrite everything to run on Kubernetes. Hey, here's my Kubernetes CI CD system. Here's my Kubernetes ticketing system. Here's my Kubernetes car wash. It's like, you're doing too much. Kubernetes has a sweet spot. Yes, it has a very extensible API, but it doesn't mean that every API needs to be implemented in Kubernetes. So I think what most people should do is build a good API first. If it makes sense to host that thing on top of Kubernetes, great. Run it on top of Kubernetes. If it makes sense to have a Kubernetes custom resource definition interface to your API, great, augment your API with the resource definition model. But I don't know if it makes sense to really go all in and have your thing depending only on Kubernetes. We've seen this before. Every 10 years or so, we get really excited. And then 10 years goes by, it's like, oh, all of that sucks. There will come a day when Kubernetes is not going to be the thing people want to use. And here you go, trying to report your thing to the next thing. Thanks for that. And I think you touched on something really interesting with the stateful loads like my SQL. I see a couple of patterns. I wonder what you see. I see people using it, having the stateful things outside of Kubernetes, management tools like Ansible. I see people doing the CRDs, the custom resource definitions like vTest. And I see the newest thing is technology like cross-plane where you say, look, I'm gonna use the cloud for that. The cloud provides that. And I'm gonna manage that in a cloud native way. What are you seeing and how do you think that this will play out? So this is where I go back to the fundamentals. You can run a database yourself on a VM. You can install a database by hand. App get install my SQL. Edit the config file. You have a database. You can have someone else run the database for you. You know, RDS, Cloud SQL, someone else is writing a database. They're probably doing something similar in an automated fashion, but you don't have to think about it. So their extraction is here's an IP, here's a credentials, connect to the database. You can also do that on Kubernetes if you know what you're doing. Most people don't know what they're doing, but if you do know what you're doing, Kubernetes is just running containers on a VM. You can mount storage, turn off things like dynamic scheduling, maybe pin it to a dedicated set of hosts so you're not having resource contingent. You could totally do it, but most people don't know enough about Kubernetes to understand the trade-offs that they need to make. So if you look at things like crossplane, it says I can automate you using one of those other techniques. If you're in Amazon, I'll create a RDS database, take the credentials and stick them in a place that you can use them. You could do the same things yourself. So these tools are either trying to provide a workflow for doing the fundamentals, provide a better interface than the one that you already have. So I think when people look at all of these techniques, they're all viable. If I was a DBA and I was very comfortable running on VMs or maybe there are cases where I need like a 12 terabyte VM with the SAP stuff, I'm probably just gonna get two or three virtual machines all around my need and just use Ansible and call it a day and present IP to the other organization. I am done. Until Kubernetes proves more value than that, then maybe I stick with that for a while. So that's the reason why I'm very vocal about this whole thing. Like you don't need to go and blow away every structure that's working fine. Throw it in Kubernetes without understanding the trade-offs. That makes a lot of sense. I think I already know your answer, but do you think we have to move from non-cloud native databases like MySQL and Postgres to newer databases like what Cockroach Labs is making, CockroachDB, things that are made to be on multiple machines and to be cloud native? Yeah, so when you think about the Postgres and MySQL of the world, they did a great job. When you run them in their native habitats, virtual machines, static infrastructure, they do a good job, they scale up. Now that we're in a world where people don't wanna build all this glue around the infrastructure and database to keep it highly available, it's nice to see all of those patterns built into the database itself. So over time, new databases should do a better job with some of the challenges facing new people. So CockroachDB is one of my favorite databases. They think about all these operational concerns, not from you gluing together things on the outside or relying on some things in Kubernetes. It says, well, I'm gonna do a good job at doing highly available, finding my members, fixing myself, also thinking about data spread across the globe and having that built into the query-sensitive self. So when you have a database that works like that, it's probably the best candidate for something like Kubernetes. I think over time, just like we saw with static file hosting on FTP servers, and now what you see with Aclymy and CDNs, databases have to evolve to a world where it's going to feel like a CDN. I just log in, there's a global database that takes care of replicating my data, backing up my data, and making it an accessible, low latency, and adhering to my security policies. That's exactly what we want. And as new database companies come on the market, they're going to solve those problems and it's up to the incumbents to understand that's where people want to go, either improve or see less usage over time. That makes a lot of sense. And I actually think that it's very interesting to see CDNs take a more active role. You have Fastly that have their wasn't environment and Cloudflare that have their workers, which is boosting kind of more workloads to the edge. Big telcos are talking about having dedicated compute in the edge of the network, at the site of the telecom mass. What do you think about that development? So, again, when I think about the fundamentals, you have all of these web browsers. Everyone that's using the web is using a web browser and we push a lot of logic there. You can call that the super edge if you want to and you're running logic there. So a lot of these bigger web applications run on the user's device, on the edge. And then the extreme of that is the backend. This is where we keep some of the logic because it would not make sense to put that in the browser for security concerns and so forth. There's a middle tier of things that you want to do, like caching, caching validation, maybe there's some transformation stuff that you want to do that may be too intense as to do on the browser side. That sweet spot is kind of unserved by either of the two paradigms today. And I think this is where the next hop is obviously where the closest to the customer is and it makes sense for the CDNs to get in that game. And the other things that I think the CDNs are doing is filling a gap. There's not a lot of extensions on how you modify your own cache or other features and capabilities. So a natural plugin architecture, if you will, would be to use something like Wasm to allow the customer to build custom logic to manipulate that request because there's no way Fastlane and Cloudflare will ever keep up with adding every feature, every customer, whatever you want. So the natural thing to do is like look, let's let them write some code, we'll host it in the middle of that request and let them manipulate the response coming from us before it hits the client. So I think to me that's a very obvious evolution of those particular platforms and it's kind of nice to see those. Awesome. You have a good taste in seeing new technologies and seeing the next big thing. What's exciting to you today? I think what will be exciting is when common people can go from idea to running. So I was teaching my daughter, she's 12, like how to program and I started with HTML and some JavaScript and some CSS and she has a Chromebook so she's running it in her Chrome browser locally and she's really excited. She got some colors going and I'm looking at it like it's 1995 again. Things are blinking on the screen. I was like, all right, cool. Okay, you're making some progress and she wanted to show one of her friends. She's like, hey dad, why does this not come up on my iPhone? Why is it only on the laptop? I was like, oh, it's time to teach you about the internet. I'm really excited. Now, I have a choice to make. Do I teach her about Kubernetes? That's close to child abuse of taking a 12 year old and teaching them Kubernetes. That is not a good thing for me to do. You can only do your Tetris intro. Exactly. It won't work out well. So I was like, I love my daughter so I'm not gonna do that to her. There's no reason to do that to her. All she wants to do is get her website in a place where she can show her friends. So then I thought about it, we have Firebase. So on her Chromebook I started Firebase and I said, you run this one command Firebase deploy those files that you just written and then it's gonna give you back a URL. She ran the command, she got the URL, put it in her phone and it was like, I got a website and she did a little dash and she texted her friends and then she taught them how to build websites. That is what we're trying to do. Anything more than that is noisy and it's kind of serving our own self-interest. So I wanna see more technology whether it's machine learning, voice integrations, you wanna automate your house or you wanna cure cancer by analyzing all the photos and diagnosis scans. We need those creative people not to be wasting time trying to build up a cloud platform before they can solve real problems. Thanks for that. We're here at Google Cloud Next. Lots of announcements this week. What are the things that get you excited that you think deserve a lot of attention? I mean, Google's making this big jump into the enterprise meaning we're gonna come on-prem and deal with all of your pain. When you start to go on-prem, you have to absorb that. So that's kind of Google saying, we're gonna grow up a little bit. We're gonna give you this enterprise thing and meet you where you are, like all the way where you are, even on-prem. So a lot goes into that. I'm very interested to see where that roadmap unfolds and also things like Cloud Run, our take on serverless. We wanna expand the portfolio, not just functions, not just stuff that has to be rewritten, but can we marry the world of containers with the world of serverless? And the feedback so far on that has been people like, oh, I can now adopt serverless given the fact that you've met me a little bit closer to this container paradigm that I've adopted over the last five years. So those two big things have me really excited because I think more people see the ability to start to do things that they couldn't do before. What do you think is holding back serverless? When I see people embrace serverless, the next thing they struggle with is like they get this explosion of different functions they have. It's hard to see how it all fits together. It's hard to write tests. What do you think are the things that are holding back serverless? I think there's a big education gap. Fundamentals is like the thing I keep going back to. 10 years ago, I remember in the Java world, you could write a function and call onMessage and then it will invoke your function whenever a message showed up. Very similar. The problem with that pattern is, it works if you have great events and you have something to kind of control the elasticity of this. So back then, I guess we used message buses, they would handle some of the back pressure and they would have all of these workers just kind of listening and you spun up more workers when there's more things coming in. That pattern is trying to be applied to everything. Even back then, we didn't try to rewrite all of our monoliths to adopt that pattern. We mixed and matched the compute that made sense. Some stuff runs well in the mainframe. Some stuff runs well as a monolith and some stuff runs well as this event driven thing. Today, people are very fanatic about this all or nothing. Either I'm all serverless or I'm all Kubernetes or I'm all traditional infrastructure. That has never made sense in the history of computing have we all just went with one platform. We mixed and matched. There's things that run better on mobile because it makes sense. So I think the biggest challenge is that people want to rewrite everything. There's nothing wrong with monoliths honestly. The problem with monoliths, people have gotten themselves in a spot where they can't really update the code. It's messy, the code base is all over the place. And if you take that same mentality to functions, you're just gonna have a mess of functions that are gonna be all over the place and not gonna even know how to call them and the security is going to break down. So disciplines require no matter what the technology is. So people believe that the new platform is going to absolve them from discipline. I don't need to think about this stuff. I can just throw my functions over here and now I have nano services. It's like, no, that's just going to be more pain and highlight your lack of discipline. I think you're totally right. Last question, what do you think about GitLab from a technology perspective? What are things you love and what are things we could do better? So I think what GitLab done for a lot of people, number one, they gave them a viable alternative to GitHub. I think that was like the number one thing because I think before people had the ability to buy GitHub Enterprise, I was like one of those customers, it was expensive. But people wanted that whole integrated solution. I wanted my ticketing system to have integration with my source repository and then have a really tight relationship with my CI CD platform. So when GitLab came out, it gave people that, like people like the whole Travis CI to GitHub integration. But the problem is it was kind of all piecemeal. I couldn't run it in my infrastructure. So most people couldn't benefit from that. It took enterprises a long time to even allow their source code to lead the premises. So I think when people see GitLab, they look at it as an integrated stack that's continuously evolving. That's the thing, the fact that you're shipping all of these things like, oh, you guys want this feature? We have that feature. The community aspects, the other one, right? So traditionally, most productivity software didn't have a great community thing where you can go and improve your own tools, learn from each other. And I think having GitLab operate in the community environment where people are teaching each other how to use things. I remember when you were showing people that, hey, we moved from Microsoft to Google and things are getting faster and people were complaining about things used to be slow but then I watched the community come in and it's like, no, you could have done this instead. Nope, you could have done this instead. I think that community part is the best part of GitLab that we've seen a long time from productivity tools perspective. Thanks for that. And what are the things we could do better? I think you have to decide, am I competing with Alasian, right? Do I want to have the whole entire productivity suite? Or am I going to be like this better GitHub for developers who just want to automate it into end workflow? Because I think once you start to get into change management, focus starts to become a lot more on like the culture of the company, how they want to work integrating to other ticketing systems. And sometimes that's a different concern than here's what we've built, here's what we want to release and keeping that pipeline smooth. Then at that point you have to be able to adapt into the different cultures of the organizations. Most companies call this CICD. It's really them trying to articulate their company culture in a set of bash scripts and tickets, right? When we make this decision via tickets approved, then we want to run these particular steps. I think GitLab does a perfect job of that. Here's what we've built. Here's how we want to get it out to people. And for people that don't have a ticketing system, it's great that there's one in there. But once you start to get into the realm of like service now and the big integration into the entire enterprise, that can be tricky because if you do it once, you may alienate some people who want to bring in their own. They may not know how to spice it in. So I think it gets real tricky if you try to do too much or there's a perception of too much. Thanks for that. And thanks for the interview. Really appreciate it. Awesome, thank you.