StormForge Fireside Chat Podcast | Episode 4

Prashanto Kochavara and Bhagirath Hapse from Trilio speak with us about identifying their needs and solving problems as both platform builders, and end-users, in the Kubernetes and cloud-native ecosystem. We talk about data backups, how they use the StormForge optimization platform, and the solutions they’ll be showcasing at KubeCon.

NOAH: Hello everyone and welcome to today’s episode of our StormForge Fireside Chat Podcast series leading up to KubeCon. We’re here this week talking with all sorts of different folks about the concepts of pain points. Today’s guest, guests rather, are from Trilio. They will be talking to us as an end user and also as a platform developer. So we’re excited to talk to them today. I as always am your co-host Noah Abrahams, Open Source Advocate here at StormForge. My other co-host…

CODY: Cody Crudgington at StormForge.

NOAH: …and gentlemen from Trilio, thank you for coming here today. Will you please introduce yourselves to our audience? 

PRASHANTO: Sure. Hey everyone. This is Prashanto Kochavara. I’m the Director of Product here at Trilio, spearheading our offering for the Kubernetes community around data management and data protection.

BHAGIRATH: Hey everyone. Hello. This is Bhagirath. I’ve been working with Trilio as a solution engineer and we’ve been working with StormForge for the last few months.

NOAH: Fantastic. Thanks for joining us today. 

PRASHANTO: Yeah, happy to be here.

BHAGIRATH: Thanks for having us.

NOAH: So we’re gonna dive right in because we’re really interested in the Trilio data management platform. What’s been built there. Why it’s been built. So let’s start with… tell us a little bit about the platform and then can you describe for us a bit what was the pain and the motivation. What was the problem state that you were solving that sort of brought this whole thing into existence? 

PRASHANTO: Sure, so Trilio for Kubernetes as you said is a data management data protection platform and we focus on all things data, whether it is from a developer’s perspective of doing test data management, or whether it is from a security perspective making sure that your data is secure, or whether it is from an SRE’s perspective making sure you are able to handle disaster recovery kind of scenarios or migration kind of scenarios. Trilio focuses on all of these. 

Initially when we started off as any kind of data protection solution focuses more on the day two aspect of things, but with Kubernetes being such a team sport where you have your developers working so closely with your upside and the IT admin personas as well. We realized that our product has the potential to suffice and focus on a lot of different pain points that the Kubernetes community was trying to evangelize and build on top of with respect to application development and delivery. So that’s our product in a nutshell and what we offer to the community today. 

NOAH: Let’s go a little bit more into maybe a little bit of implementation detail. What does it look like for somebody who wants to get involved with the product? What does it look like technically as a user of the product? 

PRASHANTO: So from how the product was built, it’s a cloud native application. It’s a Kubernetes native solution that runs as an operator based solution, so we have an operator that deploys the overall instance of an application, manages those instances however you want to control those instances, whether you want to control it at a cluster level or the namespace level. That’s the overall architecture, whether you want to do a point in time capture, recovery, define what your application looks like. Everything is a custom resource definition for us. So it’s very seamless. Very, very forward service oriented architecture overall. We are a stateless application ourselves, but we protect both stateless and stateful workloads, whatever is running within the Kubernetes system. You may have your data aspects running outside of the Kubernetes system and we are focusing on protecting those workloads as well now.

CODY: So you brought up a good point a minute ago. So Kubernetes is still relatively new I would say. I mean maybe for some of us it’s not. So early on, would you say that the DR aspect and some of the governance driving those factors were really the problem you were trying to solve, and then you realized hey, it can also be used for these other things?

PRASHANTO: Absolutely. Initially, this was a few years ago when we started off it was more so focused on backup recovery, DR, ransomware kind of protections and things like that. However, we realized that we control the data portion of it and there is a lot more feasibility and a lot more use cases that are being generated that will help the overall intention of Kubernetes, right? Kubernetes focuses on fast application development, fast application delivery, which is done by making sure multiple users of your organization are working together collaboratively. When you’re working collaboratively, you need a solution that is not only focused on your admins or your resources who are focused on disaster recovery, but you can also, or you should also, be using that same tool to focus on use cases that your developers are using the or what your developers are trying to achieve. So basically, it’s one solution that fits multiple use cases for different kinds of personas from development all the way to deployment to monitoring of the application and overall life cycle of the application.

NOAH: Cool. So we’ve talked a lot about applications in the past, and one of the reasons that we work together is the optimization piece. We’re talking about the application optimization. Can you talk a little bit about identifying the need for optimization within the platform versus identifying the need for external application optimization, and a little bit about, the optimization that we brought in, is that solving an internal pain point? Or is that more bringing value to the customers? Or is that both? Where does that fit within the platform that you’re delivering and how does that fit the solution? 

PRASHANTO: So I’m going to answer the question in two ways, right. So when we looked at StormForge and the optimization capabilities that StormForge had, we immediately realized that there are two kinds of problems that we can solve for. Internally ourselves and for the users that we are servicing through our product. So from… I’m gonna talk about at a high level what our intention and goal is and then I can probably step into the details of how we are achieving that. 

So from an external use case point of view, when you think about point of time capture, point in time recovery, there are two variables that have been that any kind of solution or any kind of customer also is monitoring that’s recovery point objective, how much what’s the last point of capture or how much data loss can you tolerate, and then recovery time objective. RTO. How quickly should your applications or your data get restored? 

Now obviously both have a correlation. Very, very strong correlation to CPU and memory resources. Obviously when you’re doing the capture you want to make sure that you’re able to capture it quickly so that whatever you have to find for your toleration of data loss is upheld. Then if you are recovering, obviously you want to recover quickly. You don’t want to wait for hours and hours or days to make sure that your applications are back up online again after a disaster. So those are the two main variables and through StormForge what we realized is we can make it very intricate for the user so that any new application that they are deploying into a Kubernetes cluster, instead of trying to do raw analysis as to hey what should the best recovery point objective be for this application, we are using StormForge to provide that to the user. Saying that hey, you don’t have to calculate all those things yourself and let this automation tool take care of all that. Let this optimization tool figure it out and give you that calculation as to what is the exact cost that you are investing in terms of memory and CPU and what is the value you’re getting. It may be that you were trying to push a lot of memory and CPU, but the advantage that you were getting from a RPO, RTO perspective was very, very minimal. So now users can immediately understand as and when they onboard new applications what should be the best RPO that they can achieve and they can set it. And maybe if the best RPO that they want to achieve is not possible, then they know okay hey, we need to up the resources on the system so that everything still functions as a very strong basic unit. Similarly from the recovery standpoint where you have RTO, we want to let users know that hey, if you increase your memory and CPU to these levels, your application can recover 50% faster. That is a very, very strong value statement and all of this being automated and being crunched behind the scenes for the customer becomes very, very valuable because you don’t have any, you have peace of mind because okay, everything’s going to be taken care of, everything’s being optimized, cost is going to be suitable to my needs because I am dictating the resources that need to be applied. So considering the kind of world we live in, hybrid memory and CPU do have direct implications of what you apply and you want to right size your resources very, very early on to avoid any additional costs. So that’s more on the customer front where we are using StormForge to optimize the experience for our users on our own platform and then internally, obviously as we are doing scalability tests, stress tests, and anything on those lines to validate the product, regression tests as well, we use StormForge to make sure those pieces are also upheld in a way, right? Scaling to like 100,000 backups and things like that. What is the memory, CPU you need? What is the guidance that we need to provide to customers? Hey Mr. Customer, if you have X terabytes of data. This is the best memory, CPU config that you need. That level of guidance, which normally you would have taken multiple engineers to run tests in parallel to figure out, now we have an automated machine learning engine that does all of that for us, and from a resource perspective it’s very, very simple. So not only from the build of the application, but also from the delivery of the application and the experience to the end user. Definitely, there is a lot of value between our own product and StormForge. 

CODY: That’s great. Kind of getting… StormForge isn’t the only solution that you have to help your customers. I think you have something for GitHub runner, you have something for a few other things. What does it look like or can you talk about what it looks like when you identify something what it looks like for you incorporating your customer’s needs and pain points back into the platform from a product sense.

PRASHANTO: Okay, so if I understand the question correctly, what you’re saying is how are we productizing this experience for the customer? 

CODY: Yeah, not just StormForge but general. Not just with StormForge, but in general as it is. Because I mean obviously you have stuff up out there and you’re very customer focused, right? 

PRASHANTO: So the way we track it is it’s all based on… There’s obviously things that we need to do and everything needs to be prioritized. These kinds of solutions are our entry point to understand what is being leveraged more by users. It’s a test as well. It may not be like all hundred customers are using it right away, but tomorrow we see okay hey, 99% of our customers are using StormForge with Trilio, so that will make it very clear to us that hey, this needs to be more of a productized solution. 

So for example, when our product… we have something we have a feature known as Disaster Recovery, right? Where a user can just take all the different applications that he had protected into multiple backup repositories and he can construct this plan and say that okay, this is my minimal viable business and I want to get this instantiated again. So the way we think about it is, it would be highly, highly valuable where we can have StormForge predict that to the end customer and say, you have these seven, eight clusters available. This is a cluster at the lowest cost and the fastest time that you can get your application up and running again. So our intention again is to first look at the traction in terms of how customers adopt and once we see a decent amount of adoption, we productize it into the product. We already have a lot of plans as to where it fits into the product. Now it’s more about tracking how the usage is.

CODY: So a question over to Bhagirath, since you’re much more, you’re sort of elbows deep in the implementation when you’re doing these integrations, what does it look like when you’re doing these implementations and these integrations within the platform for, as Prashanto said, whether something’s going to be productized or whether or not it’s just going to be integrated? Are there differences that come along when you’re doing that type of work, or does everything get done in the same sort of way?

BHAGIRATH: Yeah, that’s a good question. So actually while doing the implementation, the product side, right, we have realized that StormForge is something that is very easy for us to implement and integrate with Trilio, right. Trilio being a backup and recovery solution, the best benefit that we actually got out of it is for the cost optimization, right, and the integration with Trilio for the backup and recovery, it’s much easier than writing your own automation suite for it, right? So when we actually have StormForge in place, which is integrated through experiments and config maps, right, it was much easier for us to just create those config maps, create those experiments, depending on different use cases that we were trying to build. So just to give you an example, right, having a number of backups trigger either sequentially or parallel, depending on the customer needs is not a big task when we actually have StormForge, right? For us, understanding an experiment and putting those use cases into the experiment is much easier because learning the experiment has become a very easy task now. So instead of going through all the new implementation of the code for automation, the integration obviously has helped us to do this much faster. The productizing side as well. It is much easier for us now to productize it with Trilio and then ask customers to follow certain steps, so that the problems that they are facing from the cost and the RPU, RTU side can be resolved very easily. 

NOAH: Awesome. So if I were to turn that on its ear slightly, it sounds like you’re also saying that the integration work is much more dependent on the tool that you’re integrating with than on the behavior, whether you’re looking for productizing versus a direct integration. Is that correct? 

BHAGIRATH: Yeah, that’s true. That’s good. 

NOAH: Great. I think I am out of questions at this… Cody, what else you got?

CODY: Not, not much. I can say this team is really great people to work with. I’ve had a lot of fun working with you all over the past few months. It’s been great.

NOAH: Awesome. Heartwarming – I love it. I guess it’s time to move on to our Rapid Fire questions then. Cody, you want to grab this one?

CODY: Sure, okay. Again, Rapid Fire questions do not necessarily have to do too much with much of anything, if that makes any sense. Feel free to answer them as they pop in your head… 

PRASHANTO: Sure. 

CODY: …and we’re going to start. Pineapple on pizza – yes or no? 

PRASHANTO: Yes.

BHAGIRATH: No, I guess. 

CODY: Alright. Favorite sports team? 

PRASHANTO: I follow cricket a lot and there is a local Indian league called IPL, so Mumbai Indians is my favorite team. 

BHAGIRATH: Okay, so I will also go with the IPL since that’s going on currently. There’s the 13th season. So I have Chennai Super Kings. This is my favorite team.

CODY: Nice! Alright. Favorite piece of technology?

PRASHANTO: Hm… Rapid Fire… I would say probably my phone. Can do anything and everything on my phone.

BHAGIRATH: Absolutely. Agree, agree with Prashanto on that.

CODY: That’s actually a fairly popular answer, believe it or not.

PRASHANTO: It is right in front of me so…

CODY: Alright. Favorite open source project?

PRASHANTO: Oh, I’ve been tracking Argo very closely and just been something that I’ve been looking at and really, really liking how they’ve built and constructing the overall project.

CODY: I agree with you.

BHAGIRATH: Yeah, so I am also following Argo and there’s one more tool which is being built by one of the firms in India. So it’s called Bot Cube, which is majorly for communication or notification or monitoring between different tools like Slack and your Kubernetes cluster. So that one for me. 

CODY: Nice. Alright last two. Favorite hobby?

PRASHANTO: Not doing anything and relaxing. Yeah, that can be your hobby. Yeah.

BHAGIRATH: Maybe watching cricket all the time? Get some popcorn. 

CODY: That’s fair.

BHAGIRATH: From a more realistic point of view I would say running. I do run a lot, so that would be it.

CODY: Oh okay, yes, yeah. Alright. Favorite place to vacation?

PRASHANTO: Anything that is close to the ocean and warm, especially since we are in the northeast, so now that’s still top of mind.

BHAGIRATH: That’s a tough one for me. On the domestic side, we have any beach, doesn’t matter. If you ask me on the international side that I visited recently was, yes, before COVID, was Switzerland.

CODY: Man, we’ve been talking about trying to get over there at some point, hopefully, with COVID. But I’ve seen the videos of all the waterfalls and stuff like that… oh man, it looks fantastic. Yeah, yeah.

Perfect, that’s all I have. Thank you so much. 

PRASHANTO: Awesome, awesome. This was fun. Thank you, gentlemen, for joining us today. This has been a wonderful conversation. Great view into the building of a product and as an end user and a consumer as well. It’s a nice dichotomy and we like to present it. So thank you everyone who tuned in for joining us, and we will see you tomorrow on our next episode.

Have a wonderful day, everyone. 

PRASHANTO: Thank you, everyone.