 Live from San Diego, California, it's theCUBE. Covering KubeCon and CloudNativeCon, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome back, this is theCUBE's coverage, fourth year of KubeCon, CloudNativeCon 2019, here in San Diego, I am Stu Miniman. My co-host for this afternoon is Justin Warren and happy to welcome to the program a first time guest but was on the keynote stage yesterday, Sugu Sugurmarin, who is the co-founder and CTO of PlanetScale and also one of the, we're going to be talking about Vittes, which graduated, announced on the stage, they didn't put cap and gown or roll everything out, which they did a couple of years ago, but first of all, thanks so much for joining us and congratulations. Thank you. All right, so Sugur, bring us back. We're talking about a CloudNative database and we'll dig into that and everything, but bring us back to what you were working on and the why of what we now call Vittes. So when we started with tests, we were really not thinking of CloudNative itself per se. It was kind of a sequence of events that kind of forced Vittes to become CloudNative, long before CloudNative was actually born, even the term was born, which was when we had to move Vittes from YouTube's on-prem into Google's Borg, which is the predecessor of Kubernetes. The reason why Vittes is kind of one of the leading storage projects in CloudNative was because it was probably the first project that remained open source, even though we managed to run it within Borg. Yeah, you know, one of the things we've been talking about at the show here is, you know, in the early days, 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 when I talk to customers, it's not just one database, often they have many different databases, 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 overall picture. Yeah, so that kind of goes back into Google's history and how that influenced Kubernetes itself. So, if you look at Google's Borg, most of its features are meant for running stateless applications. 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 Borg, but wasn't itself run by Borg as if you would run your application. So, many of those properties were inherited by Kubernetes. So, which was the reason why, right from the beginning, it was hard to make storage work for Kubernetes, and for that reason, even as recently, as early this year, if you look at tweets from Kelsey, a high tower, says, don't just move your database into Kubernetes, you're going to regret it. The people still say that, but at the same time, because we test, we were able to figure out how to make storage work under these stringent rules that Borg had, which was mainly to support stateless applications. In other words, we actually ran with this as if it was a stateless application, while still managing, while still making statefulness survive this stateless behavior, which is actually why we test managed to be launched within Kubernetes as soon as it was born, but it has been a struggle for other people because they didn't have the luxury of preparing for it without even knowing. 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 Kubernetes, as well as Kubernetes itself, trying to meet them halfway, trying to add features to help the storage developers. Yeah, 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 immediate thing as an ex-storage guy and as a backup guy was to go and look at things and say, okay, so this is lovely for stateless applications, as you said, but real applications have data in them and they need to maintain state. And I said, so where's the state? Looking at all the Kubernetes side of things, stateful sets was not a thing. That has changed a lot in four years and people have come to the party and said, we need to be able to manage state. But now that we have a database like Vitesse, 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 Vitesse. So I don't actually need to deal with any of that state management problem myself. That's what it amounts to. The one property of Vitesse is that it can run both in Kubernetes and outside. So there are people who run Vitesse on-prem and they have their own orchestration layer. So that has given some challenge where Vitesse cannot depend on Kubernetes. It cannot call into a Kubernetes API. So the way we have architected Vitesse 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 Vitesse but I don't want to have to deal with Kubernetes? Exactly right. So not everyone has migrated to Kubernetes. It is surprising that everybody wants to migrate to Kubernetes. But then many of them are saying, I don't know how many years out it is. And then for them Vitesse solves a different problem which is the problem of sheer massive scalability. And for them, they want to be able to still run Vitesse on-prem. So for that reason, there is actually a small gap between Kubernetes and Vitesse itself. And we are filling that gap with Helm charts in the open source and PlanetScale which is the company that I founded has built an operator that we are also going to open source so that people can use that to launch Kubernetes with Vitesse. Before we talk about PlanetScale- Sorry, I keep- No, no, no, absolutely. In the keynote, you had some customer stories and might help illustrate some of what we're talking about, the scalability of the environment and everything. So I'll let you choose a kind of a short example. The Slack one is one that I think resonated with the audience there, but yeah. I would choose Slack. JD is obviously enormous, but I will choose Slack and Nozzle because they represent two very different but real genuine needs in the industry. Slack wants not just massive scale, but they want flexibility with manipulating data. And that is something that is manipulating data is really, really hard. And we believe that we found the secret sauce to make that work with Vitesse. And that is the reason you saw those statements from Slack. They are so passionate and with so much conviction. That is because they were fascinated by what Vitesse could do with their data. So that is one example. And Slack does not run on Kubernetes. They don't run on cloud. They run on AWS, but they don't, they run it like they are on-prem. They have very fixed IP addresses, fixed instance names, but they run it like a cloud. Sometimes I would say they are more cloud-native 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. They throw it out, replace it with something new, which is a property of cloud-native behavior. And on the other hand, a company like Nozzle because they are actually a startup. And it is surprising that why would a startup want to use something that is meant to scale massively. That's when we realize that the cloud-native nature of Vitesse fills a gap that currently is not filled by many people, which is, I want to run everything in Kubernetes, all in one. And we didn't realize until they showed us what they did with it, which is completely migrate from one cloud to another. That was super amazing, and I heard that. And they did that without even telling me or telling anybody in the community because one day I talked to them, they say they are on AKS, and few days later, I still assume that they are on AKS and say, no, we have moved to GKE. When did you do this? Oh, we did that last month because we got some really good deal with them. It was super exciting. And that is a surprising example. The fact that that's surprising is a bit of a concern to me because we hear a lot of talk about multi-cloud and the idea of applications being mobile between different clouds is like, data movement is really hard. Exactly. So the fact that someone has actually managed to do that and have it move from one Kubernetes service across to another one is like, 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 underappreciated, is that it's not that it makes everything easy, but it makes what used to be hard is now possible. Yes, yes, yes. That is very true. Yeah. It's a, like it took us a while to think, to make this mindset because some of these things, even though they are like, it looks very obvious, right? But for the longest time, we were saying Vittas is for massive scalability. It's for this and that. And even two years ago, HubSpot came and said, we are going to use Vittas for Kubernetes orchestration. We're like, 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 why. And this solves a really, really difficult problem. And they all did, especially HubSpot, did a lot of work in Vittas to actually make it easier. But now we see, now we see the light. All right. So, Sugu, PlanetScale is the company, help us understand Vittas, PlanetScale, how that fits together. What's kind of the business model for your company? Yeah, so, so Vittas was originally developed at YouTube, by YouTube. 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. And it was interesting when people started adopting it. So you're adopting this system. Oh, 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 to. It's not like a peripheral software where anybody can understand the code and start writing. It was obvious that the number of people wanting to use Vittas and wanting features from it are also people that were not really capable of writing those features. Because they are really hard features to write. And that pressure was growing, and they were saying, I wish YouTube could do this for me. You know, YouTube is a video company. They are not in the, we just did this for ourselves. There's no reason for us to spend so many person years developing this feature 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 thinking about starting PlanetScale. And one requirement was, it cannot remain a YouTube project at that point. So which is why we worked it out that we will actually move it to CNCF. And then I ended up leaving YouTube to start PlanetScale with my co-founder, Jithin. So is just, from a business standpoint, is it services, or do customers ask for things and fun that gets contributed upstream? So that was initially what we thought we will do. Initially we thought we'll just get our laptops and start helping people. 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, all we have to do is, we know how to run with us. We've done it at YouTube. We've helped people deploy with us in various companies. We know exactly what it takes to run with us. All we have to do is take this and run it as a service. And that is exactly what people want because otherwise, because of the fact that we test this flexible, it is also extremely complex to configure. Because it can run on-prem, then you have to set all these flags. If you run in Kubernetes, you have to set all these flags. So all this has to be managed. And we realized, okay, we can manage this. And we know exactly how to make it work. And we actually just announced two days ago that our PlanetScale, CNDB, Cloud Native Database is available for people to come and use. Yeah. Sugu, congratulations on the progress of the business as well as the test graduation. And thank you so much for joining us here on theCUBE. Thank you. All right, for Justin Warren, I'm Stu Miniman. We will be back with more of our day two of three days wall-to-wall coverage here from San Diego. Thank you for watching theCUBE.