Salman Iqbal: One Kubernetes hypothesis.
Bart Farrell: One expert.
Salman Iqbal: And one question.
Bart Farrell: Does it actually hold up?
Salman Iqbal: In episode two of KubeSelect, we are tackling one of the oldest debates in Kubernetes. Should you run databases on Kubernetes? StatefulSets, persistent volumes, Container Storage Interface, and operators have changed the technology massively. So maybe Kubernetes isn't the problem anymore.
Bart Farrell: And in order to figure that out. We brought in local village sorcerer Kat Cosgrove to pressure test our hypothesis. Kubernetes is ready for databases, but most teams are not. We get into storage, operators, why you still need database experts, and whether putting everything on Kubernetes actually makes your life easier or just gives you more ways to break things. Also, some hot tips about scams.
Salman Iqbal: So Bart, can we run databases on Kubernetes? Should you run databases on Kubernetes?
Bart Farrell: Slightly different question.
Salman Iqbal: Did the hypothesis survive?
Bart Farrell: This time, it might.
Salman Iqbal: Welcome everybody to KubeSelect, the show where we take one bold hypothesis about Kubernetes and put it to test. No hot takes, just evidence, experience, and healthy amount of pressure testing with our guests to see if the idea actually stands the test of time. And the hypothesis for today is Kubernetes is ready for databases. Most teams are not. I'm Salman, and joining me in this podcast is my co-host, none other than Bart Farrell, also known as the Lord of StatefulSets, because he spent years running the Data on Kubernetes Community, trying to convince us all that putting databases on Kubernetes wasn't completely insane. Welcome to the pod, Bart. How are we doing?
Bart Farrell: Very well. Good to be here. Thank you.
Salman Iqbal: Excellent. Our guest today is Kat Cosgrove. If you're going to pressure test an opinion about Kubernetes, Kat is exactly the person you want in the room or the virtual room that we're in at the moment. She's a member of Kubernetes Steering Committee, leads Kubernetes release team subprojects, serves as SIG Docs tech lead and has led Kubernetes releases in the past. All of this while doing her day job as a village sorcerer at VillageSQL, which is going to come in handy later on in the episode. In other words, she doesn't just have opinions about Kubernetes, she has receipts. Kat, welcome to KubeSelect. How are we doing?
Kat Cosgrove: I am excellent. Thank you for having me.
Salman Iqbal: Great. Thanks for being on the podcast. Here's the thing, folks, what we're going to talk about today is the hypothesis that we're putting forward. I'm going to set the scene a little bit before we ask our guests here some questions. For years, engineers were warned not to run databases on Kubernetes. That was also me when I used to teach people. I'll tell people, don't run databases on Kubernetes because the platform in the beginning wasn't designed around replaceable containers while databases depend on a bunch of stuff like stable identity, durable storage, careful sequencing, replication, backup, failure recovery. But Kubernetes has changed. We have stateful sets, persistent volumes, CSI, storage expansion, on which Kat is going to touch upon later on in the podcast. Now we have a more managed Kubernetes platform which allows us to run more stateful workloads. The question can no longer be simply, can Kubernetes run a database? The more useful question is, has your organization developed an operational maturity that is required to run one safely? Today we're going to break this episode into four blocks. Let's set this historical argument. Before we go into detail, early Kubernetes was excellent for treating application instances as replaceable. A pod disappeared, another appeared. That model worked for stateless. But for stateful, like databases, it didn't work. The advice we gave: don't run databases on Kubernetes. It wasn't necessarily out of fear at the time. Kubernetes lacked some storage and primitive workloads. The first question for Kat: was the original resistance to databases on Kubernetes technically justified?
Kat Cosgrove: Yes, for sure. It is not what Kubernetes was originally designed for. It's over a decade old, right? In the beginning, at the dawn of time, this is not what Kubernetes was designed for. It was designed for everything to be ephemeral. The point is we were trying to manage and scale applications that were made out of really large numbers of containers. And stateful workloads were just not really a thought then. But we've changed and Kubernetes is significantly more mature now. I assume that a lot of this is going to focus on stateful sets and persistent volumes, but stateful sets went GA with Kubernetes version 1.9. And we are about to release Kubernetes version 1.37. It's been possible for a long time, like a hot minute. 1.9 was, I think, eight years ago.
Salman Iqbal: A long time ago. For anybody who's listening and don't fully understand what stateful sets are, would you mind explaining really briefly what they are?
Kat Cosgrove: You think of a Kubernetes deployment in terms of deployments and stateful sets. A stateful set, it's wrong to say that it's a type of deployment because a deployment is a deployment, but it is a way of using Kubernetes that allows you to have persistent stable storage. Initially, they were not great. They did what was on the box and not much more than that. At the very beginning of stateful sets being GA, I still probably would not have said Kubernetes is ready for databases, because yes, they will allow for a stateful application to exist. That does not mean that they would allow you to run a database on Kubernetes, as well as running a managed database platform somewhere else. But it's a way to have stateful applications on Kubernetes. Not necessarily databases. I wouldn't rely on it exclusively for that. But the documentation makes it look more complex than it is. They are easier to use than they used to be. It used to be a huge pain and it scared people off, rightfully. But StatefulSets are a pretty standard aspect of running a modern application on Kubernetes now.
Salman Iqbal: That's fair. You said in the beginning, StatefulSets weren't that good. What was the feature that came out afterwards that gave you confidence around databases on Kubernetes? Do you know when that shift started to happen?
Kat Cosgrove: I think opinions will vary on this, but for me it would be CSI going GA. This was I think five, six years ago, but this is when we started moving storage drivers out of tree. When we standardized the way storage drivers interact with Kubernetes and moved all of the CSI plugins out of tree, it allowed anyone, any cloud provider, any database company, any random person to build a driver for whatever database they want without being beholden to the Kubernetes release schedule. Before that, any storage driver for a database for Kubernetes was part of the core Kubernetes code, which meant it was only releasing as often as Kubernetes does, which is currently three times a year. And it means that all of these big companies, everything from a hyperscaler to a startup with a fork of a legacy database, had to work within the Kubernetes ecosystem entirely to release a storage driver. There are a bajillion and one databases out there, even if you're only looking at relational databases, and way more than that, once you start looking at other database types that are better for different types of workloads, that's not really a feasible thing to chain to the Kubernetes release cycle. We have enough trouble cramming Kubernetes native features into a release cycle. It made more sense for us to move all of that out of tree. And doing that allowed for an explosion in database drivers for Kubernetes. That is what really popped things off for me, not StatefulSets or persistent volumes.
Bart Farrell: I think it's a great point. One of the challenges we saw in the Data on Kubernetes Community was the issue around standardization of practices, because like you said, there are so many different kinds of databases out there. And there was even a challenge when speaking to the CNCF about, could there be some kind of a certification for a certified Kubernetes database reliability engineer? They'd say, well, which databases are we going to be testing here? And we're also looking at things around storage. One of the big projects that was talked about a lot in the Data on Kubernetes Community was OpenEBS, and also all the things that were going on with SIG Storage. Sometimes I think a lot of people don't know all the things that are going on behind the scenes and all the different SIGs. And that's something you can probably comment on a little bit more here. But do engineers underestimate how much Kubernetes storage has matured because they remember the platform as it existed five or eight years ago when things were different?
Kat Cosgrove: 1,000%. It's not just databases people do that for. They do that for any given aspect of Kubernetes. One of the downsides of Kubernetes becoming so widely adopted and an industry standard so quickly is people remember what it was like when they first adopted it. And it is relatively young. We're still changing a lot. We're changing faster and faster every release. The way you remember Kubernetes five years ago is not the Kubernetes of today. For sure, that has been used to make an argument that we should be in a two dot, not a one dot still. But we haven't done anything yet that would introduce a significant breaking change besides the v1beta1 APIs. And that was seven years ago. They got on board with Kubernetes when it started becoming the industry standard five, six years ago and assume that it hasn't grown since then. But it very much has. Same way people assume that Kubernetes is still hard to use. It's complex for sure, but it's not hard to use in the same way it was hard to use eight years ago.
Salman Iqbal: That is fair. And v1beta1 when you're referring to the change in the ingress that happened a few years ago, I can't remember exactly which one it was. Just a side question. I know that because you are a sorcerer, you're into prediction. When do you think we're going to go to Kubernetes 2.0?
Kat Cosgrove: I think we're going to stick with 1.0 until the heat death of the universe for the bit. You know how people make jokes about every time somebody asks about Half-Life 3? Gabe Newell delays Half-Life 3 by another three months? I think it's one of those. We don't get that question as much as we used to. It used to be every KubeCon, anytime any of us went out in public, we would get asked about 2.x. Every time there's a significant change in Kubernetes, I think it should be a leap in the way the platform is used. I thought it would be the AI thing. There was this big push for Kubernetes to be an AI-native platform: we're the default for AI workloads, but that's not going to be it either because people are just using it for that. It could already be used for that. Obviously, there's heat death of the universe. Entropy will be 2.x.
Salman Iqbal: For a long time, it will always be 1.0. Excellent. Thank you for that. This really set up the scene for the whole podcast. You are right in saying that, in the beginning when Kubernetes came out, it was justifiable to not run databases in Kubernetes. But then we ended up with StatefulSets and then more on top of it when we got CSI, Container Storage Interface, which came out of the Kubernetes release and you can write your own driver. That's when you really saw an uptake on databases and just storage in general, being used in stateful applications being run on Kubernetes. Fair enough. And I do agree that people still think that it is much harder to run Kubernetes just full stop, not even storage, just Kubernetes itself. Moving swiftly on to the next part, you can run stateful applications. Fair enough? You can. Because now I have a StatefulSet, I can preserve identity and do a bunch of things. And persistent volumes, where I can store data in any volume that I want to store in, whichever one I use the driver for. People started to say, we can build an operator on top. An operator is a special pod that runs in Kubernetes cluster and automates specific things about deployments. Because StatefulSet doesn't really understand what database really means, like transaction consistency, schema migration. These operators can do a bunch of these things. Kubernetes can successfully restart a pod and then the operator sitting on top can do the database operations that it requires. The question for Kat is: where does Kubernetes' responsibility end and the database's responsibility begin?
Kat Cosgrove: Kubernetes is responsible for managing the pods, the containers, right? That is fundamentally what its job is, unless you have an operator handling some of this for you. It doesn't really know what's going on in there. It only knows what's reported to it in a way that it can understand. A lot of stuff does have to be offloaded to operators. A lot of stuff does have to be offloaded to a CSI driver of some kind. Kubernetes is not responsible for understanding and maintaining the integrity of data running in your database. It's not responsible for making sure that the database is healthy by running some kind of health check query specific to that kind of database, unless you tell it to do that with an operator. But fundamentally, Kubernetes is responsible for keeping the pods online. That's what it is. The actual operation of the database is the database's job.
Salman Iqbal: And then what kind of things for databases? You can pick any database. VillageSQL, whichever one you want to pick. If you have an operator, what kind of knowledge that needs to be encoded in the operator? What kind of things do you think that a successful operator should have?
Kat Cosgrove: Anything that's not generic to the concept of databases in general. How to handle automatic failover safely is different between MariaDB and Postgres, right? Those kinds of things get offloaded to an operator. The generic controllers care about the lifecycle of a pod. And that's pretty much it. There are some exceptions to that. But generally, the generic controllers know about the lifecycle of a pod, and that's what they're going to worry about. If you need to worry about things like, any database specific rule, handling automatic failover in a way that doesn't blow up your application, or a health check that is smarter than is this pod alive and throwing no errors, that is all stuff that needs to be encoded into an operator. A health check is going to be different from a relational database to a wide column data store. Those are entirely different kinds of queries. You need an operator to handle that kind of thing.
Salman Iqbal: That's cool. That makes sense.
Bart Farrell: And with that in mind, we're talking about teams that are working in these contexts and they're all coming in with the knowledge that they have or don't have. So are teams sometimes mistaking successful orchestration for successful database operation?
Kat Cosgrove: Wholeheartedly. I for sure suspect there's some degree of that happening. We tend to think that putting everything under one umbrella, so cramming everything we can into Kubernetes, even if they're widely disparate pieces, makes things easier to manage. But that is not necessarily true. Kubernetes is a really good abstraction layer. It's really good at centralizing control of things. And it's really good at that as long as things are going well. You still need a subject matter expert when something goes wrong. And I say when intentionally, because something is going to go wrong. It is not going to go well all the time. At some point, something is going to go wrong that requires a database expert to investigate it. Your cluster administrator is not going to necessarily also be your database administrator, not necessarily going to be an expert in running distributed databases. They're an expert in running your Kubernetes cluster. Just because it is all running well on Kubernetes right now does not mean that you have not done something wrong on the database portion that will blow up later. You just haven't run into the failure mode yet. You do not get to replace your DBA with a cluster administrator. You still need the DBA.
Salman Iqbal: The weird thing, Kat, I don't know if you've seen this or Bart, you've seen this. I used to work with a lot of DBAs back in the day, but nowadays there's not that many DBAs that we used to work with. I think the roles are shifting. Is this true? And what you're saying, I completely agree with. You need the person who knows the application to be able to debug what's going on in the application. The same is true for a database as well. Is that the trend that you've seen as well, that role is kind of disappearing? Or is that just me?
Kat Cosgrove: The title is disappearing, for sure. I don't think that the role is disappearing. The role is getting moved into different teams. You don't see DevOps engineer as a job title as much anymore, but you sure do see platform engineer a lot. Platform engineering is just an implementation of DevOps tooling and principles. That's all it is. The job moved. Your platform engineer, that is a DevOps person. And it was SRE for a while too, right? This is just job title shuffling. That's all that's happening with DBAs. They exist somewhere in a platform engineering team under a different job title. What is a forward deployed engineer? Nobody knows what that is. That is a job title that somebody made up. Same thing's happening with DBAs. That job is still real. We just don't call it DBA anymore. We don't have sysadmins anymore. The job is still there. We just don't call them sysadmins.
Salman Iqbal: The forward deployed engineer is just something made up. Anthropic made it up.
Kat Cosgrove: It's fake.
Salman Iqbal: It's fake. No, that's fair enough. Also, I completely agree with you. But some people get really upset. They say DevOps and SRE is two completely different things. And platform engineering. On this podcast, I agree. I think that makes sense. In the beginning, Kubernetes wasn't really built for running stateful workloads, but then we got persistent volume. We have StatefulSets. That gave us that confidence in running it. Then on top of it, if you can have an operator that has the knowledge, the specific logic built into it to manage the operations of a database, that gives us more confidence. But as you both mentioned, you still need the people to be able to manage it. That organization needs to have that maturity. Let's talk about that for a second. Imagine there's two organizations. The first already operates Kubernetes, has strong platform ownership, understands the storage layer, has DBAs, plenty of those, tests the restores, rehearses failures, does the upgrades in the controlled fashion, all that kind of stuff that we all dream about. That's what I dream of all the time. The second one installs a database using Helm chart. That's me in reality. Then it sees the pods are healthy and assumes that Kubernetes has solved high availability. We're done with that. Both are technically running a database on Kubernetes. Nobody can say that. But then the debate moves away from, can Kubernetes support database towards, can the organization manage this if anything goes wrong? Like you just said, Kat, things go wrong. The question is: what capabilities must the team, be it a platform engineering team or whatever it might be, have before moving a production database onto Kubernetes?
Kat Cosgrove: I think this is more of an answer for the team's management. The C-suite, the VP of engineering, whoever, there's going to be a temptation because you're migrating to Kubernetes to can your DBAs, to get rid of them. They think because now it's on Kubernetes and you don't need the dedicated database people, you just need your platform team. That, as we said in the previous section, is so not true. You extremely still do need those database experts. There's not a ton of skill overlap between a Kubernetes cluster administrator and a database administrator. The need for those database skills do not go away just because the cluster administrator is now the babysitter of the database. That cluster administrator, unless they've been around for a long time and have changed their job titles a long time, I'm sure some of these people exist, but you probably can't afford them. The cluster administrator does not have the experience to handle it when something very database specific goes wrong. The number one thing I would say is you still need that database expert if you think that you are going to migrate your database onto Kubernetes. You also need a functional cluster administrator. You don't need somebody who is brand new. This is not an entry level way to run Kubernetes. You do need an experienced cluster administrator. I also think that you probably should not be rolling your own for this. I think that you should be using a managed Kubernetes service for something like this, which is generally what I advise. I think most people should not be rolling their own clusters because of the specialized knowledge it requires. But the number one thing is this is not a Kubernetes skill set specific problem. There is just not that much overlap with a database administrator skill-wise. You do need both.
Salman Iqbal: Can I ask a very controversial question on top of that? You did say that we do need cluster administrators and database admins, and I agree. Do you think some of these AI agents can do some of those tasks, or is that too controversial at the moment?
Kat Cosgrove: I have a pretty long and storied history of shooting my mouth off with pretty much zero regard for how it impacts the feelings of VCs. I will say that I think AI under the supervision of a domain expert is a really good way to reduce toil. Things that are predictable and repeatable and they have to be done manually and they're annoying and they take a lot of time. I think that is a really good use for AI tooling if the problem is predictable and well documented because fundamentally these things are really good predictive text, right? It's not a person and it can't think and it shouldn't be used for creative works. I do think that they are a good use for toil type of things. Maybe for this one, if you already have those two experts in place to supervise what it's doing, somebody has to be there to babysit it. You should not be turning Claude or whatever loose, unsupervised to handle a migration like this. You for sure still need a cluster administrator and a database administrator there to make sure that its output makes sense, because it's just too finicky. It's too fragile. There are too many things that can go wrong. Also, all of the hyperscalers are finally figuring out that using AI isn't free. Tokens are expensive. If you already have that cluster administrator and that DBA, are you saving enough of their hours to be worth the cost of those tokens? For a one-off like this, that's honestly probably pretty weighty. I am not sure that it's worth it. I use it as a really smart templating engine. A migration like this isn't that. I don't think it's that much of a time and money saver. I wouldn't personally. You do you. But I would not. To me, it feels like an expensive pain in the ass. Or you do it for the sake of saying that you're an AI-native company.
Bart Farrell: And scam the VCs. I'm a big fan of that. But that's a t-shirt ready to be made: Scam the VCs. You're first. I won't want a coupon. I'll definitely wear the coupon. Scam the scammers, folks, and do it with them and bigger. I definitely agree. This took an interesting turn. With that in mind, it's very clear that you've identified some things about when a team is obviously not ready to be moving a production database into Kubernetes if they think, we're just going to vibe code our way through it and not have these guardrails in place or babysitting responsibility. In terms of what you've seen, what would be the clearest warning sign that an organization is definitely not ready to be moving a production database onto Kubernetes?
Kat Cosgrove: If they just think they need to do it because everything needs to be on Kubernetes, you're not ready to be doing that. You're not considering the upsides and downsides. You're not considering the ongoing maintenance of running something like that on Kubernetes. And that's the same answer I give for people who are questioning whether they need to run Kubernetes at all. A lot of people throw applications on Kubernetes that don't need to be on Kubernetes because it's trendy. It feels like they need it. And the more this database conversation heats up, the more of that I think we'll see. You have to consider whether or not it is useful to you to run Kubernetes or a database on Kubernetes. In a lot of situations, I feel like it's probably not. And you're just doing it because you want to cram all of the shit you can into Kubernetes, which is ultimately a maintenance risk in your actual infrastructure and in the people that you're going to have to keep employed to keep doing this. Make sure that you need it and you're really going to benefit from it. Not all workloads benefit from being on Kubernetes.
Bart Farrell: And in a way that was supposed to provide operational simplicity, but probably only adds more complexity.
Kat Cosgrove: For some very specific things, it is better to run your workload on Kubernetes. But if you're already using Kubernetes really heavily, and it's very much ingrained in your company, you've been cloud native from day one, and your database is the one outlier, and it is a workload that could benefit from the scalability of Kubernetes, then I think go for it. But if you're medium on Kubernetes, or your organization is relatively young in its cloud-native journey, and you don't have the expertise in place, I think for sure, moving your database onto Kubernetes is just going to create wildly unnecessary complexity for you.
Salman Iqbal: I think that's completely fair. So far, we started with: don't run. They would say, yes, do run. Now we've got a bunch of stuff on Kubernetes. You can run that. And then they'd say things like CSI. Make sure that your team is ready to have all those roles, have all that knowledge. And we know when we can't. Let's quickly talk about this because we're coming to the conclusion of this, and hopefully we can talk about the hypotheses that we started in the beginning. People will ask this question. You mentioned that you should not run your own Kubernetes cluster. Use a managed Kubernetes cluster when you can. People will ask a similar question. Should I run database in Kubernetes or should I just use the managed service? I know you touched upon it right now. Only run it when it benefits you, but you can go into a little bit more. What are your thoughts on this case? Should you just go towards the managed service unless you want to do such and such, then run database in Kubernetes?
Kat Cosgrove: In most situations, use a managed service. Make things easier on yourself. Offload some of that work onto somebody and something else. Make that Amazon's problem. That's not your problem. Who's the CEO of Amazon right now? I can't even keep track. Andy Jassy. Scam that person. Damn, Andy Jassy, he's not gonna notice you're scamming him. He's got so much money he's not gonna know. What are you waiting for? Scam that dude, genuinely. But there are workloads that I think are good on Kubernetes. For example, caching. Any kind of workload that's fine being ephemeral, anything that's really quickly reloaded from an external primary, that's a good thing for Kubernetes. Think of things you use Redis for or Elasticsearch. That's a good workload to be running on Kubernetes. And it's not necessarily a business-critical workload. I would not be storing your entire customer database on Kubernetes, right? That's not necessarily useful. It's not something that needs to be queried rapidly. It's not something that is great at being ephemeral. But the caching, that's a Kubernetes thing. Throw that on Kubernetes, no problem. But if you've got a big-ass MongoDB database that is going to be super time-consuming to reload if it goes down entirely from an external primary, leave that on an external managed service.
Salman Iqbal: What you're saying is something like caching, like Redis, that's a good candidate for running on Kubernetes. I think you said it quite nicely: any critical databases, keep them outside the Kubernetes cluster unless you really want to. I'm going to close this section by asking you to complete the sentence because it will make a good clip for us. You should run a database on Kubernetes when?
Kat Cosgrove: Do it when it's easy.
Bart Farrell: As easy as scamming the CEO of Amazon.
Kat Cosgrove: Do it when you're scamming a billionaire. Stateful Scams. That's a new podcast name?
Salman Iqbal: We could start another one. Maybe you can rename this one. Why not? Special episode.
Bart Farrell: I think we have a title.
Salman Iqbal: Excellent. This is great. Let's go back. We have a couple of things before we close off. A quick recap. We talked about it was difficult in the beginning because Kubernetes wasn't really designed for stateful applications. Kat, you mentioned 1.9 is when StatefulSet, which is about eight years ago, went GA, and then you could start running stateful workloads on it. And then we ended up with CSI when we had Container Storage Interface. That is when actual databases could run. And you built controllers on top of it that allows you to run Kubernetes quite well. You have the right teams, right knowledge, you can run databases on Kubernetes. In the end, you mentioned some of the workloads that fit really well to run on databases on Kubernetes, things like caches that you can run like Redis. We started this conversation at the beginning of this call that Kubernetes is ready for databases. Most teams are not. After everything, Kat, that we've discussed so far, do you think the thesis holds or shall we rewrite it?
Kat Cosgrove: No, I think it holds for sure. The existing misconceptions about Kubernetes' suitability for a stateful workload is a problem because it is in some situations. People tend to think that because you're running on Kubernetes, you do not need a database expert anymore. That is a pretty significant problem. I don't think it's a technical problem anymore. It is a people problem.
Salman Iqbal: That's fair enough. You heard it here, folks. Two main things. Number one, scam the scammers. Number two, Kubernetes is ready for databases, but most teams are not. That's excellent. We have some quick-fire questions for you, Kat. If you don't mind, we're going to do a quick one. Bart, do you want to start with the first one?
Bart Farrell: Absolutely. All right, Kat. Coffee or tea?
Kat Cosgrove: Coffee, black, no sugar.
Salman Iqbal: Morning person or night owl?
Kat Cosgrove: Both. I like to go to bed early, but I do work right before bed. I go to bed at like nine and I get up around 5:30 and then I work while I drink my coffee and then I disappear mid-afternoon for a few hours.
Bart Farrell: When you're on a plane, window seat or aisle seat?
Kat Cosgrove: Depends on the length of the flight. If it is a short domestic flight, window, if it is a long domestic flight or God forbid, an international flight where I don't have a lie-flat, aisle. I don't like climbing over people to go to the bathroom.
Salman Iqbal: I agree. Buzzword you're most allergic to right now?
Kat Cosgrove: It's agentic, but it's whatever the VCs are trying to convince me I need.
Bart Farrell: Bonus side-quest question: Space Marines or Orks?
Kat Cosgrove: Space Marines. That's a tough one for me because I'm a huge Lord of the Rings fan. This is the Witch-king of Angmar helmet behind me. But I'm also a huge fan of the Doom universe and of the horror movie Event Horizon. I have several wearable Doomguy helmets in my office. There's a whole bunch of Doom stuff in here. I have Doomguy's sigil tattooed behind my ear. So I gotta go Space Marine. I do believe that the movie Event Horizon is actually a Warhammer movie, though. They are very clearly going through the warp, okay? That's what happened. The gravity drive on the Event Horizon took them through the warp, and that's why Hell is on the ship. It's a Warhammer movie.
Bart Farrell: I agree, and remember, there's no right or wrong order here. Go out and watch the movie, and while you're watching the movie, thinking about which VC you're going to scam first. But I do also have one more question, Kat, because you're wearing a Portishead t-shirt. What's the one song that people aren't listening to enough by Portishead?
Kat Cosgrove: My favorite song is probably Sour Times. Everybody loves Glory Box. I love doing that one at karaoke. It's a banger, right? But everybody knows that song. I think that album is perfect front to back. It's a shame to skip any songs. I'd run it front to back, personally. But Sour Times is my favorite.
Bart Farrell: Excellent. Very good. I think we've got some pretty good material here. And we do not accept any responsibility for any financial crimes being committed against venture capital funds. But you take the information from this podcast and do what you will. It's up to you.
Salman Iqbal: Thank you so much, Kat, for making time for us and sharing your opinions with us. That was honestly a great discussion with all the experience that you had with Kubernetes for such a long time and bringing it in your point of view. And it really made us either get to that claim or hypothesis and test it to the very end. I really appreciate it. What are you up to in the next couple of months?
Kat Cosgrove: I'm going camping. I'm disappearing. I'm gonna go touch grass. Love doing that. I don't do a lot of computer in my time outside of work aside from playing video games. Most of my hobbies do not involve computer. Work-wise, though, you can find me at Open Source Summit in Prague. I will also be at KubeCon in Salt Lake City. And I am driving so that I can disappear and go camping in Zion afterwards.
Bart Farrell: That's a really good plan.
Salman Iqbal: That's a great plan. Thank you so much, Kat, for joining. Thank you, everybody, for tuning in. Bart, any last words for everyone listening in?
Bart Farrell: I'm very satisfied and have a lot of scamming to do. I'm really grateful to Kat for sharing her time and her background experience working in Kubernetes, and all the things that you've done. I admire how you're able to do all this stuff and sometimes share news that people don't want to hear in the releases. And you did it with a cool head. I really respect that because I couldn't do it.
Kat Cosgrove: Thank you.
Salman Iqbal: Thank you so much. That was all from us.
