(upbeat intro music) >> Good afternoon, fellow tech nerds. My name is Savannah Peterson, coming to you from theCube's Remote Studio here in Motown, Detroit, Michigan where we are at KubeCon. John, this is our 12th interview of the day. How are you feeling? >> I'm feeling fresh as the first interview. (Savannah laughs) As always. >> That delivery really implied a level of freshness. >> Let's go! No, this is only Day 1. In three days, reinvent. We go hardcore. These are great events. We get so much great content. The conversations are amazing. The guests are awesome. They're technical, they're smart, and they're making the difference in the future. So, this next segment about Scale MySQL should be awesome. >> I am very excited to introduce our next guest who actually has a Twitter handle that I think most people, at least of my gender in this industry would love to have. She is @ATechGirl. So you can go ahead and tweet her and tell her how great this interview is while we're live. Please welcome Deepthi Sigireddi. Thank you so much for being here with us. >> Thank you for having me. >> You're feeding us in. You've got two talks you're giving while we're here. >> Yes, yes. So tomorrow we will be talking about VTR, myself and one of the other maintainers of Vitess and on Friday we have the Vitess Maintainer Talk. All graduated projects get a maintainer talk. >> Wow, so you are like KubeCon VIP celebrity. >> Well, I hope so. >> Well, you're a maintainer and technical lead, also software engineer at the PlanetScale. But talk about the graduation process where that means to the project and the people involved. >> So Vitess graduated in 2019 and there are strict criteria for graduation and you don't just have to meet the minimum, you sort of have to over perform on the graduation criteria. Some of which are like there must be at least two large production deploys and people from those companies have to go in front of the CNCF committee that approves these things and say that, "Yes, this project is critical to our business." >> A lot of peer review, a lot of deployment success. >> Yes. >> Good consistency in the code. >> Deepthi: Community diversity. >> All that. >> All those things. >> Talk about the importance of this project. What is the top story that people should know about around the project? Why it exists, why it's important, why it's relevant, why it's cool. How would you answer that? >> So MySQL is now 30 years old and yet they are still- >> Makes me feel a little sidebar. (Deepthi laughs) Yeah. >> And yet even though there are many other newer databases, it continues to be used at many of the largest internet scale companies. And some of them, for example, Slack, GitHub, Square, they have grown to a level where they could not have if they had tried to do it with Vanilla MySQL that they started with, and the only reason they are where they are is Vitess. So that is I think the number one thing people should know about Vitess. >> And the origination story on notes say "Came from YouTube." >> Yes. So the way Vitess started was that YouTube was having problems with their MySQL deployment and they got tired of dealing with the site being down. So the founders of Vitess decided that they had to do something about it and they started building Vitess which started as a pretty small, relatively code-based with limited features, and over time they built charting and all of the other things that we have today. >> Well, this is exciting Savannah because we've seen this industry. Like with Facebook, when they started, everyone built their own stuff. MySQL was a great- >> Oh gosh, and everyone wanted to build it their way, reinventing the wheel. >> And MySQL was great. And then as it kind of broke when it grew, it got retrofitted. So, it was constantly being scaled up to the point where now you guys, if I get this right, said, "Hey, we're going to work on this. We're going to make it next-gen." So it's kind of like next-gen MySQL. Almost. >> Yes, yes. I would say that's pretty accurate, yeah. So there are still large companies which run their own MySQL and they have scaled it in their own way, but Vitess happens to be an open source way of scaling MySQL that people can adopt without having to build all of their own tooling around it. >> Speaking of that and growing, you just announced a new version today. >> Yes, yes. >> Tell us about that. >> The focus in this version was to make Vitess easier to use and to deploy. So in the past, there was one glaring gap in Vitess which was that Vitess did not automatically detect and repair MySQL level failures. With this release, we've actually closed that gap. And what that means for people using Vitess is that they will actually spend less time dealing with outages manually, or less human intervention, More automated recovery is what it means. The other thing we've released today is a new web UI. Vitess had a very old web UI, ugly, hard to maintain. Nobody liked it. But it was functional, except we couldn't add anything new to it because it was so old. So, the backend functionality kept advancing but the front end was kind of frozen. Now we have a next generation UI to which in upcoming releases we can add more and more functionality. >> So, it's extensible. They add things in. >> Deepthi: Oh yes, of course. Yeah. >> Awesome. What's the biggest thing that you like about the new situation? Is it more contributors are on board the UI? What's the fresh new impact that's happening in the community? What's getting you excited about with the current project? And the UI's great 'cause usability is important. >> Deepthi: Right. >> Scalability is important. >> I think Vitess solved the scalability problem way early and only now we are really grappling with the usability problem. So the hope and the desire is to make Vitess autopilot so that you reduce human intervention to a minimum once you deploy it. Obviously, you have to go through the process of deploying it. But once you've deployed it, it should just run itself. >> Runs at scale. So, the scale's huge? >> Deepthi: Yes. >> How many contributors are involved in the project? Can you give some numbers? Do you have any handy that you can speak to? >> Right. So, CNCF actually tracks these statistics for all the projects and we consolidated some numbers for the last two full calendar years, 2020 and 2021. We had over 400 contributors and 200 plus of them contributed code and the others contributed documentation issues, website changes, and things like that. So that gives- >> How about downloads? Download's good? >> Oh, okay. So we started publishing the current official Vitess Docker Image in 2018. And by October of 2020, we had about 3.8 million downloads. And by August of 2021, we had 5.2 million. And today, we have had over 10 million downloads- >> Wow! >> Of the main image. >> Starting to see a minute of that hockey stick that we all like to see. Seems like you're very clearly a community-first leader and it seems like that's in the PlanetScale and the test's DNA. Is that how the whole company culture views it? Would you say it's community-first business? >> PlanetScale is very much committed to Vitess as an open source project and to serving the Vitess community. So as part of my role at PlanetScale, some of the things I do are helping new contributors whether they are from PlanetScale or from outside PlanetScale. A number of PlanetScale engineers who don't work full-time on Vitess still contribute bug fixes and features to Vitess. We spend a significant amount of our energy helping users in our community Slack. The releases we do are mainly for the benefit of the community and PlanetScale is making those releases because for Planet Scale... Within PlanetScale, we actually do separate releases versus the public ones. >> One of the things that's coming up here at the show is deploying on Kubernetes. How does that look like? Everyone wants ease of use. Are you guys easy to use? >> Yes, yes. So PlanetScale also open sourced a Kubernetes operator for Vitess that people outside PlanetScale are using to run their production deployments of Vitess. Prior to that, there were Vitess users who actually built their own Kubernetes deployments of Vitess and they are still running those, but new users and new adopters of Vitess tend to use the Kubernetes operator that we are publishing. >> And you guys are the managed service for Vitess for the people that that's the business model for PlanetScale. >> Correct. So PlanetScale has a serverless database on demand which is built on Vitess. So if someone's starting something new and they just need a database, you sign up. It takes 30 seconds to get a database. Connect to it and start doing things with it. Versus if you are a large enterprise and you have a huge database deployment, you can migrate to PlanetScale, import all of your existing data, cut over with minimal downtime and then go, and then PlanetScale manages that. >> And why would they do that? What's the use case for that? Save time new development team or refactoring? >> Save time not being able to hire people with the skills to run it in-house. Not wanting to invest engineering resources in what businesses think is not their core competency. They want to focus on their business value. >> So, this database is a service in their whatever they're doing without adding more costs. >> Right. >> And speed. Okay, cool. How's that going? >> It's going well. >> Any feedback from customers in terms of why that there are any benefit statements you seek popping out? What are the big... What's the big aha when they... When people realize what they have here, what's the aha moment for them? Do they go, "Wow, this is awesome. It's so easy. Push a button. Migrate." Or is it... >> All of those. And people have actually seen cost savings when they've migrated from Amazon RDS to PlanetScale and we have testimonials from people who've said that, "It was so easy to use PlanetScale. Why would we try to do it ourselves?" >> It's the best thing a customer could say, right? We're all about being painkillers and solving some sort of problem. I think that that's a great opportunity to let you show off some of your customers. So, who is receiving this benefit? 'Cause I know PlanetScale specifically is for a certain style of business. >> Hmm. We have a list of customers on the website. >> Savannah: I was going to say you have a really- >> John: She's a software engineer. She's not marketing. >> You did sexy. >> You're doing a great job as much as marketing. >> So the reason I am bringing this up is because it's clear this is a solution for companies like Square, SoundCloud, Etsy, Jordan, and other exciting brands. So when you're talking about companies at scale, these companies are very much at scale, which is awesome. >> Yeah. >> What's next? What do you guys see the future for the project? >> I think we talked about that a little bit already. So, usability is a big thing. We did the new UI. It's not complete, right? Because over the last four years we've built more features into the backend which you can't yet access from the UI. So we want to be able for people to use things like online schema changes which is a big feature of Vitess. Doing schema changes without downtime from the UI. So, schema management from the UI. Vitess has something called VReplication which is the core technology that enables charting. And right now you can from the UI monitor your charting status, but you can't actually start charting from the UI. So more of the administrative functions we want to enable from the UI. >> John: Awesome. >> Last question. What are you personally most excited about this week being here with our wonderful community? >> I always enjoy being at KubeCon. This is my fifth or sixth in-person and I've done a couple of virtual ones. >> Savannah: Awesome. >> Because of the energy, because you get to meet people in person whom previously you've only met in Slack or maybe in a monthly community Zoom calls. We always have people come to our project booth. We have a project booth here for Vitess. People come to the company booth. PlanetScale has a booth. People come to our talks, ask questions. We end up having design discussions, architecture discussions. We get feedback on what is important to the people who show up here. That always informs what we do with the project in future releases. >> Perfect answer. I already mentioned that you can get a hold and in touch with Deepthi through her wonderful Twitter handle. Is there any other website or anything you want to shout out here before I do our close? >> vitess.io. V-I-T-E-S-S dot I-O is the Vitess website and planetscale.com is the PlanetScale website. >> Deepthi Sigireddi, thank you so much for being on the show with us today. John, thanks for keeping me company as always. >> You're welcome. >> And thank all of you for tuning into theCUBE. We will be here in Detroit, Michigan all week live from KubeCon and we hope to see you there. (gentle upbeat music)

>>live from San Diego, California It's the Q covering Koopa and Cloud Native Cot brought to you by Red Cloud. Native Computing Pounding and its ecosystem March >>Welcome back. This is the cubes coverage. Fourth year of Q Khan Cloud native Khan, 2019 Here in San Diego. I am still Minutemen like co host for this afternoon is Justin Warrant and happy to welcome to the program A first time guests, but was on the keynote stage yesterday Sougou Super Marine, who is the co founder and CEO of Planet Scale and also one of the, uh, we're gonna be talking about the test which graduated, announced on the stage. They didn't put a cap and gown or roll everything out, which they did a couple of years ago. But first, thanks so much for joining us. And congratulations. Thank you. All right, so, Sougou, bring us back. You know, we're talking about a cloud native database and we'll dig into that and everything, but bring us back to what you were working on. And you know why of what we now call >>so the When we started with us, we were really not thinking of cloud native itself. for say, it was kind of a sequence of events that kind of forced with us to become cloud native long before cloud native was actually born as even the term was born. Which was when we had to move the test from YouTube on print into Google's board, which use the predecessor off Cooper natives. Um, the reason why the test is kind of one of the leading storage projects in Cloud Native was because it was probably the first project that remained open source, even though we managed to ram it with >>work. Yeah, you know what? One of things we've been talking about at the show here is you know, in the early days, you know, we were very much talking about infrastructure, but we know the reason we have infrastructure is to run applications, and one of the most important applications is databases, and I talk to customers. It's not just one database. Often they have many different databases on, and that is one of the big challenges today. So, you know, you kind of look at that landscape, help us understand how this fits into that. That overall picture. >>Yeah, so that kind of goes back in tow, Google's history and how that can influence kubernetes itself. So if you look at Google's board, most off its features are meant for running stateless application. So within Google, people who wrote applications when they wanted to store state they just called out into a service that was semi part of board but wasn't itself run by board as if you would run your application. So many of those properties were inherited by Cooper natives. So which is the reason why? Um, right from the beginning, it was hard to make storage work for cover natives on Dhe. For that reason, even a zoo recently as early this year, If you look at the tweets from Kelsey Hightower, don't just move your database into communities. You're going to regret it. People still say that, but at the same time, because we test way, we're able to figure out howto make storage work under the stringent rules that Borg had, which was mainly to support stateless applications. In other words, we actually land because, as if it was a stateless application, while still managing while still making state state will not survive this stateless behavior, which is actually why we just managed to be launched within communities as soon as it was born. Ah, but it has been a struggle for other people because they didn't have the luxury of preparing for it without even knowing. Uh so I think that more effort needs to be made on both sides, both from people who are writing storage to make them work with communities as well as kubernetes itself, trying to meet them halfway, trying to add features to help the storage developers. >>It has been a real struggle. I remember from even the very first show I came to four years ago in Seattle looking at the set. My media thing is an ex storage guy and has a backup guy was to go and look at things and say OK, this is lovely for stateless applications, you said. But riel applications have data in them and they need to maintain state. Where's the state looking at all of the group in any type of things, like there were no state full sets with another thing that has changed a lot in four years, and people have come to the party and we need to be able to manage state. But now that you we have a database like a test, isn't that just taking things to the point where I as an app developer, I can just write my stateless application and then my data can live inside a data management service like a test? So I don't actually need to deal with any of that state management problem myself. >>That's what it amounts to. Uh, the the one property of the test is that it can run both in communities and outside. So there are people who run tests on Prem and they have their own orchestration layer. So that has given some challenge where we just cannot depend on communities. You cannot call into communities a p I s o. The way we have the architect of the test is that it knows when it runs within a orchestrated environment, how to interact with it, but it doesn't assume that it exists. So >>why have you provided that functionality? Is that because customers said that I actually want to be able to run the test, But I don't wanna have to deal with kubernetes >>exactly like so not everyone has migrated to communities. It is surprising that everybody wants to migrate communities. But then many of them are saying, I don't know how many years out it is on. Then for them, we just solved a different problem, which is the problem of sheer massive scale ability on dhe for them. They want to be able to still run with us on print s. So for that reason, that is actually a small gap between communities and the test itself. On dhe, we're filling that gap with health charts in the open source on Dhe Planet Scale, which is the company that I founded has built an operator that we're also going to open source so that people can use that to launch community >>before we talk about planet scale You. No, no, no, no. Absolutely. In the keynote you had some customer stories on might might help illustrate some what we're talking about, you know, the scalability of the environment, everything. So you know, I'll let you choose that kind of a short example. You know, the slack One you know, is one that I think president in the audience there. But >>I would choose slack. Ah, Jerry's always obviously enormous, but I will choose slack and nozzle because they represent two very different but really genuine needs in the industry. Slack once not just massive scale, but they want flexibility with manipulating data on DDE. That is something that is manipulating data really, really hard. Onda. We believe that we found the secret sauce to make that work with tests, and that is the reason you saw those statements from Slack. They're so passionate and with so much conviction, that is because they were fascinated by what we could do with their data. So that is one example and slack does not run on communities. They don't run on cloud. They run on AWS, but they don't they run it like they their own claim. They have very fixed I p addresses fixed instance names, but they're on it like a cloud. Sometimes I would say they are more coordinated behavior than some applications that run on kubernetes like they treat everything as disposable. When something goes away, they don't try to recover it or anything destroyed out. Replace it with something new, which is property off cloud native behavior. And on the other hand, a company like nozzle because they're they're actually a startup on dhe. It is surprising that why would the start of one to use? Ah, something that is Mento scale. Massively. That's when we realized that the cloud native nature of it does fills a gap that currently is not filled by many people, which is I want to run everything in Cooper natives all in one. And we didn't realize until they showed us what they did with it, which is, like, completely migrate from one cloud to another. They're a super amazing. And I heard it on dhe. They did that without even telling me are telling anybody in the community because one day I talked to them. They say they are on a key s on. A few days later, I still assumed that they are Nikki s and they know of your booty. Jakey, when did you do this? Oh, we did that last month because we got some really good deal with them, super exciting, >>and that that is a surprising, exactly affected. That's surprising. It is a bit of a concern to me because we hear a lot of talk about multi cloud and the idea of applications being being mobile between different clouds. Data movement is really hot. Exactly. So the fact that someone has actually managed to do that and haven't moved from one community service across to another one is that we find that remarkable because we know it's such a hard problem. But that's one of the great things I think about kubernetes, which is possibly under appreciated, is that it's not that it makes everything easy, but it makes what What used to be hard is now >>possible. Yes, yes, yes, that is very true. Yeah, it's, um uh, like it took It took us a while to, uh, think to make this mind shit, because some of these things, even though they're like it looks, looks looks very obvious. But for the longest time, we were, you're saying, tested for massive scale ability. It's for It's what this and that and even two years ago, up sport came and said, We're going to use the tests for communities orchestration. Weird, but okay, feel free. We don't have a problem with it. And then nozzle came out, and now suddenly you see Oh, this is this is why. And this Saul's really, really difficult problem on. They all did especially hot Spot. Did a lot of work in with tests to actually make it easier. But now we see Now we see the light. >>So Sougou Planet scales the company. Help us understand Vitesse planet scale. How that fits together. What's kind of the business model for your company? >>Yeah. So, um uh, so the test was originally developed at YouTube by you, too. There was one thing That was some pressure. We were beginning to feel when we developed it. We didn't mean for anybody to use it. Really. It was open source, more for academic reasons to show that we can do these things on. But it was interesting when people started adopting it. You're adopting this system. Okay, so we'll see what we can do to help you. But after a while, when the community started growing, some of them were contributing. But definitely storage is a difficult software to write, too. It's not like a pitiful software. Any anybody can understand the cord and start writing. It was obvious that the number of people wanting to use with death and wanting peaches from it are also people that we're not really capable of. writing those features because they're really hard features, too. Right on DDE. That pressure was going and they were saying all I wish you two could do this for me. You know, YouTube is a video company. They're not in the We just did this for ourselves. There's no reason for us to spend so many person years they've left in the future for you. And that time it became obvious that we need to start a company to support this community where there's this huge growing demand, Which is kind of what motivated towards us, uh, thinking about starting planet scale and one requirement waas It cannot remain a YouTube project at that point. So which is why we work it out that way, will actually move it to see NCF. And then I ended up leaving. You do have to start planet scale with my co founder. Then >>so is just from a business standpoint, is that service is on their customers ask for things and fun that that that gets contributed upskirt stream. >>So that was initially what we thought we will do. Initially we thought it was just get out laptops and start helping people that that was our initial thinking. But what we realized was at the same time the industry has shifted towards this new business model which is to actually run everything as a service. And we realized, Oh, my God, years All we have to do is we know how to run with us. You've done it at YouTube. You help people deployed with testing various companies. You know exactly what it takes to run with us. All we have to do is take this. I'm does the service. And that's exactly what people want. Because otherwise, because of the fact that we tested this flexible, it is also extremely complex, too confident because it can run on frame. Then you have to sit all these flags. You runnin carbonate is you said all these flags. So all this has to be managed and we realized, OK, we can manage this and we know exactly how to make it work. And we actually just announced two days ago that our planet scale CNDP Cloud native database is available for people to come in use. >>Well, congratulations on the progress of the business as well as the test graduation and thank you. So much for joining us here on the Cube. Thank you. Alright for Justin Warren. I'm stupid Men. We will be back with more of our day. Two of three days. Whoa! Wall coverage here from San Diego. Thank you for watching the Cube.