 I'm gonna actually get a bottle of water because there's bottles underneath here, but they're hand sanitizer. And I think that would be bad if I chose one of those. Hello, everybody, sorry, I was a little bit late, but I flew in yesterday and I had to give a talk yesterday. Has anybody ever given a talk on an hour and a half of sleep? This is not that talk, by the way. But the team at Red Hat asked me to give a quick talk about my experience working with them and our experience working with them, which has been an incredibly great partnership. I'm always happy to get on stage to talk about Red Hat and kind of what's going on with us. But first of all, my name, my name is Jim Walker. I am principal product evangelist at Cockroach Labs. I've been with the company for about three and a half years. And three and a half years ago, not many people knew what Cockroach database was. In fact, they kind of thought it was gross and disgusting, whereas a lot of people now are kind of starting to use it. Three and a half years ago as well, I guess about five years ago, I started my journey in this whole Kubernetes space at a company called CoreOS, which is actually now part of Red Hat. And while I was at CoreOS, Waleed, I don't know where you're at in the room, I met a lot of those same people. I love that slide with all the faces, dude. It's like my favorite slide of the entire day. This conference is amazing because of those people and people that build communities. And I'm just, I get so excited that I was part of that team that was at CoreOS at the beginning because KubeCon has been such a part of my life. And for the last two years, not having it has been odd at best. And so if it is your first time here, I will second that. You don't have to be the dancing guy, just join in with the dancing guy because this is just a wonderful community. And that's why I present today. So the premise of Cockroach and Red Hat and OpenShift and Kubernetes and this whole thing, I try to simplify these things for salespeople all the time. Are there salespeople in the room? If you're a salesperson in the room, just if you could hold your, okay, we got one of them, all right. I'm gonna disparage salespeople a little bit here on stage, but you guys, you're good. You make money and commissions and all this stuff. But I have to simplify things for salespeople sometimes. And sometimes we have to simplify things for our managers. Sometimes we have to simplify things for developers. And that's really what the theme of this conversation is, right? When I think about Kubernetes and what's going on in this modern world, it's really a combination of two things. We're dealing with scale and we're dealing with efficiency, right? The promise of scale is basically modern cloud infrastructure. The promise of efficiency is, oh my God, I have ubiquitous infrastructure. I better start automating all that because this is super inefficient because I need millions of resources to actually handle all these things, right? And so when I talk about things with my salespeople, I'm like, hey, man, look it. This is really what this stuff does. It allows us to actually deliver on some of these things. Oh, look, there's one of these things, awesome. Okay, great. Not gonna work. So how do you explain Kubernetes to people? So back at CoreOS, go back five years, I had to explain these things. So I took my slides that I used at our very first sales kickoff to explain what Kubernetes does to people. Okay, there was a bunch of slides before this because salespeople didn't really understand what monolith to microservices meant and what a container was. And I had to actually kind of understand what a, God forbid, don't tell them what a namespace is, but you can actually break things down into what a container is, right? And you get to say, hey, look at containers are these things that when we used to build software, I had a CD-ROM that was for Windows and I had a CD-ROM for Mac and I had all these different versions. We don't need that anymore. You just have kind of one version you just deploy everywhere, which is really cool. It's super portable and awesome, right? The entirety of this is predicated on that. Salespeople get that, right? But if I'm gonna actually deploy these things and have a running on servers in these huge rooms with lots of things, who's controlling all that? What I'm gonna have like 15 people logging into each machine or standing by each machine and managing all these things, that's all that Kubernetes does. That's it, it's really as simple as that. It automates all of this operations, right? And so if we start there, it's pretty simple. Now, what the Red Hat team is doing is saying let's make it even more simple, right? Let's package it so that there's UI. Let's package it so there's this whole network of operators and things so that all these different pieces can come together, right? So it's really the next generation of simplification of Kubernetes. Now, back in the day when I, you know, the Corus days, I struggled because man, five years ago, managing Kubernetes was nothing short of, I don't know, did anybody do it five years ago? It was nothing short of a nightmare. It was pretty complex, pretty difficult, right? So we built something back then and it was called Tectonic, right? A lot of what's in Tectonic was actually carrying on into what's going on in OpenShift today and a lot of those same engineers, right? And so it was really about simplifying these things and making it easier for the enterprise to adopt because, you know, look, ultimately this thing does one thing, right? There's two parts of Kubernetes. There's a control plane and these little pods. Anybody ever seen that movie, Avengers, you know, where the big ship is up in the sky and then all these machines come down and wreak havoc on Grand Central Station? That's Kubernetes, man. There's like the mothership and then there's all these little guys and if you kill the mothership, you're gonna kill the whole thing, honest. Well, there's actually redundancies now for that. Okay, salespeople, it's pretty easy to understand, right? Like, I got it, Avengers, it's cool, right? Well, there's a state in this thing called Kubernetes and the control plane. It's called SED. SED is just basically a database. That's how you gotta think about it, right? Again, I'm talking to salespeople, right? It's just a database that has like state. I have these three different things that I wanna do. I guess that's blue, red, and yellow, right? My color blindness over the years has gotten worse, actually, I think, right? And I have these three things I wanna do. One of them is like get account. One of them is like print my statement. The third one is, you know, transfer funds to somebody and it takes input. And I have all these different services. I have different levels of services that I need to fit the traffic for certain things. So what you do in Kubernetes, you basically just say, hey, look it, I need 10 of the blue and so it spins up 10 of those across these physical servers that are somewhere. That's all Kubernetes does. Look it, I need eight of the red and I need eight of the yellow. It's pretty simple. We get mired in all these kind of complex kind of considerations and descriptions of what Kubernetes is doing all the time. This, I hope, is one of the most simple explanations of what it is. I know probably people are out there and wow, you just simplified like eight million things to make this work, right? But if I want to scale up one of those services because I have more demand, I just go into STD, I go 10, great, I have services. It controls, the control point says this is the state that I need to be in. STD is just managing state, right? Okay, so what if something fails, right? It understands that all these pods, one of my pods didn't check in. I better do something so I better start moving some things around so that I'm gonna maintain state. It's basically the ultimate state guarantee. That's what Kubernetes is doing, y'all, okay? The simplest Kubernetes presentation of the entire show, I presume, right? So what it did is it just moved a bunch of things around, right? It moved those three into some other servers, right? Pretty simple. Okay, so I found Cockroach Database, like I said about five years ago. And so I was at CoreOS and the CEO of CoreOS, Alex Polvi, was gonna get on stage and talk at OpenStack Summit. And he's like, Jim, we need an application to show on this thing. Nobody was really building applications and things to actually work on top of Kubernetes, right? Back then it was all like, it was stateless. It was ephemeral workloads. Like, what is this thing? I don't even know what stateless means half the time. I'm an old developer. Everything has a database, right? Everything has state. I didn't really kind of know where it is. Like, oh, talk to my friend Spencer at Cockroach. They're building a database that's kind of built for this whole thing, right? Like, it's kind of the same thing that's, you know, Google did with Spanner that they were doing on board. Well, this is like that, but for Kubernetes, right? It's gonna be pretty cool. I'm like, great, go check it out. Databases, I learned very quickly, have some pretty interesting challenges when it comes to Kubernetes. If you just try to spin up an instance of Postgres, sure, I could spin it up in a single pod. I could connect to that thing. Okay, it's pretty interesting. Okay, well, once we got, you know, stateful sets, we were actually maintained persistent volumes underneath that thing so that the storage just didn't go away, right? Because the ephemeral nature of pods, like, it helped a whole lot of things in this world, right? We used to use demon sets to do that, right? But stateful sets was about three and a half, four years ago, really helped the community kind of maintain state within what was going inside a pod. Now that lit up a bunch of databases, right? Because state is very important to a database. Because all a database is, is a layer between somebody that's trying to do something in some storage somewhere. That is literally all it is. It's a language that allows people to store data to the disk, that's it. And if I lose the disk, which is attached to a pod, well, I actually invalidated the point of a database. Now databases in Kubernetes are really difficult because you can bring up a single instance of a database and run it in a pod and great, I have this like instance and I can maybe scale that up. Well, just, what's my scale? I'm gonna get as big as that pod, right? Like, basically it's vertical scale at some point. Or I could try to run one of these things in these kind of distributed natures. But in the case of, that gets really complex as well because not all databases, at least on the relation side, were built to be distributed. They weren't built for scale. They weren't built to, you know, this failover thing. Like, if I just wanna increase the state of this service, how do I increase this, how do I get more instances, right? Cockroach was basically just built for that whole world. And when I saw it, I couldn't unsee it. Because the challenges that we have around efficiency that we're addressing with things like Kubernetes, they get accelerated. They go exponential when you start doing with databases because now you're dealing with actual physical storage. And basically, you know, the data that's in your app, which is probably one of the most important things that the developer is concerned about, right? And so there's lots of different challenges. And so, like being cloud native in this context, it's actually pretty important. So when we talk about cloud native databases, you know, like the VIST Test Project is cloud native, it's extremely interesting to me, right? What we're doing at Cockroach is cloud native. It's extremely interesting to me. When we attach that word cloud native to something, it actually means something, y'all. It doesn't mean that I have an operator and I could run that thing in a pod and I could manage this thing and all this stuff. No, it's the way the thing works is what's important. It's inside the architecture of that solution. I don't care if it's a database or a CRM or something like that in between. If it's cloud native, it means something. It means it's built to scale and it's built to be resilient. It's that core kind of description of what I said when I said Kubernetes and what that is, right? And so to me, when I look at cloud native, those are the things that are really important, especially at the application layer, above all this kind of craziness that we deal with. So when you look at databases, again, I'm a shill for Cockroach DB. When I look at databases, I think of the relational database. I never coded in a NoSQL database. I'm sorry, I left the document model somewhere around XML. I never really understood it. I guess I was just built in a world of relational data models and referential integrity and normalization and these sort of things. But these databases are really cool. I get to build things really quickly. They're dynamic, they allow us to do some things like the availability, the resilience, sound familiar, right? NoSQL databases. But the power of the relational database is still needed by our mission critical apps. Are you gonna run a financial ledger on a NoSQL database? You're not gonna do that because you're not gonna guarantee consistent transactions, right? We still need the relational database because honestly, it is basically the back end of all of our mission critical data in organizations. However, it wasn't built to be distributed. It wasn't built to be cloud native, right? So if we could take all those things and make it distributed, make it elastic, make it automated, make it modern, right? For what we're trying to do. That's great. Well, a lot of them try to do that. But you kinda need these complex operators to actually do those things, right? Operator is just basically a synthesis of something that you all would have to do. But automate it into a script. I think when we first named operators, we're gonna call them controller operators. I think Brandon Phillips wanted to call them controllers and then Rob Zoomsky is on the OpenShift team as product manager, Rob's awesome. He wanted to call them controller operators and we ended up calling them operators because ultimately that's all they're doing. They aren't controlling. They're doing your operations for you and you need these complex things to actually make these things work in these complex environments for most of the databases. So Cockerish combines all these things. I think you know where I was headed in this whole thing. And so how do we do that? First of all, this is a relational database. So like I said, referential integrity, secondary indexes, all the kinds of worlds of inner and outer joins and all the things you wanna do, materialized views, everything you would expect out of Postgres, right? Why are compatible with Postgres? The same sort of things you would wanna do in that environment. Hey Jim, what about stored procedures? Well, do you wanna do with stored procedures in a distributed environment? I love asking this in a crowd where people get distributed systems in Kubernetes because it's a little bit more straightforward. Does it make sense? Or would you just basically take stored procedures and re-architect that as a microservice and have it controlled by the control plane in Kubernetes? Doesn't that make sense? For us, we feel stored procedures are an anti-pattern. Will we implement it? Eventually. I think we'll call it distributed data functions though. Let's actually make it something that's valuable. Let's not take this legacy past and just basically fork it over and live in this new world. And that's what I mean by cloud native. Rethinking how you actually build in the application itself. Not just the infrastructure, what we're all dealing with as service meshes and API discoveries and Kubernetes. Literally, there's a lot more. There's another layer that developers really struggle with. And as ISVs, it's on us to basically make sure that this stuff is cloud native. Because this is what's gonna light up everything that we're all working on. But make it familiar, it should be relational. Scale and cockroach is pretty easy. Spin up a node, point it at the cluster and you have both horizontal and vertical scale. Vertical, you just have more computation, horizontal. You don't have to do any sort of manual sharding in your application, which is an absolute nightmare. But we can scale beyond just say a single data center or in this case, can you scale a database? Can you have a single logical database that spans across multiple Kubernetes clusters? When I saw this, I actually could this. This is the next thing I couldn't unsee. Deploying a database in a single cluster is fairly straightforward, right? I just talked about these things. What if I want a single logical database that's actually spanning multiple different regions because I have different Kubernetes clusters across the United States in three different spots? So that any node in, say, USEs can actually access any of the data that's in US West or in the Philippines or in Europe or wherever you wanna be. So being able to do that, being able to scale beyond just the single data center into what you really wanna do, can I federate at the data layer as opposed to federating all the clusters? I love what's going on. Whoa, SIGFed used to be like this really interesting space. It's really difficult to federate clusters. What if we move that up at the database layer and let's logically do it there? And that's exactly what this is doing. We can survive the failure of an entire region. When we write data cockroaches, we don't actually synchronize data. We have distributed consensus. If you're not familiar with what Raft is as a distributed consensus algorithm, go check it out. There's a website called thesecretlivesofdata.com which is just fantastic to help you understand what Raft is. But we can do some other special things. We can tie data to regions. So if you have data living in different clusters, do you want it always moving between these clusters? No. Can the database control and tie data to an explicit location? It's one of the magic things that we do in CockroachDB. So that's the overview of what we do. But over the past couple months and really over the past three years, I guess, I think when I started at Cockroach, we started working with Red Hat and lots of different stuff. Because I think we share a similar vision of what this hybrid world looks like. What does this look like when I have clusters? I don't care if they're across cloud providers or on-prem, whatever. That's hybrid to me. That's multi-cloud. And the two companies really share a vision of what I believe is a pragmatic reality. Is that these things are not gonna live in one spot. And so when I think about partnering with companies and things working or not, it really starts with a shared vision. And I think working with the Red Hat team, it's been incredible. And so over the last, oh gosh, it's been about a year, I think. The Red Hat team's been working on, or about six months a year, I think, right? They've been working on Red Hat OpenShift database access, which is Rota. Anybody who grew up in the 70s, Rota just makes me laugh every single time. I don't know why. You know what it is if you know. But it's really about this, remember this simplification journey I was talking about? Like, let's take, you know, started way back in my world in tectonic and then was OpenShift. And like, how do we make these things really, really easy? Well, deploying a database is really difficult in Kubernetes. So how do I get this kind of push button access to a database from OpenShift and from the OpenShift UI? And that's, it's really as simple as that. Let's forget about all these things. Well, it works really well with us because we're a cloud native database. It works well with some other databases too because, well, they have those aspects but they also have operators that are, you know, Red Hat, you know, operator certified. Red Hat OpenShift operator certified. There's a lot of words sometimes. Right, and so the Red Hat team does the work to actually make sure these things are gonna work and then simplifying it for everybody. So they wrote a really good blog post that talks about this. You could use the QR code if you wanna go check out exactly what they're building. But really it's kind of a, really a management plane for databases within Red Hat OpenShift. That's the way I think about it. And it's pretty simple straightforward. Like, we're really happy because, well, we develop, we deploy pretty easy. It's kind of like I said, it's push button and you're kind of ready to deploy. And then it's in preview right now. That's the second QR code actually goes into the docs if you wanna go check that out. And so there's a little bit more information there. So that's what I wanted to talk about. Little bit about, you know, simplifying Kubernetes the way we talk about. Little bit about databases and a little bit about our partnership. But I have one last thing. You can go start a cluster of cockroaches right now. First of all, that's me. I'm on Twitter as James. That's me everywhere. But I'll also give you this. This is like my one last thing. We published our first O'Reilly definitive guide and God, I was really happy that they gave us a cockroach because if it was like a lemur or something, that'd be really weird. But we got a cockroach on it. So if you wanna go check out and get a free book, if you wanna build out your O'Reilly library, see, that's when the phones come up with QR codes, everybody. Free books. Go check it out and try cockroaches today. So that is what I had. So thank you everybody.