>>Good evening, brilliant humans. My name is Savannah Peterson and very delighted to be streaming to you. Live from the Cube Studios here in Motor City, Michigan. I've got John Furrier on my left. John, this is our last interview of the day. Energy just seems to keep oozing. How >>You doing? Take two, Three days of coverage, the queue love segments. This one's great cuz we have a practitioner who's implementing all the hard core talks to be awesome. Can't wait to get into it. >>Yeah, I'm very excited for this one. If it's not very clear, we are a community focused community is a huge theme here at the show at Cape Con. And our next guests are actually a provider and a customer. Turning it over to you. Lisa and Jake, welcome to the show. >>Thank you so much for having us. >>It's great to be here. It is our pleasure. Lisa, you're with Cockroach. Just in case the audience isn't familiar, give us a quick little sound bite. >>We're a distributed sequel database. Highly scalable, reliable. The database you can't kill, right? We will survive the apocalypse. So very resilient. Our customers, mostly retail, FinTech game meet online gambling. They, they, they need that resiliency, they need that scalability. So the indestructible database is the elevator pitch >>And the success has been very well documented. Valuation obviously is a scorp guard, but huge customers. We were at the Escape 19. Just for the record, the first ever multi-cloud conference hasn't come back baby. Love it. It'll come back soon. >>Yeah, well we did a similar version of it just a month ago and I was, that was before Cockroach. I was a different company there talking a lot about multi-cloud. So, but I'm, I've been a car a couple of years now and I run community, I run developer relations. I'm still also a CNCF ambassador, so I lead community as well. I still run a really large user group in the San Francisco Bay area. So we've just >>Been in >>Community, take through the use case. Jake's story set us up. >>Well I would like Jake to take him through the use case and Cockroach is a part of it, but what they've built is amazing. And also Jake's history is amazing. So you can start Jake, >>Wherever you take >>Your Yeah, sure. I'm Jake, I'm CEO and co-founder of Offset. Oted is the commercial entity behind Spice Dvy and Spice Dvy is a permission service. Cool. So a permission service is something that lets developers and let's platform teams really unlock the full potential of their applications. So a lot of people get stuck on My R back isn't flexible enough. How do I do these fine grain things? How do I do these complex sharing workflows that my product manager thinks is so important? And so our service enables those platform teams and developers to do those kinds of things. >>What's your, what's your infrastructure? What's your setup look like? What, how are you guys looking like on the back end? >>Sure. Yeah. So we're obviously built on top of Kubernetes as well. One of the reasons that we're here. So we use Kubernetes, we use Kubernetes operators to orchestrate everything. And then we use, use Cockroach TV as our production data store, our production backend data store. >>So I'm curious, cause I love when these little matchmakers come together. You said you've now been presenting on a little bit of a road show, which is very exciting. Lisa, how are you and the team surfacing stories like Jakes, >>Well, I mean any, any place we can obviously all the social medias, all the blogs, How >>Are you finding it though? >>How, how did you Oh, like from our customers? Yeah, we have an open source version so people start to use us a long time before we even sometimes know about them. And then they'll come to us and they'll be like, I love Cockroach, and like, tell me about it. Like, tell me what you build and if it's interesting, you know, we'll we'll try to give it some light. And it's always interesting to me what people do with it because it's an interesting technology. I like what they've done with it. I mean the, the fact that it's globally distributed, right? That was like a really important thing to you. Totally. >>Yeah. We're also long term fans of Cockroach, so we actually all work together out of Workbench, which was a co-working space and investor in New York City. So yeah, we go way back. We knew the founders. I, I'm constantly saying like if I could have invested early in cockroach, that would've been the easiest check I could have ever signed. >>Yeah, that's awesome. And then we've been following that too and you guys are now using them, but folks that are out there looking to have the, the same challenges, what are the big challenges on selecting the database? I mean, as you know, the history of Cockroach and you're originating the story, folks out there might not know and they're also gonna choose a database. What's the, what's the big challenge that they can solve that that kind of comes together? What, what would you describe that? >>Sure. So we're, as I said, we're a permission service and per the data that you store in a permission service is incredibly sensitive. You need it to be around, right? You need it to be available. If the permission service goes down, almost everything else goes down because it's all calling into the permission service. Is this user allowed to do this? Are they allowed to do that? And if we can't answer those questions, then our customer is down, right? So when we're looking at a database, we're looking for reliability, we're looking for durability, disaster recovery, and then permission services are one of the only services that you usually don't shard geographically. So if you look at like AWS's iam, that's a global service, even though the individual things that they run are actually sharded by region. So we also needed a globally distributed database with all of those other properties. So that's what led us >>To, this is a huge topic. So man, we've been talking about all week the cloud is essentially distributed database at this point and it's distributed system. So distributed database is a hot topic, totally not really well reported. A lot of people talking about it, but how would you describe this distributed trend that's going on? What are the key reasons that they're driving it? What's making this more important than ever in your mind, in your opinion? >>I mean, for our use case, it was just a hard requirement, right? We had to be able to have this global service. But I think just for general use cases, a distributed database, distributed database has that like shared nothing architecture that allows you to kind of keep it running and horizontally scale it. And as your requirements and as your applications needs change, you can just keep adding on capacity and keep adding on reliability and availability. >>I'd love to get both of your opinion. You've been talking about the, the, the, the phases of customers, the advanced got Kubernetes going crazy distributed, super alpha geek. Then you got the, the people who are building now, then you got the lagers who are coming online. Where do you guys see the market now in terms of, I know the Alphas are all building all the great stuff and you guys had great success with all the top logos and they're all doing hardcore stuff. As the mainstream enterprise comes in, where's their psychology, what's on their mind? What's, you share any insight into your perspective on that? Because we're seeing a lot more of it folks becoming like real cloud players. >>Yeah, I feel like in mainstream enterprise hasn't been lagging as much as people think. You know, certainly there's been pockets in big enterprises that have been looking at this and as distributed sequel, it gives you that scalability that it's absolutely essential for big enterprises. But also it gives you the, the multi-region, you know, the, you have to be globally distributed. And for us, for enterprises, you know, you need your data near where the users are. I know this is hugely important to you as well. So you have to be able to have a multi-region functionality and that's one thing that distributed SQL lets you build and that what we built into our product. And I know that's one of the things you like too. >>Yeah, well we're a brand new product. I mean we only founded the company two years ago, but we're actually getting inbound interest from big enterprises because we solve the kinds of challenges that they have and whether, I mean, most of them already do have a cockroach footprint, but whether they did or didn't, once they need to bring in our product, they're going to be adopting cockroach transitively anyway. >>So, So you're built on top of Cockroach, right? And Spice dv, is that open source or? >>It >>Is, yep. Okay. And explain the role of open source and your business model. Can you take a minute to talk about the relevance of that? >>Yeah, open source is key. My background is, before this I was at Red Hat. Before that we were at CoreOS, so CoreOS acquisition and before that, >>One of the best acquisitions that ever happened for the value. That was a great, great team. Yeah, >>We, we, we had fun and before that we built Qua. So my co-founders and I, we built Quay, which is a, a first private docker registry. So CoreOS and, and all of those things are all open source or deeply open source. So it's just in our dna. We also see it as part of our go-to market motion. So if you are a database, a lot of people won't even consider what you're doing without being open source. Cuz they say, I don't want to take a, I don't want to, I don't want to end up in an Oracle situation >>Again. Yeah, Oracle meaning they go, you get you locked in, get you in a headlock, Increase prices. >>Yeah. Oh yeah, >>Can, can >>I got triggered. >>You need to talk about your PTSD there >>Or what. >>I mean we have 20,000 stars on GitHub because we've been open and transparent from the beginning. >>Yeah. And it >>Well, and both of your projects were started based on Google Papers, >>Right? >>That is true. Yep. And that's actually, so we're based off of the Google Zans of our paper. And as you know, Cockroach is based off of the Google Span paper and in the the Zanzibar paper, they have this globally distributed database that they're built on top of. And so when I said we're gonna go and we're gonna make a company around the Zabar paper, people would go, Well, what are you gonna do for Span? And I was like, Easy cockroach, they've got us covered. >>Yeah, I know the guys and my friends. Yeah. So the question is why didn't you get into the first round of Cockroach? She said don't answer that. >>The question he did answer though was one of those age old arguments in our community about pronunciation. We used to argue about Quay, I always called it Key of course. And the co-founder obviously knows how it's pronounced, you know, it's the et cd argument, it's the co cuddl versus the control versus coo, CTL Quay from the co-founder. That is end of argument. You heard it here first >>And we're keeping it going with Osted. So awesome. A lot of people will say Zeed or, you know, so we, we just like to have a little ambiguity >>In the, you gotta have some semantic arguments, arm wrestling here. I mean, it keeps, it keeps everyone entertained, especially on the over the weekend. What's, what's next? You got obviously Kubernetes in there. Can you explain the relationship between Kubernetes, how you're handling Spice dv? What, what does the Kubernetes piece fit in and where, where is that going to be going? >>Yeah, great question. Our flagship product right now is a dedicated, and in a dedicated, what we're doing is we're spinning up a single tenant Kubernetes cluster. We're installing all of our operator suite, and then we're installing the application and running it in a single tenant fashion for our customers in the same region, in the same data center where they're running their applications to minimize latency. Because of this, as an authorization service, latency gets passed on directly to the end user. So everybody's trying to squeeze the latency down as far as they can. And our strategy is to just run these single tenant stacks for people with the minimal latency that we can and give them a VPC dedicated link very similar to what Cockroach does in their dedicated >>Product. And the distributed architecture makes that possible because it's lighter way, it's not as heavy. Is that one of the reasons? >>Yep. And Kubernetes really gives us sort of like a, a level playing field where we can say, we're going going to take the provider, the cloud providers Kubernetes offering, normalize it, lay down our operators, and then use that as the base for delivering >>Our application. You know, Jake, you made me think of something I wanted to bring up with other guests, but now since you're here, you're an expert, I wanna bring that up, but talk about Super Cloud. We, we coined that term, but it's kind of multi-cloud, is that having workloads on multiple clouds is hard. I mean there are, they are, there are workloads on, on clouds, but the complexity of one clouds, let's take aws, they got availability zones, they got regions, you got now data issues in each one being global, not that easy on one cloud, nevermind all clouds. Can you share your thoughts on how you see that progression? Because when you start getting, as its distributed database, a lot of good things might come up that could fit into solving the complexity of global workloads. Could you share your thoughts on or scoping that problem space of, of geography? Yeah, because you mentioned latency, like that's huge. What are some of the other challenges that other people have with mobile? >>Yeah, absolutely. When you have a service like ours where the data is small, but very critical, you can get a vendor like Cockroach to step in and to fill that gap and to give you that globally distributed database that you can call into and retrieve the data. I think the trickier issues come up when you have larger data, you have huge binary blobs. So back when we were doing Quay, we wanted to be a global service as well, but we had, you know, terabytes, petabytes of data that we were like, how do we get this replicated everywhere and not go broke? Yeah. So I think those are kind of the interesting issues moving forward is what do you do with like those huge data lakes, the huge amount of data, but for the, the smaller bits, like the things that we can keep in a relational database. Yeah, we're, we're happy that that's quickly becoming a solved >>Problem. And by the way, that that data problem also is compounded when the architecture goes to the edge. >>Totally. >>I mean this is a big issue. >>Exactly. Yeah. Edge is something that we're thinking a lot about too. Yeah, we're lucky that right now the applications that are consuming us are in a data center already. But as they start to move to the edge, we're going to have to move to the edge with them. And it's a story that we're gonna have to figure out. >>All right, so you're a customer cockroach, what's the testimonial if I put you on the spot, say, hey, what's it like working with these guys? You know, what, what's the, what's the, you know, the founders, so you know, you give a good description, little biased, but we'll, we'll we'll hold you on it. >>Yeah. Working with Cockroach has been great. We've had a couple things that we've run into along the way and we've gotten great support from our account managers. They've brought in the right technical expertise when we need it. Cuz what we're doing with Cockroach is not you, you couldn't do it on Postgres, right? So it's not just a simple rip and replace for us, we're using all of the features of Cockroach, right? We're doing as of system time queries, we're doing global replication. We're, you know, we're, we're consuming it all. And so we do need help from them sometimes and they've been great. Yeah. >>And that's natural as they grow their service. I mean the world's changing. >>Well I think one of the important points that you mentioned with multi-cloud, we want you to have the choice. You know, you can run it in in clouds, you can run it hybrid, you can run it OnPrem, you can do whatever you want and it's just, it's one application that you can run in these different data centers. And so really it's up to you how do you want to build your infrastructure? >>And one of the things we've been talking about, the super cloud concept that we've been issue getting a lot of contrary, but, but people are leaning into it is that it's the refactoring and taking advantage of the services. Like what you mentioned about cockroach. People are doing that now on cloud going the lift and shift market kind of had it time now it's like hey, I can start taking advantage of these higher level services or capability of someone else's stack and refactoring it. So I think that's a dynamic that I'm seeing a lot more of. And it sounds like it's working out great in this situation. >>I just came from a talk and I asked them, you know, what don't you wanna put in the cloud and what don't you wanna run in Kubernetes or on containers and good Yeah. And the customers that I was on stage with, one of the guys made a joke and he said I would put my dog in a container room. I could, he was like in the category, which is his right, which he is in the category of like, I'll put everything in containers and these are, you know, including like mis critical apps, heritage apps, since they don't wanna see legacy anymore. Heritage apps, these are huge enterprises and they wanna put everything in the cloud. Everything >>You so want your dog that gets stuck on the airplane when it's on the tarmac. >>Oh >>God, that's, she was the, don't take that analogy. Literally don't think about that. Well that's, >>That's let's not containerize. >>There's always supply chain concern. >>It. So I mean going macro and especially given where we are cncf, it's all about open source. Do y'all think that open source builds a better future? >>Yeah and a better past. I mean this is, so much of this software is founded on open source. I, we wouldn't be here really. I've been in open source community for many, many years so I wouldn't say I'm biased. I would say this is how we build software. I came from like in a high school we're all like, oh let's build a really cool application. Oh you know what? I built this cuz I needed it, but maybe somebody else needs it too. And you put it out there and that is the ethos of Silicon Valley, right? That's where we grew up. So I've always had that mindset, you know, and social coding and why I have three people, right? Working on the same thing when one person you could share it's so inefficient. All of that. Yeah. So I think it's great that people work on what they're really good at. You know, we all, now you need some standardization, you need some kind of control around this whole thing. Sometimes some foundations to, you know, herd the cats. Yeah. But it's, it's great. Which is why I'm a c CF ambassador and I spend a lot of time, you know, in my free time talking about open source. Yeah, yeah. >>It's clear how passionate you are about it. Jake, >>This is my second company that we founded now and I don't think either of them could have existed without the base of open source, right? Like when you look at I have this cool idea for an app or a company and I want to go try it out, the last thing I want to do is go and negotiate with a vendor to get like the core data component. Yeah. To even be able to get to the >>Prototypes. NK too, by the way. Yeah. >>Hey >>Nk >>Or hire, you know, a bunch of PhDs to go and build that core component for me. So yeah, I mean nobody can argue that >>It truly is, I gotta say a best time if you're a developer right now, it's awesome to be a developer right now. It's only gonna get better. As we were riff from the last session about productivity, we believe that if you follow the digital transformation to its conclusion, developers and it aren't a department serving the business, they are the business. And that means they're running the show, which means that now their entire workflow is gonna change. It's gonna be have to be leveraging services partnering. So yeah, open source just fills that. So the more code coming up, it's just no doubt in our mind that that's go, that's happening and will accelerate. So yeah, >>You know, no one company is gonna be able to compete with a community. 50,000 users contributing versus you riding it yourself in your garage with >>Your dogs. Well it's people driven too. It's humans not container. It's humans working together. And here you'll see, I won't say horse training, that's a bad term, but like as projects start to get traction, hey, why don't we come together as, as the world starts to settle and the projects have traction, you start to see visibility into use cases, functionality. Some projects might not be, they have to kind of see more kind >>Of, not every feature is gonna be development. Oh. So I mean, you know, this is why you connect with truly brilliant people who can architect and distribute sequel database. Like who thought of that? It's amazing. It's as, as our friend >>You say, Well let me ask you a question before we wrap up, both by time, what is the secret of Kubernetes success? What made Kubernetes specifically successful? Was it timing? Was it the, the unambitious nature of it, the unification of it? Was it, what was the reason why is Kubernetes successful, right? And why nothing else? >>Well, you know what I'm gonna say? So I'm gonna let Dave >>First don't Jake, you go first. >>Oh boy. If we look at what was happening when Kubernetes first came out, it was, Mesosphere was kind of like the, the big player in the space. I think Kubernetes really, it had the backing from the right companies. It had the, you know, it had the credibility, it was sort of loosely based on Borg, but with the story of like, we've fixed everything that was broken in Borg. Yeah. And it's better now. Yeah. So I think it was just kind and, and obviously people were looking for a solution to this problem as they were going through their containerization journey. And I, yeah, I think it was just right >>Place, the timing consensus of hey, if we just let this happen, something good might come together for everybody. That's the way I felt. I >>Think it was right place, right time, right solution. And then it just kind of exploded when we were at Cores. Alex Povi, our ceo, he heard about Kubernetes and he was like, you know, we, we had a thing called Fleet D or we had a tool called Fleet. And he's like, Nope, we're all in on Kubernetes now. And that was an amazing Yeah, >>I remember that interview. >>I, amazing decision. >>Yeah, >>It's clear we can feel the shift. It's something that's come up a lot this week is is the commitment. Everybody's all in. People are ready for their transformation and Kubernetes is definitely gonna be the orchestrator that we're >>Leveraging. Yeah. And it's an amazing community. But it was, we got lucky that the, the foundational technology, I mean, you know, coming out of Google based on Go conferences, based on Go, it's no to coincidence that this sort of nature of, you know, pods horizontally, scalable, it's all fits together. I does make sense. Yeah. I mean, no offense to Python and some of the other technologies that were built in other languages, but Go is an awesome language. It's so, so innovative. Innovative things you could do with it. >>Awesome. Oh definitely. Jake, I'm very curious since we learned on the way and you are a Detroit native? >>I am. Yep. I grew up in the in Warren, which is just a suburb right outside of Detroit. >>So what does it mean to you as a Michigan born bloke to be here, see your entire community invade? >>It is, I grew up coming to the Detroit Auto Show in this very room >>That brought me to Detroit the first time. Love n a I a s. Been there with our friends at Ford just behind us. >>And it's just so interesting to me to see the accumulation, the accumulation of tech coming to Detroit cuz it's really not something that historically has been a huge presence. And I just love it. I love to see the activity out on the streets. I love to see all the restaurants and coffee shops full of people. Just, I might tear up. >>Well, I was wondering if it would give you a little bit of that hometown pride and also the joy of bringing your community together. I mean, this is merging your two probably most core communities. Yeah, >>Yeah. Your >>Youth and your, and your career. It doesn't get more personal than that really. Right. >>It's just been, it's been really exciting to see the energy. >>Well thanks for going on the queue. Thanks for sharing. Appreciate it. Thanks >>For having us. Yeah, thank you both so much. Lisa, you were a joy of ball of energy right when you walked up. Jake, what a compelling story. Really appreciate you sharing it with us. John, thanks for the banter and the fabulous questions. I'm >>Glad I could help out. >>Yeah, you do. A lot more than help out sweetheart. And to all of you watching the Cube today, thank you so much for joining us live from Detroit, the Cube Studios. My name is Savannah Peterson and we'll see you for our event wrap up next.

(bright upbeat music) >> Hello, and welcome back to the DockerCon 2021 virtual coverage. I'm John Furrie host of theCUBE here in Palo Alto with a remote interview with a great guest Cuban alumni, Jim Walker VP of Product Marketing at Cockroach Labs. Jim, great to see you remotely coming into theCUBE normally we're in person, soon we'll be back in real life. Great to see you. >> Great to see you as well John, I miss you. I miss senior live and in person. So this has got to do, I guess right? >> We we had the first multi-cloud event in New York city. You guys had was I think one of the last events that was going on towards the end of the year before the pandemic hit. So a lot's happened with Cockroach Labs over the past few years, accelerated growth, funding, amazing stuff here at DockerCon containerization of the world, containers everywhere and all places hybrid, pure cloud, edge everywhere. Give us the update what's going on with Cockroach Labs and then we'll get into what's going on at DockerCon. >> Yeah Cockroach Labs, this has been a pretty fun ride. I mean, I think about two and a half years now and John it's been phenomenal as the world kind of wakes up to a distributed systems and the containerization of everything. I'm happy we're at DockerCon talking about containerization 'cause I think it has radically changed the way we think about software, but more importantly it's starting to take hold. I think a lot of people would say, oh, it's already taken hold but if you start to think about like just, these kind of modern applications that are depending on data and what does containerization mean for the database? Well, Cockroach has got a pretty good story. I mean, gosh, before Escape I think the last time I talked to you, I was at CoreOS and we were playing the whole Kubernetes game and I remember Alex Povi talking about GIFEE Google infrastructure for everyone or for everyone else I should say. And I think that's what we've seen that kind of happened with the infrastructure layer but I think that last layer of infrastructure is the database. Like I really feel like the database is that dividing line between the business logic and infrastructure. And it's really exciting to see, just massive huge customers come to Cockroach to rethink what the database means in cloud, right? What does the database mean when we moved to distributed systems and that sort of thing, and so, momentum has been building here, we are, upwards of, oh gosh, over 300 paying customers now, thousands of Cockroach customers in the wild out there but we're seeing this huge massive attraction to CockroachCloud which is a great name. Come on, Johnny, you got to say, right? And our database as a service. So getting that out there and seeing the uptake there has just been, it's been phenomenal over the past couple of years. >> Yeah and you've got to love the Cockroach name, love it, survive nuclear war and winter all that good stuff as they say, but really the reality is that it's kind of an interesting play on words because one of the trends that we've been talking about, I mean, you and I've been telling this for years with our CUBE coverage around Amazon Web Services early on was very clear about a decade ago that there wasn't going to be one database to rule the world. They're going to many, many databases. And as you started getting into these cloud native deployments at scale, use your database of choice was the developer ethos just whatever it takes to get the job done. Now you start integrating this in a horizontally scalable way with the cloud, you have now new kinds of scale, cloud scale. And it kind of changed the game on the always on availability question which is how do I get high availability? How do I keep things running? And that is the number one developer challenge whether it's infrastructure as code, whether it's security shifting left, it all comes down to making sure stuff's running at scale and secure. Talk about that. >> Yeah, absolutely and it's interesting it's been, like I said, this journey in this arc towards distributed systems and truly like delivery of what people want in the cloud, it's been a long arc and it's been a long journey and I think we're getting to the point where people, they are starting to kind of bake resilience and scale into their applications and I think that's kind of this modern approach. Look we're taking legacy databases today. There are people are kind of lift and shift, move them into the cloud, try to run them there but they aren't just built for that infrastructure like the there's a fundamentally different approach and infrastructure when it talks, when you talk about cloud it's one of the reasons why John early on your conversations with the AWS Team and what they did, it's like, yeah, how do we give resilient and ubiquitous and always on scalable kind of infrastructure people. Well, that's great for those layers but when you start to get into the software that's running on these things, it isn't lift and shift and it's not even move and improve. You can't like just take a legacy system and change one piece of it to make it kind of take advantage of the scale and the resilience and the ubiquity of the cloud, because there's very very explicit challenges. For us, it's about re-architect and rebuild. Let's tear the database down and let's rethink it and build from the ground up to be cloud native. And I think the technologies that have done that, that have kind of built from scratch, to be cloud native are the ones that are I believe, three years from now that's what we're going to be talking about. I mean, this comes back to again, like the Genesis of what we did is Google Cloud Spanner. Spanner white paper and what Google did, they didn't build, they didn't use an existing database because they needed something for a transactional relational database. They hire a bunch of really incredible engineers, right? And I got like Jeff Dean and Sanjay Ghemawat over there, like designing and doing all these cool things, they build and I think that's what we're seeing and I think that's, to me the exciting part about data in the cloud as we move forward. >> Yeah, and I think the Google cloud infrastructure, everyone I think that's the same mindset for Amazon is that I want all the scale, but I don't want to do it like over 10 years I to do it now, which I love I want to get back to in a second, but I want to ask you specifically this definition of containerization of the database. I've heard that kicked around, love the concept. I kind of understand what it means but I want you to define it for us. What does it mean when someone says containerizing the database? >> Yeah, I mean, simply put the database in container and run it and that's all that I can think that's like, maybe step one I think that's kind of lift and shift. Let's put it in a container and run it somewhere. And that's not that hard to do. I think I could do that. I mean, I haven't coded in a long time but I think I could figure that out. It's when you start to actually have multiple instances of a container, right? And that's where things get really, really tricky. Now we're talking about true distributed systems. We're talking about how do you coordinate data? How do you balance data across multiple instances of a database, right? How do you actually have fail over so that if one node goes down, a bunch of them are still available. How do you guarantee transactional consistency? You can't just have four instances of a database, all with the same information in it John without any sort of coordination, right? Like you hit one node and you hit another one in the same account which transaction wins. And so the concepts in distributed systems around there's this thing called the cap theorem, there's consistency, availability, and partition tolerance and actually understanding how these things work especially for data in distributed systems, to make sure that it's going to be consistent and available and you're going to scale those things are not simple to solve. And again, it comes back to this. I don't think you can do it with legacy database. You kind of have to re-architect and it comes down to where data is stored, it comes down to how it's replicated, it comes down to really ultimately where it's physically located. I think when you deploy a database you think about the logical model, right? You think about tables, and normalization and referential integrity. The physical location is extremely important as we kind of moved to that kind of containerized and distributed systems, especially around data. >> Well, you guys are here at DockerCon 2021 Cockroach Labs good success, love the architectural flexibility that you guys offer. And again, bringing that scale, like you mentioned it's awesome value proposition, especially if people want to just program the infrastructure. What's going on with with DockerCon specifically a lot of talk about developer productivity, a lot of talk about collaboration and trust with containers, big story around security. What's your angle here at DockerCon this year? What's the big reveal? What's the discussion? What's the top conversation? >> Yeah, I mean look at where we are a containerized database and we are an incredibly great choice for developers. For us, it's look at there's certain developer communities that are important on this planet, John, and this is one of them, right? This is I don't know a developer doesn't have that little whale up in their status bar, right? And for us, you know me man, I believe in this tech and I believe that this is something that's driven and greatly simplify our lives over the next two to three to 10 to 15 years. And for us, it's about awareness. And I think once people see Cockroach, they're like oh my God, how did I ever even think differently? And so for us, it's kind of moving in that direction. But ultimately our vision where we want to be, is we want to abstract the database to a SQL API in the cloud. We want to make it so simple that I just have this rest interface, there's end points all over the planet. And as a developer, I never have to worry about scale. I never have to worry about DR right? It's always going to be on. And most importantly, I don't have to worry about low latency access to data no matter where I'm at on the planet, right? I can give every user this kind of sub 50 millisecond access to data or sub 20 millisecond access to data. And that is the true delivery of the cloud, right? Like I think that's what the developer wants out of the cloud. They want to code against a service like, and it's got to be consumption-based and you secure and I don't want to have to pay for stuff I'm not using and that all those things. And so, for us, that's what we're building to, and interacting in this environment is critical for us because I think that's where audiences. >> I want to get your thoughts on you guys do have success with a couple of different personas and developers out there, groups, classic developers, software developers which is this show is that DockerCon full of developers KubeCon a lot of operators cool, and some dads, but mostly cloud native operations. Here's a developer shops. So you guys got to hit the developers which really care about building fast and building the scale and last with security. Architects you had success with, which is the classic, cloud architecture, which now distributed computing, we get that. But the third area I would call the kind of the role that both the architects and the developers had to take on which is being the DevOps person or then becomes the SRE in the group, right? So most startups have the DevOps team developers. They do DevOps natively and within every role. So they're the same people provisioning. But as you get larger and an enterprise, the DevOps role, whether it's in a team or group takes on this SRE site reliability engineer. This is a new dynamic that brings engineering and coding together. It's like not so much an ops person. It's much more of like an engineering developer. Why is that role so important? And we're seeing more of it in dev teams, right? Seeing an SRE person or a DevOps person inside teams, not a department. >> Yeah, look, John, we, yeah, I mean, we employ an army of SREs that manage and maintain our CockroachCloud, which is CockroachDB as a service, right? How do you deliver kind of a world-class experience for somebody to adopt a managed service a database such as ours, right? And so for us, yeah I mean, SREs are extremely important. So we have personal kind of an opinion on this but more importantly, I think, look at if you look at Cockroach and the architecture of what we built, I think Kelsey Hightower at one point said, I am going to probably mess this up but there was a tweet that he wrote. It's something like, CockroachDB is the Spanner as Kubernetes is the board. And if you think about that, I mean that's exactly what this is and we built a database that was actually amenable to the SRE, right? This is exactly what they want. They want it to scale up and down. They want it to just survive things. They want to be able to script this thing and basically script the world. They want to actually, that's how they want to manage and maintain. And so for us, I think our initial audience was definitely architects and operators and it's theCUBE con crowd and they're like, wow, this is cool. This is architected just like Kubernetes. In fact, like at etcd, which is a key piece of Kubernetes but we contribute back up to NCD our raft implementation. So there's a lot of the same tech here. What we've realized though John, with database is interesting. The architect is choosing a database sometimes but more often than not, a developer is choosing that database. And it's like they go out, they find a database, they just start building and that's what happens. So, for us, we made a very critical decision early on, this database is wire compatible with Postgres and it speaks to SQL syntax which if you look at some of the other solutions that are trying to do these things, those things are really difficult to do at the end. So like a critical decision to make sure that it's amenable so that now we can build the ORMs and all the tools that people would use and expect that of Postgres from a developer point of view, but let's simplify and automate and give the right kind of like the platform that the SREs need as well. And so for us the last year and a half is really about how do we actually build the right tooling for the developer crowd too. And we've really pushed really far in that world as well. >> Talk about the aspect of the scale of like, say startup for instance, 'cause you made this a great example borg to Kubernetes 'cause borg was Google's internal Kubernetes, like thing. So you guys have Spanner which everyone knows is a great product at Google had. You guys with almost the commercial version of that for the world. Is there, I mean, some people will say and I'll just want to challenge you on this and we'll get your thoughts. I'm not Google, I'll never be Google, I don't need that scale. Or so how do you address that point because some people say, well this might dismiss the notion of using it. How do you respond to that? >> Yeah, John, we get this all the time. Like, I'm not global. My application's not global. I don't need this. I don't need a tank, right? I just need, like, I just need to walk down the road. You know what I mean? And so, the funny thing is, even if you're in a single region and you're building a simple application, does it need to be always on does it need to be available. Can it survive the failure of a server or a rack or an AZ it doesn't have to survive the failure of a region but I tell you what, if you're successful, you're going to want to start actually deploying this thing across multiple regions. So you can survive a backhoe hit in a cable and the entire east coast going out, right? Like, and so with Cockroach, it's real easy to do that. So it's four little SQL commands and I have a database that's going to span all those regions, right? And I think that's important but more importantly, think about scale, when a developer wants to scale, typically it's like, okay, I'm going to spin up Postgres and I'm going to keep increasing my instance size. So I'm going to scale vertically until I run out of room. And then I'm going to have to start sharding this database. And when you start doing that, it adds this kind of application complexity that nobody really wants to deal with. And so forget it, just let the database deal with all that. So we find this thing extremely useful for the single developer in a very small application but the beauty thing is, if you want to go global, great just keep that in notes. Like when that application does take off and it's the next breakthrough thing, this database going to grow with you. So it's good enough to kind of start small but it's the scale fast, it'll go global if you want to, you have that option, I guess, right? >> I mean, why wouldn't you want optionality on this at all? So clearly a good point. Let me ask you a question, take me through a use case where with Cockroach, some scenario develops nicely, you can point to the visibility of the use case for the developer and then kind of how it played out and then compare that and contrast that to a scenario that doesn't go well, like where where we're at plays out well, for an example, and then if they didn't deploy it they got hung up and went sideways. >> Yeah like Cockroach was built for transactional workloads. That that's what we are like, we are optimized for the speed of light and consistent transactions. That's what we do, and we do it very well. At least I think so, right. But I think, like my favorite customer of all of ours is DoorDash and about a year ago DoorDash came to us and said, look at we have a transactional database that can't handle the right volume that we're getting and falls over. And they they'd significant challenges and if you think about DoorDash and DoorDash is business they're looking at an IPO in the summer and going through these, you can't have any issues. So like system's got to be up and running, right? And so for them, it was like we need something that's reliable. We need something that's not going to come down. We need something that's going to scale and handle burst and these sort of things and their business is big, their businesses not just let me deliver food all the time. It's deliver anything, like be that intermediary between a good and somebody's front door. That's what DoorDash wants to be. And for us, yeah, their transactions and that backend transactional system is built on Cockroach. And that's one year ago, they needed to get experienced. And once they did, they started to see that this was like very, very valuable and lots of different workloads they had. So anywhere there's any sort of transactional workload be it metadata, be it any sort of like inventory, or transaction stuff that we see in companies, that's where people are coming to us. And it's these traditional relational workloads that have been wrapped up in these transactional relational databases what built for the cloud. So I think what you're seeing is that's the other shoe to drop. We've seen this happen, you're watching Databricks, you're watching Snowflake kind of do this whole data cloud and then the analytical side John that's been around for a long time and there's that move to the cloud. That same thing that happened for OLAP, is got to happen for OLTP. Where we don't do well is when somebody thinks that we're an analytic database. That's not what we're built for, right? We're optimized for transactions and I think you're going to continue to see these two sides of the world, especially in cloud especially because I think that the way that our global systems are going to work you don't want to do analytics across multiple regions, it doesn't make sense, right? And so that's why you're going to see this, the continued kind of two markets OLAP and OLTP going on and we're just, we're squaring that OLTP side of the world. >> Yeah talking about the transaction processing side of it when you start to change a distributed architecture that goes from core edge, core on premises to edge. Edge being intelligent edge, industrial edge, whatever you're going to have more action happening. And you're seeing, Kubernetes already kind of talking about this and with the containers you got, so you've got kind of two dynamics. How does that change the nature of, and the level of volume of transactions? >> Well, it's interesting, John. I mean, if you look at something like Kubernetes it's still really difficult to do multi-region or multicloud Kubernetes, right? This is one of those things that like you start to move Kubernetes to the edge, you're still kind of managing all these different things. And I think it's not the volumes, it's the operational nightmare of that. For us, that's federate at the data layer. Like I could deploy Cockroach across multiple Kubernetes clusters today and you're going to have one single logical database running across those. In fact you can deploy Cockroach today on top of three public cloud providers, I can have nodes in AWS, I could have nodes in GCP, I could have nodes running on VMs in my data center. Any one of those nodes can service requests and it's going to look like a single logical database. Now that to me, when we talked about multicloud a year and a half ago or whatever that was John, that's an actual multicloud application and delivering data so that you don't have to actually deal with that in your application layer, right? You can do that down in the guts of the database itself. And so I think it's going to be interesting the way that these things gets consumed and the way that we think about where data lives and where our compute lives. I think that's part of what you're thinking about too. >> Yeah, so let me, well, I got you here. One of the things on my mind I think people want to maybe get clarification on is real quick while you're here. Take a minute to explain that you're seeing a CockroachDB and CockroachCloud. There are different products, you mentioned you've brought them both up. What's the difference for the developers watching? What's the difference of the two and when do I need to know the difference between the two? >> So to me, they're really one because CockroachCloud is CockroachDB as a service. It's our offering that makes it a world-class easy to consume experience of working with CockroachDB, where we take on all the hardware we take on the SRE role, we make sure it's up and running, right? You're getting connection, stringing your code against it. And I think, that's side of our world is really all about this kind of highly evolved database and delivering that as a service and you can actually use it's CockroachDB. I think it was just gets really interesting John is the next generation of what we're building. This serverless version of our database, where this is just an API in the cloud. We're going to have one instance of Cockroach with multi-tenant database in there and any developer can actually spin up on that. And to me, that gets to be a really interesting world when the world turns serverless, and we have, we're running our compute in Lambda and we're doing all these great things, right? Or we're using cloud run and Google, right? But what's the corresponding database to actually deal with that? And that to me is a fundamentally different database 'cause what is scale in the serverless world? It's autonomous, right? What scale in the current, like Cockroach world but you kind of keep adding nodes to it, you manage, you deal with that, right? What does resilience mean in a serverless world? It's just, yeah, its there all the time. What's important is latency when you get to kind of serverless like where are these things deployed? And I think to me, the interesting part of like the two sides of our world is what we're doing with serverless and kind of this and how we actually expose the core value of CockroachDB in that way. >> Yeah and I think that's one of the things that is the Nirvana or the holy grail of infrastructure as code is making it, I won't say irrelevant, but invisible if you're really dealing with a database thing, hey I'm just scaling and coding and the database stuff is just working with compute, just whatever, how that's serverless and you mentioned Lambda that's the action because you don't want the file name and deciding what the database is just having it happen is more productivity for the developers that kind of circles back to the whole productivity message for the developers. So I totally get that I think that's a great vision. The question I have for you Jim, is the big story here is developer simplicity. How you guys making it easier to just deploy. >> John is just an extension of the last part of the conversation. I don't want to developer to ever have to worry about a database. That's what Spencer and Peter and Ben have in their vision. It's how do I make the database so simple? It's simple, it's a SQL API in the cloud. Like it's a rest interface, I code against it, I run queries against it, I never have to worry about scaling the thing. I never have to worry about creating active, passive, and primary and secondary. All these like the DevOps side of it, all this operation stuff, it's just kind of done in the background dude. And if we can build it, and it's actually there now where we have it in beta, what's the role of the cost-based optimizer in this new world that we've had in databases? How are you actually ensuring data is located close to users and we're automating that so that, when John's in Australia doing a show, his data is going to follow him there. So he has fast access to that, right? And that's the kind of stuff that, we're talking about the next generation of infrastructure John, not like we're not building for today. Like, look at Cockroach Labs is not building for like 2021. Sure, do we have something that's great. We're building something that's 22 and 23 and 24, right? Like what do we need to be as a extremely productive set of engineers? And that's what we think about all day. How do we make data easy for the developer? >> Well, Jim, great to have you on VP of Product Marketing at Cockroach Labs, we've known each other for a long time. I got to ask you while I had got you here final question is, you and I have chatted about the many waves of in open source and in the computer industry, what's your take on where we are now. And I see you're looking at it from the Cockroach Labs perspective which is large scale distributed computing kind of you're on the new side of history, the right side of history, cloud native. Where are we right now? Compare and contrast for the folks watching who we're trying to understand the importance of where we are in the industry, where are we in and what's your take? >> Yeah John I feel fortunate to be in a company such as this one and the past couple that I've like been around and I feel like we are in the middle of a transformation. And it's just like the early days of this next generation. And I think we're seeing it in a lot of ways in infrastructure, for sure but we're starting to see it creep up into the application layer. And for me, it is so incredibly exciting to see the cloud was, remember when cloud was like this thing that people were like, oh boy maybe I'll do it. Now it's like, it's anything net new is going to be on cloud, right? Like we don't even think twice about it and the coming nature of cloud native and actually these technologies that are coming are going to be really interesting. I think the other piece that's really interesting John is the changing role of open source in this whole game, because I think of open source as code consumption and community, right? I think about those and then there's license of course, I think people were always there. A lot of people wrapped around the licensing. Consumption has changed, John. Back when we were talking to Dupe, consumption was like, oh, it's free, I get this thing I could just download it use it. Well consumption over the past three years, everybody wants everything as a service. And so we're ready to pay. For us, how do we bring free back to the service? And that's what we're doing. That's what I find like I am so incredibly excited to go through this kind of bringing back free beer to open source. I think that's going to be great 'cause if I can give you a database free up to five gig or 10 gig, man and it's available all over the planet has fully featured, that's coming, that's bringing our community and our code which is all open source and this consumption model back. And I'm super excited about that. >> Yeah, free beer who doesn't like free beer of course, developers love free beer and a great t-shirt too that's soft. Make sure you get that, get the soft >> You just don't want free puppy, you know what I mean? It was just like, yeah, that sounds painful. >> Well Jim, great to see you remotely. Can't wait to see you in person at the next event. And we've got the fall window coming up. We'll see some events. I think KubeCon in LA is going to be in-person re-invent a data breast for sure we'll be in person. I know that for a fact we'll be there. So we'll see you in person and congratulations on the work at Cockroach Labs. >> Thanks, John, great to see you again. All right, this keep coverage of DockerCon 2021. I'm John Furrie your host of theCUBE. Thanks for watching.