 theCUBE presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Now what we're opening. Welcome to Valencia, Spain. In KubeCon, CloudNativeCon Europe 2022, I'm Keith Townsend along with my host, Paul Gillan, who is the senior editor for architecture at SiliconANGLE, Paul. Keith, you've been asking me questions all these last two days. Let me ask you one, you're a traveling man, you go to a lot of conferences. What's different about this one? You know what, we're just talking about that pre-conference. Open source conferences are usually pretty intimate. This is big. 7,500 people talking about complex topics all in one big area. I gotta say it's overwhelming. It's way more, it's not focused on a single company's product or messaging. It is about a whole ecosystem, very different show. And certainly some of the best t-shirts I've ever seen. And our first guest, Jim, has one of the better ones. I mean, a bit, cockroach, come on, right? Jim Walker, principal product evangelist at Cottworld DB. And Christian Honey, tech director of cloud technologies at FanLeap connect a financial services company that's based out of Germany, now offering services in four countries now? Basically all over Europe. But we're in three countries with offices. So you're a Cottworld DB customer and I got an extra obvious question. Databases are hard. In 2015, start company in 2015, Cottworld DB, been a customer since 2019 and I understand why take the risk on a four-year-old database? I mean, that just sounds like a world of risk and trouble. So it was in 2018 when we joined the company back then and we did this cloud-native transformation. That was our task, basically. We had a very limited amount of time and we were faced with a legacy infrastructure. And we needed something that would run in a cloud-native way and just blend in with everything else we had. And the idea was to go all in with Kubernetes. Though early days kind of, a lot of things were alpha-better and we were running on MySQL back then, on a VM, kind of small setup. And then we were looking for something that we could just deploy in Kubernetes alongside with everything else. And we had to, like, we had to stack and we had to duplicate it many times. So also to maintain that we wanted to do it all the same, like with GitOps and everything and Cockroach delivered that proposition. So that was why we evaluate the risk of relatively early adopting that solution with the proposition of having something that's truly cloud-native and really blends in with everything else we do in the same way was something we considered and then we jumped the leap of faith. The thin leap of faith. The thin leap of faith, exactly. And we were not dissatisfied. So talk to me a little bit about the challenges because when we think of MySQL, MySQL scales to amazing sizes. It is the de facto database for many cloud-based architectures. What problems were you running into? We were running into the problem that we essentially, as a FinTech company, we are regulated and we have companies or customers that really value running things like on-prem, private cloud, on-prem is a bit of a bad word maybe. So it's private cloud, hybrid cloud, private cloud in our own data centers in Frankfurt and we needed to run it in there. So we wanted to somehow manage that and with, so all of the managed solution were off the table, so we couldn't use them. So we needed something that ran in Kubernetes because we only wanted to maintain Kubernetes. We're a small team, didn't want to use also like full-blown VM solution of sorts. So that was that and the other thing was we needed something that was HA, distributable somehow. So we also looked into other solutions back at the time like Vitess, which is also prominent for having MySQL compliant interface and great solution. We also got it to work, but we figured, okay, this is from the scale and from the sheer amount of maintenance it would need, we couldn't deliver that. We were too small for that. So that's where then Cockroach just fitted in nicely by being able to, yeah, distribute, BHAB resilient against failure, but also be able to scale out because we had this problem like with a single MySQL deployment to not really, as it grew, as the data amounts grew, we had trouble to operate the fleet. So Jim, keep that under control. Jim, every time someone comes to me and says, I have a new database, I think we don't need yet another database. What problem, or how does Cockroach DB go about solving the types of problems that Christian had? Yeah, I mean, Christian laid out why it exists. I mean, look guys, building a database isn't easy. If it was easy, we'd have a database for every application, but you know, I mean, Michael Stonebreaker kind of Godfather all database says it himself. It takes seven, eight years for a database to fully gestate to be something that's like enterprise ready and kind of be relied upon. We've been building for about seven, eight years. I mean, I'm thankful for people like Christian to join us early on to help us kind of like troubleshoot and go through some things. We're building a database, it's not easy, you're right. But building a distributed system is also not easy. And so for us, you know, if you look at what's going on in just infrastructure in general, what's happening in, like this whole space is Kubernetes, it's all about automation. How do I automate scale? How do I automate resilience out of the entire, like the entire equation of what we're actually doing? I don't want to have to think about active passive systems. I don't want to think about sharding a database. Sure, you can scale MySQL, you know how many people it takes to run three or four shards of MySQL database? That's not automation. And I tell you what, in this world right now, with the advances in data and, you know, like how hard it is to find people who actually understand infrastructure to hire them, this is why this automation is happening because our systems are more complex. So, you know, we started from the very beginning to be something that was very different. This is a cloud native database. This is built with the same exact principles that are in Kubernetes. In fact, like Kubernetes is kind of a spawn of Borg, the back end of Google, we are inspired by Spanner. I mean, this is, you know, started by three engineers that were at Google or frustrated they didn't have the tools they had at Google. So they built something that was, you know, outside of Google. And how do we give that kind of Google-like infrastructure for everybody? And that's, you know, the advent of Cockroach and kind of why we're doing what we're doing. As your database has matured, you're now beginning a transition or you're in a transition to a serverless version. How are you doing that without disrupting the experience for existing customers? And why go serverless at all? Yeah, it's interesting. So, you know, serverless was a, it was kind of an R&D project for us and when we first started on the path because I think, you know, ultimately what we would love to do for the database is let's not even think about database, Keith. Like I don't want to think about the database. What we're building to is we want to, we want a SQL API in the cloud. That's it. I don't want to think about scale. I don't want to think about upgrades. I literally like, that stuff should just go away. That's what we need, right, as developers. I don't want to think about isolation levels or like, you know, give me DML and I want to be able to communicate. And for us, you know, the realization of that vision is like, if we're going to put a database on the planet for everybody to actually use it, we have to be really, really efficient. And serverless, which I believe really should be infrastructureless because I don't think we should be thinking of just about servers. We have to think about how do I take the context of regions out of this thing? How do I take the context of cloud providers out of what we're talking about? Let's just not think about that. Let's just go against something. Serverless was the answer. Now, we've been building for about a year and a half. We launched the serverless version of Cockroach last October. And we did it so that everybody in the public could have a free version of a database. And that's what serverless allows us to do. It's all consumption based up to certain limits and then you pay. But I think ultimately, and we spoke a little bit about this at the very beginning, I think as ISVs, people who are building software today, the serverless vision gets really interesting because I think what's on the mind of the CTO is, how do I drive down my costs to the cloud provider? And if we can basically drive down costs through either making things multi-tenant and super efficient, and then optimizing how much compute we use, spinning things down to zero and back up and auto scaling these sort of things in our software, we can start to make changes in the way that people are thinking about spend with the cloud provider. And ultimately, we did that so we could do things for free. So, Jim, I think I disagree with Christian, I'm sorry, Jim, I disagree with you just a little bit. Christian, I think the biggest challenge facing CTOs are people, getting the people to worry about cost and span and implementation. So as you hear the concepts of CoachDB moving to a serverless model and you're a large customer, how does that make you think or react to your people side of your resources? Well, I can say that from the people side of resources, luckily Cockroach is our least problem. So it just kind of, we always said it's an operator's dream because that was the part that just worked for us. So. And it's worked as you have scaled it without, you haven't. Yeah, I mean, we use it in a bit of a, we do not really scale out like the Cockroach, like really large. It's like more that we use it with the enterprise features of encryption in the stack. And our customers then demand, if they do so, we have disaster offering and we also do like dedicated stacks. So by having a fully cloud native solution on top of Kubernetes as the foundational layer, we can just use that and stamp it out and deploy that. How does that translate into services you can provide your customers? Are there services you can provide customers that you couldn't have if you were running, say MySQL? No, what we do is we run this, so the SaaS offering runs on our hybrid private cloud. And the other thing that we offer is that we run the entire stack at a cloud provider of their choosing. So they are on AWS, they give us an AWS account, we put it in there. Theoretically we could then also talk about using the serverless variant if they like so, but it's not strictly required for us. So, Christian, talk to me about that provisioning process because if I had a MySQL deployment before it, I can imagine how putting that into a cloud native type of repeatable CI CD pipeline or Ansible script, that could be difficult. Talk to me about that, how ControachDB enables you to create new onboarding experiences for your customers. So what we do is we use Helm charts all over the place as probably everybody else. And then each application team has their parts of services, they package them to Helm charts, they've wrapped this in a super chart that gets wrapped into the super super chart for the entire stack. And then at the right place, somewhere in between cockroaches added where it's a dependency. And as they just offer a Helm chart, that's as easy as it gets. And then what the teams do is they have an inner job that once you deploy all that, it would spin up and as soon as cockroaches ready, it's just the same reconciled loop as everything, it will then provision users, set up databases, schemas, do all that and initialize initial data sets that might be required for a new setup. So with that setup, we can spin up a new cluster and then deploy that stack chart in there and it takes some time and then it's done. So talk to me about lifecycle management because when I have one database, I have one scheme. When I have a lot of databases, I have a lot of different schemas. How do you keep your stack consistent across customers? That is basically part of the same story. We have GitOps all over the place, so we have this repository, we see the Super Helm chart versions and we maintain like minus three versions and ensure that we update the customers and keep them up to date. It's part of the contract sometimes down to the schedule of the customer at times. And Crockridge nicely supports also these updates with these migrations in the background. The schema migrations in the background. So we use, in our case, in that integration SQL Alchemy, which is also nicely supported. So there was also part of the story from SQL to Postgres was supported by the ORM, these kind of things. So the GitHub approach together with the ease of Helm charts and the background migrations of the schema is a very seamless upgrade operations. Before that, we had to have downtime. That's right, you could have online schema changes upgrading the database uses the same concept of rolling upgrades that you have in Kubernetes. It's just cloud native. It just fits that same context, I think. The camera know right now. Yeah. Jim, you mentioned the idea of a SQL API in the cloud. That's really interesting. Why does such a thing not exist? Because it's really difficult to build. You know, SQL API, what does that mean? Like, okay, what I'm going to, where does that endpoint live? Is there one in California and one on the East Coast, one in Europe, one in Asia? Okay, and I'm asking that endpoint for data. Where does that data live? Can you control where data lives on the planet? Because ultimately what we're fighting in software today in a lot of these situations is the speed of light. And so how do you intelligently place data on this planet so that, you know, when you're asking for data, when you're maybe home, it's a different latency than when you're here in Valencia. Does that data follow and move you? These are really, really difficult problems to solve. And I think we're at that layer of, we're at this moment in time in software engineering. We're solving some really interesting things because we are budding against this speed of light problem. And ultimately that's one of the biggest challenges. But underneath, it has to have all this automation, like the ease at which we can scale this database, like the always on resilient, the way that we can upgrade the entire thing with just rolling upgrades, like the cloud native concepts is really what's enabling us to do things at global scale. It's automation. Let's talk about that speed of light in global scale. There's no better conference for speed of light for scale than QCon. Any predictions coming out of the show? Yeah, it's less a prediction for me and more an observation, you guys. Like, look at two years ago when we were here in Barcelona at QCon EU. It was a lot of hype. It's a lot of hype. A lot of people walking around curious, fascinated. This is reality. The conversations I'm having with people today, there's a reality. There's people really doing, they're becoming cloud native. And to me, I think what we're going to see over the next two to three years is people start to adopt this kind of distributed mindset and it permeates not just with an infrastructure, but it goes up into the stack. We'll start to see much more developers using Go and these kind of the threaded languages because I think that distributed mindset, if it starts at the chip all the way to the fingertip of the person clicking and you're distributed everywhere in between, it is extremely powerful. And I think that's what Finley, I mean, that's exactly what the team is doing. And I think there's a lot of value and a lot of power in that. Jim, Christian, thank you so much for coming on theCUBE and sharing your story. You know what? We're past the hype cycle of Kubernetes. I agree. I was a non-believer in Kubernetes two, three years ago. It was mostly hype. We're looking at customers from Microsoft, Finley and competitors doing amazing things with this platform and cloud native in general. Stay tuned for more coverage of KubeCon from Valencia, Spain, I'm Keith Townsend along with Paul Gillan and you're watching theCUBE, the leader in high tech coverage.