 TheCube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain, KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend, your host and we're continuing the conversations around ecosystem, cloud native, 7,500 people here, and 70 plus show for sponsors. It is for open source conference, I think the destination. I might even premise that this may be, this may eventually roll to the biggest tech conference in the industry, maybe outside of AWS re-invent. My next guest is Nick VanRiggin. Riggerin. Riggerin. VP Engineering of PlanetSkill. Nick, I'm going to start off the conversation right off the bat. PlanetSkill, CloudNative Database, why do we need another database? Well, why don't you need another database? I mean, are you happy with yours? Is anyone happy with theirs? That's a good question. I don't think anyone's quite happy with, I don't know, I've never seen a excited database user except for guys with really or gout, guys with gray beards or one way gray hair, maybe. Yeah, outside of the dungeon I think no one really is happy with their database and that's what we're here to change. We're not just building the database, we're actually building the whole kind of start to finish experience so that people can get more done. So what do you mean by getting more done? Because MySQL has been the underpinnings of like massive cloud database deployments. It has been the de facto standard for cloud databases. What is PlanetSkill doing and enabling us to do that I can't do with something like a MySQL or a SQL server? Great question. So we are MySQL compatible, so under the hood it's a lot of the MySQL you know and love but on top of that we've layered workflows, we've layered scalability, we've layered serverless so that you can get all of the parts of the MySQL, that dependability, the thing that people have used for 20, 30 years, right? People don't even know a world before MySQL but then you also get this ability to make schema changes faster so you can kind of do your work quicker, get to the business objectives faster. You can scale farther so when you get to your MySQL and you say well you know can we handle adding this one feature on top, can we handle the user growth we've got? You don't have to worry about that either. So it's kind of the best of both worlds. We've got one foot in history and we've got one foot in the new kind of cloud native database world. We want to give everyone the best of both. So when I think of serverless because that's a buzzy word. But when I think of serverless I think about developers being able to write code, deploy the code, not worry about VM sizes, amount of disk base, CPU, et cetera. But we're talking about databases. I got to describe what type of disk I want to use. I got to describe the performance levels. I got all the descriptive stuff that I have to do about infrastructures. Databases are not serverless. They're a further thing from it. So despite what the name may say I can guarantee you're a planet scale database that does run on at least one server. Usually more than one. But the idea is exactly what you said. So especially when you're starting off when you're first beginning your let's say database journey that's a word I use a lot. The furthest thing from your mind is how many CPUs do I need? How many disk IOs do I need? How much memory do I need? What we want you to be able to do is get started on focusing on shipping your code, right? The same way that Lambda, the same way that Kubernetes and all of these other cloud native technologies just help people get done what they want to get done. Planet scale is the same way. You want a database, you sign up, you click two buttons, you've got a database, we'll handle scaling the disk as you grow, we'll handle giving you more resources. And when you get to a spot where you're really starting to think about my database has got hundreds of gigabytes or petabytes, terabytes, that's when we'll start to talk to you a little bit more about, hey, you know it really does run on a server, we can get to help you with the capacity planning. But there's no reason people should have to do that up front. I mean that stinks. When you want to use a database you want to use a database. You don't want to use a 747 with 27 different knobs. You just want to get going. So also when I think of serverless and cloud native, I think of stateless. Now there's stateless with databases. Help me reconcile like when you say it's cloud native. How is it cloud native when I think a cloud native is stateless? So it's cloud native because it exists where you want it in the cloud, right? No matter where you've deployed your application on your own cloud, on a public cloud or something like that, our job is to meet you and match the same level of velocity and the same level of change that you've got on your kind of cloud native setup. So there's a lot of state, right? We are your state and that's a big responsibility. And so what we want to do is we want to let you experiment with the rest of the stateless workloads and be right there next to you so that you can kind of get done what you need to get done. All right, so this concept of clicking two buttons and deploying, it's a database. It has to run somewhere. So let's say that I'm in AWS, I have AWS VPC. What does it look like from a developer's perspective to consume the service? So we've got a couple of different offerings and AWS is a great example. So at the very kind of the most basic database unit, you click, you get an endpoint, a host name, a password and a username. You feed that right into your application and it's TLS secure and stuff like that. Goes right into the database, no problem. As you grow larger and larger, we can use things like AWS private link and stuff like that to actually start to integrate more with your AWS environment, all the way over to what we call planet scale managed, which is where we actually deploy your data plane in your AWS account. So you give us some permissions and we kind of create a sub account and stuff like that. And we can actually start sending pods and whole clusters and stuff like that into your AWS account, give you a private link so that everything looks like it's kind of wrapped up in your ownership. But you still get the same kind of planet scale cloud experience, cloud native experience. So how do I make calls to the database? So I mean, do I have to install a new? Great question. Like agent or do some weird SQL configuration on my end? Like what's the experience? Nope, we just speak my SQL. Same way you'd go, you know, brew install my SQL if you're on a Mac or apt get install my SQL on a Linux PC. You just username, password, database name and stuff like that. You feed that into your app and it just works. All right, so databases are typically security. My security person sees a new database all they get excited. They're like, oh my job just got real easy. I can find like eight or nine different findings. How do you help me with compliance in answering these tough security questions from security? Great question. So security is at the core of what we do, right? We've got security people ourselves. We do the same thing for all the new vendors that we onboard. So we invest a lot. For example, the only way you can connect to a planet scale database, even if you're using private link, even if you're not touching the public internet at all is over TLS secured endpoint, right? From the very first day, the very first beta that we had, we knew not a single byte goes over the internet that's not encrypted. It's encrypted at rest. We have audit logging. We do a ton internally as well to make sure that what's happening to your database is something you can find out. The favorite thing that I think though is all your schema changes are tracked on planet scale because we provide an entire workflow for your schema changes. We actually have, you know, like a GitHub pull request style thing. Your security folks can actually look and say what changes were made to the database day in, day out. They can go back and there's a full history of that log. So you actually have, I think better security than a lot of other databases where you know you've got to build all these tools and stuff like that. It's all built into planet scale. So we started out the conversation with two clicks, but I'm a developer and I'm developing a service at scale. I want to have a SaaS offering. How do I automate the deployment of the database in the management of the database across multiple customers? Yeah, so everything's API driven. We've got an API that you can use to provision databases, to make schema changes, to make, you know, whatever changes you want to that database. We have an API that powers our website, the same API that customers can use to kind of automate any part of the workflow that they want. There's actually someone who did a talk earlier using I think crossplane.io where they can use Kubernetes custom resource definitions to provision planet scale databases completely automatically. So you can even do it as part of your standard deployment workflow. Just create a planet scale database, create a password, inject it in your app, all automatically. So Nick, as I'm thinking about scale, I'm thinking about multiple customers. I have a successful product. And now these customers are coming to me with different requirements. One customer wants to upgrade once every quarter. Another one, it's like, you know what? Just bring it on. Like bring the schema changes on. I want the latest features, et cetera. How do I manage that with planet scale? When I'm thinking about MySQL, that can be a little difficult. But how does planet scale help me solve that problem? Yeah, so again, I think it's that same workflow engine that we've built. Every database has its own kind of deploy queue, its own migration system. So you can automate all these processes and say on this database, I want to change this schema this way. On this database, I'm going to hold off. You can use our API to drive a view into like, well, what's the schema on this database? What's the schema on this database? What version am I running on this database? And you can actually bring all that in. And if you were really successful, you'd have this single pane of glass where you can see what's the status of all my databases and how are they doing? All powered by kind of the planet scale API. So we can't talk about databases without talking about backup and recovery. How do I back this thing up and make sure that I can fall back? I've, someone deleted a table. It happens all the time in production. How do I recover from it? So there's two pieces to this. And I'm going to talk about two different ways that we can help you solve this problem. One of them is every planet scale database comes with backups built in and we test them fairly often, right? We use these backups. We actually give you a free daily backup on every database, because it's important to us as well. We want to be able to restore from backup. We want to be able to do failovers and stuff like that. All that's handled automatically. The other thing though is this feature that we launched in March called the planet scale rewind. And what rewind is is actually a schema migration undo button. So let's say you're a developer, you're dropping a table or a column. You mean to drop this, but you dropped the other one on accident. Or you thought this column was unused, but it wasn't. You know when you do something wrong, you cause an incident and you get that sick feeling in your stomach, you know. I've pulled a drive that was not rate five. Exactly. And you kind of start to go, oh man, what am I going to do next? You know, everyone watching this right now is probably squirming in their seat a bit. You know the feelings. Yeah, I know the feelings. Well, planet scale gives you an undo button. So you can click undo migration for 30 minutes after you do the migration and we'll revert your schema with all the data in it back to what your database looked like before you did that migration. Drop a column on accident, drop a table on accident, click the rewind button. There's all the data there. And the new rights that you've taken while that's happened are there as well. So it's not just a restore to a point in time backup. It's actually that we've replicated your rights, sent them to both the old and the new schema and we can get you right back to where you started downtime solved. So, go ahead. DBAs are DBAs whether they've become now reformed DBAs that are cloud architects, but they're DBAs. So there's a couple of things that they're going to want to know. How do I get my zero backup in my hands? I want my, this is my SQL data. I want my SQL backup. Yeah, so you can just take backups off the database yourself the same way that you're doing today, right? My SQL dump, my SQL backup and all of those kinds of things. If you don't trust PlanetScale and look, I'm all about backups, right? You want them in two different data centers on different mediums. You can just add on your own backup tools that you have right now and also use that. I'd like you to trust that PlanetScale has the backups as well, but if you want to keep doing that and run your own system, we're totally cool with that as well. In fact, I'd go as far as to say I recommend it. You never have too many backups. So in a moment, we're going to run KubeClock. So get, you know, get your, get, you know, stand tall. I'll get ready. You know, I'm gonna, you know. I'm tall, I'm tall. We're both tall. The last question before KubeClock is, let's talk little nerve knobs. Okay. The reform DBA. Yeah. They want, they're, they're like, oh, this, this, this Curie ran a little bit slow. I know I could squeeze a little bit more out of that. Who do they talk to? Yeah. So that's a great question. So we provide you some insights on the product itself, right? So you can take a look and see how are my queries performing and stuff like that. Our goal, our job is to surface to you all the metrics that you need to make that decision. Cause at the end of the day, reform DBA or not, it is still a skill to analyze the performance of a MySQL query, run and explain, you know, kind of figure all that out. We can't do all of that for you. So we want to give you the information you need, either knowledge or, you know, stuff to learn, whatever it is, because some of it does have to come back to, what's my schema? What's my query? And how can I optimize it? I'm missing an index and stuff like that. All right. So you're early adopter of the KubeClock. Okay. I have to, people say they're ready. Ooh, okay. All the time, people say they're ready. But I'm not quite sure that they're ready. So are you ready? Do I have any other choice? No, you don't. Then I am. But are you ready? Sure, let's go. All right. Start the KubeClock. All right. What do you want me to do? Go? All right. You said you were ready. I'm ready, all right, I'm ready, all right. Okay, I'll give you, I'll give you, see people say they're ready. You're right, you're right. Start the KubeClock, go. Okay. Are you happy with how your database works? Are you happy with the velocity? Are you happy with what your engineers and what your teams can do with their database? Follow the dream, not the, follow the dream, not the dream. You gotta be able to deliver, at the end of the day, you gotta deliver what the business wants. It's not about performance. You gotta crawl before you crawl. You gotta crawl. You gotta crawl. It's not just about as my query fast. It's not just about as my query right. It's about, are my customers getting what they want? You're here. You deserve a seat at the table. And that's what PlanetScale provides, right? PlanetScale is a tool for getting done what you need to get done as a business. That's what we're here for ultimately. We want to be the best database for developing software. That's it, end of day. Nick, you took a shot. I'm buying it. Great job. You know, this is fun. Our jobs are complex. Yep. Databases are hard. Yep. It is where your organization keeps the most valuable assets that you have. 100%. And we are having these tough conversations. Yep. Here in Valencia, you're talking to the leader in tech coverage. From Valencia, Spain, I'm Keith Townsend and you're watching The Cube, the leader in high tech coverage.