 So Barth, thank you so much for doing the interview with us. Can you tell us who you are and what your background is all about? Yeah, thanks Langdon. First of all, great to be here. Definitely a unique situation for me to be in this bright red car on a sunny day. Yeah, it's gorgeous out, isn't it? This is actually quite amazing. You can see the clouds in the sky. That is indeed true. What's the theme this time? Isn't it like Let Kubernetes Bloom or something? Oh yeah, that rings a bell. Sorry, back to your question. I'm Gaurav Rishi. I'm the VP of Product and look at cloud-native partnerships here at Kerstin Baweem if in case people can see the logo out here. So very much looking forward to this. So what does that mean that you kind of do? Obviously, I think a lot of people are familiar with kind of helping to drive product, but what does the kind of partnership side mean to you? This is super exciting for me because living inside the cloud-native ecosystem, what first of all we as a company Kerstin Baweem do is three key use cases. One is we do Kubernetes application backup and recovery. We do disaster recovery and we do application mobility. I can explain each one of them. But to get any of these things going, you need to sort of work in the ecosystem. You need to make sure you are working with the storage partners so you can actually back up your data. You need to make sure that you are working with all of the Kubernetes distributions so that people have their freedom of choice, whether it's managed services or whether it's on-premises self-managed like OpenShift, as well as you need to work in the context of security because backup turns out to be a last line of defense. And so that's super critical too. So that's really going ahead and making sure we can make all of these technology pieces come to life in a way that makes it super simple for people and getting all the companies to work together. So that's really a part of my job while we help define the product and build it, which obviously the smart engineers at Cast & Do. Right, right. Yeah, I mean, I think kind of the crux of Cloud Native. I mean, it's kind of true in more traditional application environments as well, but Cloud Native is all about kind of service-oriented architecture. It's all about connecting all the pieces together to actually get to where your application is going. And I think that's one of the hardest things to manage. And I think that maybe companies like yours bring to the table, but also companies like Red Hat bring to the table is providing me as a customer or user kind of a guidance on which ones work together well, which is a difficult thing to figure out on kind of your own without a lot of trial and error, which is less than fun. No, you know, it's interesting you say that because I actually remember blogging about this up front when I joined Cast & The Cloud Native community, which was simplicity and freedom of choice. And I know it gets a little philosophical, but the point is, on one hand, you can argue that, hey, look, if you have a lot of choice, things become complex. It's hard to choose how to get things to work. And sometimes people can confuse that by saying, let's go restrict the choice so that it becomes sort of simple. But I think the right answer is, how do you still keep that choice but maybe guide people so that there is indeed a way where they feel confident of being able to go ahead and pick the medium which helps meet their requirements. So I think that's very much what we do. We want people to be able to choose the best storage infrastructure, choose the best deployment model, whether it's out to the edges in the cloud, hybrid, et cetera. But at the same time, make sure the data has the freedom and can sort of move around because that's very much how I think most of the deployments today are ramping up. So that's philosophical but also very much true to what we are seeing today. Yeah, I mean, I think we've started here to terms like opinionated a lot. And I'm a big fan of the opinionated kind of solution that allows for change, right? Because it doesn't always fit. But at the same time, getting it kind of up and running in the way that we know kind of works the best is a lot easier starting point than having to figure out all the tools all the way along. So yeah, I'm a fan. Yeah. No, I think simplicity is needed. And especially in this environment, I mean, I know you probably know the stats, but it amazes me every time we come for the Kubernetes event. Majority of the people are attending Kubernetes for the very first time, which means that they are actually new relatively to the ecosystem. Right. And so you cannot expect them to be black belts on day one. And so I think as organizations sort of scale up their workloads, they are looking for, like you said, the opinionated ways of being able to work so that they can get the advantages that Kubernetes has promised and is actually delivering. Right. But do it in a simple way. And that's very much, I think, how we at Gaston also approach it. Well, I mean, even if you're in this space all the time and like keeping track of, you know, the plethora of projects is really tough, right? Yes. And like I was one of the other people I interviewing is actually working on the like cloud native glossary as well as like trying to put together. There's another CNCF kind of project summary map. You know, so to try to get, you know, some, make it a little clearer what's, what really is going on. Yeah, it might be easier to navigate the streets of Amsterdam with a cyclist than it is to at times navigate the CNCF landscape I hear you. I don't know if I go quite that far. All right. Okay, fine. I was pushing it. It is exciting being out here. Well, they're excited. Yes. Yeah. So yeah, I totally hear you. But you do, your organization does do a fair amount of open source kind of contribution and the project you were talking about specifically that I thought was really interesting was Navigate. He tells a little bit about that. Sure. So yeah, I mean, to a larger point, I think we are definitely, you know, big sponsors of not only the KubeCon type events, but also our active contributors to a variety of open source projects. So, so I can probably, and depending on where customers and the community members are in their journey to adopting Kubernetes, there's something that, you know, we see as a fit for them. So, so specifically around Navigate, which is Navigee with a letter or a number eight behind it, is an exciting one. And I think the, you know, the thesis behind it really started was on one hand, Helm is amazing, right? I mean, it's a collection of YAML files, helps you have these in a chart, helps you do package management, deploy applications. But it also comes with a variety of challenges, right? As your applications and your cloud Navigate applications become more complex to your earlier point. There are a lot more configuration parameters that you need to go ahead and set, right? And it is very easy to lose yourself into these YAML files, authoring them, and different charts and different aspects of those YAML files might not appeal to the same domain owners. So your developers might care about some configuration parameters, your operations teams might care about a different set of parameters, and things can get out of whack and complex to manage really quickly, right? And we noticed that when we were dealing with our customers. And so, Cast and K10, which is our product, also is a cloud native application, and you know, we started seeing some of those complexities ourselves too. So Navigate was born from that problem and to see if there's a way to solve that. And so what it allows you to do is essentially gives you a simple, you know, user interface where you can go ahead and actually get your variables on one side and then, yeah, exactly. I was like, this is what. It's a little hard to see them when you're kind of this low. This low on this race car. I don't know if the audience can actually see how cool the car is, but yeah, it's very cool. And there's the canal on this side. Well, one of the people I interviewed earlier commented that, you know, maybe it's been low enough. And, you know, like truly the, you know, doing the race car experience, you know, with their economy mode and, you know, driving in city streets, which probably you should be in the bicycle here. And that's how the interview should happen. We talked about that. But have you ever seen a two-person bicycle that was not like front-back, right? And then you'd also have to do all the pedaling, right? So that might be tough on the talking. So, yeah. Yeah, so sorry. But no, I think we got lost in that. So, yeah, so Navigate allows you to sort of very easily be able to go ahead and get a list of, think of it as values and parameters. And so you can go ahead and get your applications configured in a way where you know what might be the parameters, what the value for that is, set it up, and it in turn will go ahead and generate the chart for you, right? And I think that, and that turns out to be something that's super useful because once you get your perfect chart, you've got this. It's easy to understand. But then it can be reused, too. And you can apply it across a variety of templates. So that's, in fact, how you want to go to install at caston.io, for example. That's what we use under the covers to go ahead and make it easy to design and configure. Exactly, exactly. So, yeah, that's something that we are excited about. We are definitely seeing, you know, the community sort of saying, okay, that's interesting. And so I think events like this, where we've got everybody from various industries come in and talk about it, can help sort of contribute to it and take it to the next level. And there's so much more you can do, right? Whether it's about parameter validation or things of that nature, I think those are all very much a part of it. So that's what Navigate is, but there are a bunch of other projects like CubeSter and we've got CubeCampus, which is a learning platform, and we've got Canister, and I'm happy to talk about that, too. Yeah, I mean, you know, what do you think is the interesting, you know, things like Canister or whatever, you know, you're doing a lot of contributions to, you know, these open source projects, and it sounds like you're contributing to them, like you're kind of creating them and contributing to them because of the need that you have that you think others might share. So, yeah, I mean, I think that's... Yeah, so I think, you know, you were asking me this question earlier, I know just before we hopped into the car about, you know, why is data protection important right now, right? Yeah, basically it's like, you know, in Kubernetes land, right, you know, I would say maybe not a year ago, but a year ago, right, there was not very many organizations that were offering, you know, solutions in the, you know, kind of backup data protection, et cetera, space, but it seemed like there are a fair number of them this year, or this, you know, event. And so what do you think has shown that growth, or where do you think that growth might have come from? Yeah, so I think, let me see if I can draw an analog given that we are on a journey here, so maybe the stops to that is, so I like to joke that Kubernetes is a, you know, eight or a nine-year young system right now, the ecosystem is still developing, the technologies are in production, but there's so much innovation still going on. So if I really had to rewind, the initial years of Kubernetes, you had this whole paradigm around hey, pets and cattle, you know, stateless systems, right, and, you know, as a vegetarian, that was not very appealing, the whole analog around pets and cattle. I had an ecologist, a friend of mine who was an open-shift advocate a long time ago, he decided that it should be ants and elephants. Actually, I do need to meet this ecologist. Okay, I hear you. I can empathize with that. We'll shout out to Stevo on Twitter. All right, very cool. Good job, Stevo. I think that would have been a much better way to term it, but for whatever reason, that stuck and that was a good way to start the system. You had very simple applications, which didn't have state, but think about any application, whether it's your banking application, shopping art application, hopefully earning money or spending money, and you need to store that somewhere. And so state is going to exist, and you have the other thing which sort of went and came alive in the cloud-native development pattern, which was what we call polyglot persistence, which was essentially just a fancy way of saying a simple application under the covers uses a variety of data services, whether it's SQL, NoSQL, messaging queues, streaming databases. The point is you have not a single relational database which used to be in the monolith of a non-cloud-native world. You now have moved to a cloud-native application of microservices and multiple data services under the covers. So if I kind of now fast forward 10 years into the journey, we actually have databases as the most popular workload running on Kubernetes, right? So if you kind of go look at your data dog report, which is not a survey but actually going and looking into what's running in these containers across, you know, a billion plus of them, it turns out that it's usually things like PostgreSQL and, you know, Mongo and things of that nature. So that's what's happened, first of all. You've had a huge amount of state come in, and as soon as you have state, you need to make sure that you're actually able to protect yourself in case there are failures and that could be, you know, attacks from things like ransomware or there could be mistakes that people made by misconfiguring, etc. And so you need to be able to go ahead and recover, and that's what brings up data protection as a here and now issue, right? That's really what's happening. And this makes me ask the question, have you lost? I see you looking at the map. Not entirely. I just, the map wasn't kind of keeping up with where I wanted to go. So I just changed it so that it's now going to fall a little better. This is a, this is a, I think I recognize the street. So this is a cool place to be, actually. Either which way. It's one of the major ones. There's a canal on either side. Yeah. So I actually think this is part of my route. It's just I wasn't actually sure where the next turn was. So that's why I was checking it out. So one of the things that I actually think has also been really interesting kind of the cognitive world, even in more traditional apps that are not actually doing kind of the real cloud native thing. The number of types of databases that is in every application is, like, ridiculous. You know, like the, you know, a an application used to be just a relational database behind it. But now it's got you know, a, you know, some sort of name value pattern, no SQL database, or it also has like a, you know, a document store, no SQL database. It also has a relational database. And maybe some others. And I think that's been also really interesting. So not only do you have the complexity of, you know, typical kind of data backup, but now you have to do it in like all these different ways, because all these tools do their persistent differently, and they also have different styles of you know, as you call it. I'm actually, I don't know why the term never really occurred to me, but data protection you know is even more complex, right, than it would be traditionally, because you have so many different kind of crazy options around how that data is being persistent. Yeah, no, I'm actually, you know, just to build on that point, not only is data protection important because of the reasons we talked about where you on one hand have a lot more attack vectors and backup turns out to be your last line of defense. But in addition to that, the makeup of your applications under the covers have a lot of this polyglot persistence point that we were making. But you know, when you actually look at the techniques of doing data protection or things like being able to take backups, you can you know, as software developers or former software developers, I mean, I think we all love our stack diagrams and layers of operation. But you know, you can work at the storage layer, right, so you can do snapshots, so you can work with block file or object stores and say, look, I need to go take a quick snapshot of that. And that works fine in some cases. But you also might need to go ahead and work at a layer above, which is at the database level, which we call logical backups. And the reason you might want to do that is for some applications, it's not sufficient to get the kind of consistency a snapshot might give you because you might have still things that are in memory haven't been flushed out today. If you lose that, that could be that million dollar sale you made. You know, you don't want that to be lost. And so that's the reason if you're using, for example, Postgres as a database, you might be wanting to exercise things like PG dump, which is a tool that might come with it. And to your point, because you have 300 plus databases and that's growing actually, you have 300 different ways of being able to use these logical tools. So I think one of the things which, you know, we at Cast and do really well and I can talk about what we're doing together with the community with projects like Canister in that context is to be able to say, look, we want to give you a simple way, but still maintain that freedom of choice to be able to go pick and choose any database that solves your problem. But when it comes to backup, we'll go ahead and create these templates. We've already gone ahead and configured that under the covers, you can choose whether to use snapshot based backups or logical database by backups and we go ahead under the covers use the native tools that the database vendors at times have gone ahead and created. And then the other sort of vector to this is also that we're seeing people employ databases in Kubernetes clusters and then they're also using databases as managed database as a service. So think about Amazon, RDS for example or MongoDB, Atlas and so on. And both are good, right? Depending on the needs you might decide option A or B and B and B also in some cases. And so you also want your backup to work across both those cases, which is what we do. And so how canister fits in, which is again an open source project is it gets a little more involved and I know we are navigating through the streets here. But it's interesting because think about going ahead and doing a backup. You might have multiple replicas running. What you might want to go ahead and do is say, look, I want to have an order of operations in terms of making sure scale it down, go act on replica number two, make sure you use these tools so you have pre hooks and post hooks in our terminology to be able to create these blueprints for certain types of databases. And then when the time comes for recovery, these order of operations are even more important because it might be that your application requires Microservice 2 to come up only after Microservice 1 has been rehydrated. So what canister allows you to do is create these blueprints which can be extended or can be authored up front for your applications which have under the covers various types of data services and then be able to define these order of operations but these order of operations also includes a call out into the database to give tools like PG dump etc so that it becomes super easy for you. So do you foresee canister as kind of like a complete disaster recovery kind of orchestrator for lack of better term or is it pretty much purely focused on data? I mean, data is obviously an important part but not the only part of kind of a recovery scenario. Yeah, that's a great question. So I think the way we've got canister right now and the way we envision it is essentially canister plays a really important part in doing what I just defined which is the blueprint aspect of it but if you had to go ahead and think about backup and disaster recovery, there's so many other aspects that are needed. So for example, you need to go ahead and not only discover all the applications that first of all are running in your cluster, then you need to go ahead and define what should be the policies, how often should they be backed up, right? Then you need to go ahead and define well how long should they be kept because you don't want policies seven years or whatever or 30 days and after that time go and delete it or move it from you know, this object store to maybe a coal, glacier or things of that nature. So there are all these other attributes and so that's where we have Kaston K10 as a co-product which does a lot of that work but for some of the key critical tasks, it uses canister to be able to define these blueprints. So the problem we are trying to solve that and strike this healthy balance is we want our partners, both system integrators as well as customers to be able to not wait for a release from us to be able to say, hey, my applications looks like this and my order of operations need to be ABC. Give me a new release for that. I should be able to go and work at my own pace and across my own deployment model and so that's the way we see canister evolving and we keep getting it richer and it surprises us at times that customers and community members who've used it and built their own things and wrapped it with other kinds of scheduling algorithms and that's all very good and the way we see it at Kaston K10, usage is to be able to continue to enrich it so it becomes easier for you to be able to write these blueprints as well as have them surfaced up so comes back to that simplicity point we started with. One thing I want to ask you, because you were talking about the complexity there's this, I wouldn't say new, but it's getting more prevalent concept of eventual consistency and I'm curious to know do some of the tools you're describing help somebody solve? When you have eventual consistency, is the data how do you deal with backups and recovery and deal with the fact that it's eventually consistent? Yeah, so look, and this goes back to that point around you were making about databases themselves are evolving in their architecture and not only are they segmented based on are they columnar or are they, I mean you're the professor so I'll leave that part to you to expand but my point is we see a diversity of those but what we are also seeing hand in glove with that is operator based patterns coming up by these database vendors themselves who know best to go ahead and define how to do the backup based on the behavior of eventual consistency or not and so I think our design and philosophical approach, I just gave a simple example of saying when it comes to Postgres we could go ahead and employ PG dump but for example if you take Cassandra there is also something called K-Exandra which is another open source operator framework which we've integrated into that hides the complexity of being able to go ahead and work in such environments and that's a pattern that we are seeing come up with a variety of you know database vendors whether it's people like EDB or Mongo or so on and so that's how we expect to work at that logical level even in this kind of environment one of the things with databases is that databases have the scale you know in they're like at all well before most of the rest of the software environment kind of needed to and so as a result you know database you know creators like developers whatever like they know for example like the best way for their application to scale and kind of containerization of those was often not a great idea because you were like kind of trying to know better than the database vendor and so database vendors are also now going kind of more containerized and I think they're doing a good job of that and this is not a fault at all it's just that a lot of the times particularly if something as sophisticated as data and database or whatever it is it's even more important to rely on the authors of that software system to kind of tell you how to work with it you know because like at the end of the day Apache or HDPD it's a pretty simple system you know I mean it's really good piece of code and all that other stuff but like at the end of the day it doesn't you know it kind of you can kind of just start it and stop it whereas a database has so many other kind of moving parts and I think that that's like your philosophy is a good one where you're kind of saying okay we hope you know that you as the author of this software know the best way to provide the data and then we can go off and do what we do well which is the you know the kind of backup and restore and all that jazz but the detail is like separation of concerns where you folks know this part well and we know this part well let's work it together instead of trying to take over and I think there's another sort of bridging open source project which probably is worth mentioning too which is Copia so you know data movement you've got the backup process etc you've got some things in so your persistent volume you need to usually move them somewhere so that it's more than just a snapshot because that's a bad idea for a backup your storage system can fail and so on so typically people would go ahead and say look let me go ahead and make sure I take a backup whether the storage layer are at the logical level but then move all of that content for safeguarding purposes using what we call the three to one rule right which is like three copies two different types of media one offside so that you can protect yourself and now you need to go ahead and do a lot of work to make sure you are efficiently and securely moving that data out into that place which typically turns out to be an object storage location and at times it's you know increasingly in the clouds right whether it's a blob store on the Azure side or whether it's S3 etc and so in that context we've also been contributing a lot in what we call copia which is a data mover and that's really interesting as a project too and that sort of built on the server less design type principles and that's quite interesting as an innovation project also that started a few many years ago actually and now it's obviously in production with some of the world's largest companies using that as a result of using cast and I think that's another interesting hand and glove project between what we see with canister and copia as you sort of evolve towards this data protection journey right so yeah so I think just to complete the analog I mean you know as you come into KubeCon if you've come in for the first time we've got open source sort of initiatives like KubeCampus where you can come and learn in fact there was a lab yesterday where a ton of people had signed up and you could go ahead and just learn about Kubernetes right no strings attached it's a way of sort of giving to the community making sure they're educated and that's a great initiative. The second one is like let's say you've gone ahead and started creating your first few applications you run into some of these practical problems we were talking about with things like Helm you've got projects like Navigate now let's say you've gone ahead being able to deploy those applications what we've also realized is people come and say hey well I need projects and I'll put a plug in for another one which is Kupster which is our way of going ahead and saying well I don't know there's so many different storage environments in my little cluster or in my set of clusters or hybrid environments can something go ahead and figure out what are these different storage environments there first of all just the auditing aspect and discovery aspect. Once I've got that going ahead and sort of just make sure that they are actually okay with being able to go ahead and do things like backups do they even support the snapshot API's you know that some vendors don't support even today the legacy ones though of course that's quite corrected at this point of time or other right drivers installed and things of that nature so in that context you also want a tool which can not only discover your environment but can go ahead and validate that you can actually have all of these pieces in and then maybe run some performance tests maybe it's an FIO or something right just to get that and that's exactly what projects like Kupster do for the environment and then once you've got that in I think data protection comes in next as a stop so that you have your last line of defense and having said that sounds like we've reached that stop. We've gotten to the end of our journey. Yeah so the last line of defense there you go. Thank you so much for being here we think they're fun hopefully the driving was not too harrowing. Now this is a fantastic car and the city is obviously beautiful and good company so thank you very much and I can talk about data protection for a long time so I know you want to stop. It's helpful when you get into a space you know there's so much more we can talk about.