Hi, all. Thanks for joining our first session for today is optimizing application performance on Kubernetes by Dhinakar Gunaguntala. Thanks, Dhinakar. And a brief introduction about Dhinakar. Dhinakar is an architect of the cruise project. Dhinakar is focused on autonomous performance tuning and exploring the usage of machine learning and hyperparameter optimization in the performance domain specific to Kubernetes and cloud. So, Dhinakar previously worked on making the open J9 Java virtual machine run more efficiently in the cloud and was the official maintainer of the adopt open JDK Docker images. Dhinakar loves open source astronomy and volleyball and it's a prolific speaker at conferences. So, a brief introduction about the topic that we're going to talk today. So, now that you have applications running on Kubernetes, wondering how to get the response time that you need, tuning applications to get the performance that you need in Kubernetes and can be challenging. At the same time, there are a number of Kubernetes features that we used in the right way can go a long way to get the most of underlying hardware resources. This talk looks into each and every aspect of optimizing a Kubernetes cluster, starting from the most basic no-definities to advanced methods such as tuning microservices each with examples and a demo. We'll also be specifically looking at tools that help to not only right size your containers, but also optimize the run times. So, we'll start the session. And thank you for attending this session. This is Dhinakar Guniguntala. I work at Red Hat, where my primary job is to see how run time such as Java can be made to run better in Kubernetes. And that is what I'll be talking about today. Has it ever happened to you when you talk technology to customers only for them to ask what's the mileage? So, today we will look at ways to improve the mileage that you can get with your Kubernetes cluster. So, let me take a moment to define what I mean by performance. Traditionally, performance looks at 3 key aspects throughput, response time, and utilization of system resources. These are the criteria that we'll be looking to optimize in today's presentation as well. However, I'll be confining myself only to compute. So, before we dive into the presentation, I thought it'd be good to define the overall context here. Imagine that you are an SRE and you've been given this problem to be solved. You have a complex polyglot application such as an airline booking system that is deployed onto Kubernetes. As you can see, it has many microservices, a couple of databases, and each of the microservices written in a different language and framework. The user is having a slow response time while doing a flight booking. Now it is up to the SRE or the IT admin to try and make the user experience better. So, let us look at in detail what are the steps that an SRE can take to try to solve this problem. So, the first aspect to be considered is observability. This is something that is very key. How closely we observe the system and all of the metrics associated will actually help us to determine where the performance bottlenecks are and how to go about tuning them. There are a number of tools out there that can help you to get better metrics. Prometheus and Grafana for example, a couple of the more popular ones. I would also suggest that you can take a look at open telemetry which is slowly becoming industry standard when it comes to observability. One of the key things in observability is the granularity of observation. For example, if you're observing the pods on a per second basis, then you get very accurate information, but that causes the higher overhead both in terms of CPU, network activity and in fact, disk space as well. So, there's a trade-off here and you need to be very careful in setting that value. Another aspect to consider would be to export additional operational metrics on a per application basis. Things like the spring actuator or the micrometer for Quarkus, prompt line for Node.js can be turned on for your application and they provide additional runtime-related metrics such as the heap, which we can see later, can be used to tune the application for better performance. When you have an on-prem cloud, you have the luxury of tuning the hardware all the way from the BIOS in each of your Kubernetes nodes. Common setting found in BIOS relates to the choice of performance of power. Choosing power means you get better power savings but variable performance. The same setting bubbles up into the operating system or the hypervisor as well. In the case of Linux, it's called as the scaling governor. In fact, I've seen performance drop by up to 30% with the power save option for certain workloads. If power saving is your goal, then this is a good setting but definitely not a performance of the application is the key goal. The other thing to consider or at least be aware of is to look at hyperthreading or not consider hyperthreading while doing capacity planning. Let us say a server has 16 cores and two threads per core that has counted as 32 CPUs. However, hyperthreaded CPUs give at most a 20% boost over a single core and so it is best to ignore this while calculating capacity. Now that our hypothetical SRE has set up observability and has fixed the hardware, what's the next step? Let's start simple. Match the application to the hardware features that is needed by the application. So node affinity is typically accomplished by setting the right labels to a node in a Kubernetes cluster. It is very useful if you want to assign pods to a specific hardware feature on the node or maybe the node is reserved for a particular type of workload or namespace or a security constraint. In this example, we see that this particular pod, which is a ML application, will only run on nodes that have the GPU label. Another way to constrain pods is to use pod affinity and pod anti affinity. If there are pods that commonly communicate together or maybe they share some common resources, then it makes sense for them to run on the same node. We can use pod affinity rules to make sure that they all run on the same node. But what if you don't want pods from one application A to run on a node if you have pods from application B running on that node? Maybe both applications are network heavy or both use GPU extensively. Whatever may be the case, we want to make sure that pods from application A and application B run on different nodes. So in that case, we can use pod anti affinity to make sure that they both don't run on the same node. In this example, we want a pod to be scheduled on a node, only if there are other pods that have the same security policy S1. And don't want to schedule it on a node that is running pods that use a different security policy S2. The advantage of pod affinity and anti affinity is that it allows the admin to dynamically assign nodes for certain kind of pods without having to dedicate nodes ahead of time. There are also other scheduler mechanisms such as taints and tolerations, pod priority that you can explore as well in this particular context. Now, we come to the most important aspect of performance tuning in a Kubernetes cluster. Right sizing application greatly helps to get the best possible performance. So this is done primarily by setting the CPU and memory requests and limits. So here on the left, I have an example application deployment YAML. And you can see the resources specified in the container spec section. It is very important as a best practice to always specify the resources to enable Kubernetes to make the best possible scheduling decisions. This usually means that you have to either set the guaranteed or the burstable QoS class and avoid the best effort, which means that in best effort, you're not setting anything at all. One thing that we do need to make sure is that for the best possible performance, we need to set the request to cover the consistent peaks that we observe. And the limits should be set to handle any spikes. So do ensure that the limits are set high enough during observation itself to prevent any throttling. Also, do ensure that requests and limits that you're setting do not clash with any limit ranges that might apply to your namespace. Now that we know that requests and limits are crucial to your performance, you might have a question, how do I arrive at the optimal values for requests and limits accurately? The vertical pod autoscaler can help in that regard, but I suggest you use the cruise tool, which I will talk about in a minute. So let's take a closer look at the various autoscalers that Kubernetes has. So application performance depends a lot on how the app is scaled, and this is where setting the right policies for the horizontal pod autoscaler is very important. So try to use app-specific metrics to set up the HPA as much as possible, as using just the average CPU utilization, for example, might not be the best approach. So for example, when a GST is triggered in Java, this might actually cause a new pod to be instantiated instead of when actual load is increased. You can also use external metrics, such as the number of concurrent users that your application is handling. But the best practice is to use objects that are known to Kubernetes as much as possible, such as the packets per second or requests per second. So in this particular case, what we are saying is that if the packets per second, the average value of the packets per second goes beyond 1k, then start a new pod. Or in this particular case, requests per second goes beyond 10k, then we start another pod, and so on. Using a cluster autoscaler definitely helps to make the best utilization of the underlying resources, especially when you're scaling down. You make sure that you free up the resources that are not being used. But you need to be very careful not to cause any service disruption in the process, especially when you're downscaling. Specifying the max unavailable pods in the pod disruption budget definitely helps in this particular regard. So now if you're an SRE, you'll know that every runtime has many, many tunables. Java, for example, has more than 100 of them. But you'll also know that you should never touch them. Why?  And it has all these dependencies on other tunables. And there are just way too many of them for you to manually test and figure out. Also, how these run times behave in Kubernetes environments is not always clear. So guess what? Most of the time, an SRE is just limited to tuning the app itself or tuning just the CPU and memory. By tuning, you know, we all know what normally happens. We just end up doubling the resources until the problem goes away. So it is difficult to be an SRE, difficult to be an SRE, let's be honest. You have the users bugging you for better response times. The finance wants to cut costs all the time. And you have developers giving you a ton of options that you find it really difficult to use. So if you're thinking this got to be a smarter way, you're absolutely right. So we are really happy to announce that we have, you know, we have this new tool called cruise autotune. It's available publicly. It's an open source project we are from Red Hat. I do encourage you to take a look at our GitHub repo given below here. So let's take a deep dive into the whole process that autotune uses to tune application. So the first step here is that the SRE encapsulates all of the performance requirements into an objective function, which is an algebraic expression, such as, you know, a square divided by b plus c, where maybe a can be your throughput, b can be response time, c can be costs. And you want to either, you know, maximize or minimize the whole thing in this particular case, for example, if it is a square divided by b plus c, you might want to maximize it. And here, each of the individual variables of the objective function are specified as Prometheus queries. And the whole thing is applicable to a particular Kubernetes deployment, which can be selected using the selector out here. So at the heart of the autotune is the Bayesian optimization, which is provided by the HPO service that you see here. HPO is nothing but the hyper parameter optimization service. So Bayesian optimization is a type of black box optimization that uses probabilistic models of the objectives function that you have specified here. And that is searched efficiently to arrive at either the global maximum or the minimum as required.  So we have figured out what are the layers of the application, what are the layers of the stack and then send all of the tunables from those layers to the Bayesian optimization, which gives you a particular config value to try out. The experiment manager here deploys it and then we get a response, I mean, we monitor the pod with the trial configuration under load and then we get a summary of how it performed under load and then send it back to the Bayesian algorithm, which will look at the results and then try to find another config that will give you better results and so on. So this loop continues and, you know, after about 100 trials, you'll find that you, I mean, the Bayesian optimization has given you a config that will satisfy the objective function that you came out with and then we come up with a config recommendation. So that's in essence how we do this. So let's take a quick look at how this works. So I do have a small demo out here. So I have MiniCube running on my laptop here, as you can see, and it has Prometheus and Grafana installed in the MiniCube cluster. And I also have AutoProtune running here. And I have a TechCampower application, which is a Quarkus Resty Z Hibernate application that is also running here in the cluster. And so now the challenge here is to try and optimize this particular benchmark that is running. So what are we trying to optimize? We are trying to optimize the response time to try and minimize it. So response time is defined as request sum divided by request count, where request sum is this particular query, Prometheus query and request count is this particular Prometheus query. And this applies of course to the TechCampower deployment. And we are trying to minimize response time here. So let's try to apply this YAML here. And you can see that AutoTune starts to deploy specific configurations for and comes up with different configurations that it can test and see how it is doing under load. Of course, this being a very short demo, we are really not monitoring the load, but just giving you a sense of how the whole process works. So you can see here that it is starting multiple trials. And you can also take a look at list experiments here to see the conflicts that it is actually trying out. So here you can see it is trying with certain values of CPU and memory and also Java options that includes the hotspot layer that it has found and the quarkus layer. So very quickly you can also look at all the layers that it has found in the application here. So it has found the base container, hotspot and quarkus and so on. So if you keep monitoring this, it runs the whole set of trials and then comes up with the best trial at the end of the experiment to say, this is the one that had the best configuration. And you can take a look at the trial according to that particular trial number to figure out what was the best configuration. So that's a very quick demo of AutoTune. I would definitely recommend that you check out our GitHub repos and we have this demo also running, I mean, available on public GitHub. So it is available in this particular repo, github.com slash cruise slash cruise demos. This is the one that I was running just now. You should be able to even run it on your own laptop as well. And this is the main GitHub repo. So now that you've seen a very quick demo, what's really happening here is that the Bayesian optimization is quickly coming to try and find a particular config that gives you the best result. I usually compare the Bayesian optimization to a Jenny. However, there is one caveat here. The Jenny can only be asked for one wish. So you can involve the Jenny any number of times, which means that you can involve the Bayesian optimization for any number of experiments. But for every experiment that you're running, which consists of maybe even up to 100 trials, there can only be one objective function or only one wish. So you need to be really get creative with your wish. It's something like I want to be on a beach in Hawaii with my wife and kids and walk into my large house with this great internet and so on. So basically you're trying to put in all of your requirements into that one objective function. And then the Bayesian optimization will try to optimize for that particular objective function. So you've heard all of the theories so far. So let's take a look at some of the results. So here you see that as I mentioned, actually we were using the tech empower framework, which is actually an industry standard framework where you have benchmarks from for all different kinds of runtimes, Java, Golang, Rust, and Node.js, you name it. So we specifically picked up the Quarkus rest easy benchmark and ran this on a open shift cluster, which had this particular configuration. And it had all of these different tunables that we used, two tunables at the container layer, a bunch of tunables for the hotspot layer and a few for the Quarkus layer as well. And so these were the ranges within which they were operating. And we had set the Kubernetes request to be the same as the limits and we were using the G1 GCE garbage collector and max RAM percentage set equal to 70. The incoming load was constant at just 512 users. So we started off initially saying that, okay, we want to just minimize response time. But then we quickly realized that, as I mentioned, Bayesian optimization only tries to optimize that one aspect at the cost of maybe other aspects. So we realized that the low response time came at the cost of higher CPU usage. Then we did another experiment where we said, okay, fix the CPU usage, but give me lower response time. But this time we found out that it was giving us higher max response times or tail latencies. So this was the third take where we said, okay, Jenny, give me the best response time, the lowest response time, high throughput. And at the same time, keep the max response time or the tail latencies down and keep the resources fixed. So essentially, we gave it weightages as well. We said response time has the highest weightage, throughput comes next, max response time is the least in terms of the weightages and make sure that you fix the CPU and memory so that the cost is the same. So the 0th value here corresponds to the default one where there were no changes done to the application configuration with the same resources as the rest of the experiment. And so here we see that the default was about 14.21 milliseconds of response time. And then we see the autotune coming up with different configurations and trying them out. And then we got the best configuration around the 97th trial where it got a response time of 2.39 milliseconds. So you can see here that this has actually achieved about 83% better response time with a small or the throughput being almost the same. And of course, the tail latencies were low as well. So you can take a look at all of these results here. These are available on github.com, cruise slash autotune results repo. These are available publicly as well. So you can see that the max response time in the autotune case is down. The CPU usage is almost the same as the default. And we got really good response times, about 83% better response time as well. And we also calculated the cost of the hardware by looking at the data that we got from the previous experiment for both the default and the autotune config. We've measured how many instances it would take to handle one million transactions and applied it on a matching AWS configuration, aw1.extra-large, which is about 4 core 8 gig. And we observed with the autotune config there's 8% reduction in cost as well. So this is the corresponding best configuration. The right side column is the value for each of the tunables that we saw previously. Interestingly, you see that autotune has flipped some of the defaults from what the runtime itself sets. Okay. So in summary, if you're an SRE, your first step is to set up observability. Don't forget to tune the hardware. Set the node and pod affinities. Ensure requests and limits are set for all app pods and they're right sized. Use app-specific scaling metrics if possible. Ensure that there is no disruption with the pod disruption budget. And please do check out the cruise autotune for autonomous tuning. And we do plan to come back to you with some updates. So lastly, do check out the cruise GitHub repos. You have any questions, reach out to us on cruise Slack or send us a mail. We do look forward to hearing from you all. Thank you so much for listening. Hey, Denakar. Thanks a lot for the session and it was really informative and very helpful. And I hope the participants are benefited by this very informative session. And if you have any questions, you can post the questions on the chat. And Denakar is available to answer. Sorry. Yeah. A lot of the session and it was really informative and very helpful. And I hope the participants are benefited by this very informative session. And if you have any questions, you can post the questions on the chat. And Denakar is available to answer. Thank you, Ashok. Happy to answer any questions folks have here. Sorry. Yeah. Looks like there are not much questions, no questions on the chat that I see. But I have one question, Denakar. Say, if like, say if there is a fresh grad who would like to get into this open source space, like what is your recommendation that you would like to give or maybe someone who would like to switch their career path maybe after 10 years of experience. And if you think that, okay, they would like to switch their career path, what is your recommendation that you would like to give Denakar? Yeah. I think that's a general question. So I would say that, you know, the first step that I would always suggest is for people to understand what are their own preferences. You know, there is like a wide variety of open source software that's available today. I mean, there is system software front end, back end, machine learning, cloud and so on. So there's multiple different open source projects that are available. And I think that the best way is to first understand what are your own interests, and then find out projects in that particular space. So for example, you know, I'm a guy who's been interested in systems technology all my life. I've worked in operating systems, JVM and Kubernetes now and so on. So I always tend to look around in this space and see what are the new things coming up. And of course, now these days, I'm interested in machine learning, who is not right. Everybody, that's the buzzword now. So if you look around, I'm sure you'll find an open source project that you are interested in. So that's the first step. Next step is to find out what is the community around it? Find out who are the different stakeholders? Do they have a Slack channel? Do they have Gitter? Is there a mailing list? So go join there, find out what's the best way to interact. Look at GitHub, obviously, GitLab or anything that's around. Look at issues. Most of the projects these days have something like a good first issue that has been marked on GitHub issues. So you look at that and see what are the issues. It could be simple things like fixing language or maybe some simple issues and so on. So you can look at that and see if you can start getting into the project by understanding the process. How do you submit a PR? Basics of GitHub and things like that. And then you can read more on the topic, look at videos and talk to experts, talk to the community folks, see if there's a meet-up or attend some things like this KCD Chennai, understand more about the topic and then gradually you take it up there. So that's the way I would look at it. Sure. Thanks, Inkar. That answers my question. And I like the red hat on your backdrop. Thank you. Yeah, folks, please make use of this time for Q&A. And if you don't have any questions, then we'll have Inkar go so that he can enjoy the rest of the weekend. It's already Friday. Attend the rest of the talks. Thanks, Inkar. Thank you all and it's been a pleasure being in this. Thank you so much for organizing this great event. Sure. Thanks. Thanks, Inkar. Thank you. Bye. Bye. We'll have the next session starting in a few minutes. So please hang in there. Thanks.


Welcome back everyone to theCUBE's special presentation with Druva on why ransomware isn't your only problem. I'm John Furrier, host of theCUBE. Our next guest are Stephen Manley, Chief Technology Officer of Druva and on John Srinivas, who is the General Manager and Vice President of Product Management at Druva. Gentlemen, you got the keys to the kingdom, the technology, ransomware, data resilience. This is the topic, the IDC white paper that you guys put together with IDC. Really kind of nails it out. I want to get into it right away. Welcome to this segment, I really appreciate it. Thanks for coming on. Great to be here, John. So what's your thoughts on the survey's conclusion? Obviously the resilience is huge, ransomware continues to thunder away at businesses and causes a lot of problems, disruption. I mean, it's endless ransomware problems. What's your thoughts on the conclusion? So I'll say the thing that pops out to me on the one hand, everybody who sees the survey who reads it's gonna say, well, that's obvious. Of course, ransomware continues to be a problem. Cyber resilience is an issue that's plaguing everybody. But I think when you dig deeper, and there's a lot of subtleties to look into, but one of the things that I hear on a daily basis from the customers is, it's because the problem keeps evolving. It's not as if the threat was a static thing to just be solved and you're done because the threat keeps evolving. It remains top of mind for everybody because it's so hard to keep up with what's happening in terms of the attacks. And I think the other important thing to note, John, is that people are grappling with this ransomware attack all of a sudden where they were still grappling with a lot of legacy in their own environment. So they were not prepared for the advanced techniques that these ransomware attackers were bringing to market. It's almost like these ransomware attackers had a huge leg up in terms of technology that they had in their favor while keeping the lights on, was keeping IT away from all the tooling that needed to do. A lot of people are even still wondering when that happens next time, what do I even do? So clearly not very surprising. Clearly I think it's here to stay. And I think as long as people don't retool for a modern era of data management, this is going to stay this way. Yeah, I mean, I hear this all the time in our CUBE conversations with practitioners. You know, it's kind of like the security problem. Give me more tools. I'll buy anything that comes on the market. I'm desperate. There's definitely attention, but it doesn't seem like people are satisfied with the tooling that they have. Can you guys share kind of your insights into what's going on on the product side? Because, you know, people claim that they have tools at fine points of recovery opportunities, but they can't get there. So it seems to be that there's a confidence problem here in the market. How do you guys see that? Because I think this is where the rubber meets the road with ransomware because it is a moving train. It's always changing, but it doesn't seem there's confidence. Can you guys talk about that? What's your reaction? Yeah, let me jump in first and Steven can add to it. What happens is, I think this is a panic buying and they have accumulated this tooling now just because somebody said could solve your problem. But they haven't had a chance to take a relook from a ground up perspective to see where are the bottlenecks? Where are the vulnerabilities and which tooling set needs to lie where? Where does the logic need to reside? And what it through of your watching people do and people do it successfully is that as they have adopted through our technology which is ground up built for the cloud and really built in a way which is driven at a data insight level where we have people even monitoring our service for anomalies and activities that are suspicious. We know where we need to play a role in really kind of mitigating this ransomware. And then there is a whole plethora of ecosystem players that kind of combine to really finish the story so to say, right? So I think this has been a panic buying situation. This is like, get me any help you can give me. And I think as this settles down and people really understand that longer term as they really build out a true defense mechanism they need to think really ground up. They will start to really see the value of technologists like Dhruva and try to identify the right set of ecosystem to really bring together to solve it meaningfully. Yeah, I was gonna say, I mean, one of the really interesting things in the survey for me and for a moment, you know, a little more than a moment it made me think was that the large number of respondents who said, I've got a really efficient well run backup environment. Who then on basically the next question said, and I have no confidence that I can recover from a ransomware attack.  And I think that's the moment when we dug deeper and we realized if you've got a traditional architecture and it's facing the dis-based architecture has been around for almost two decades now in terms of dis-based backup, you can have that tuned to the help that can be running as efficiently as you want it. But it was built before the ransomware attacks before all these cyber issues really start hitting companies. And so I have this really well run traditional backup environment that is not at all built for these modern threat vectors. And so that's really why customers are saying, I'm doing the best I can. But as Anjan pointed out, the architecture of the tooling isn't there to support what problems I need to solve today. Great point. Well, that's a great point. And before we get into the customer side I want to get to in a second. You know, I interviewed Jaspreet, the founder, CEO many years ago, even before the pandemic and you mentioned modern. You guys have always had the cloud which roof. This is huge now that you're past the pandemic. What is that modern cloud edge that you guys have? Cause that's a great point. A lot of stuff was built kind of back in recovery, bolted on, not really kind of designed into the current state of the infrastructure and the cloud native application modern environment we're seeing right now is a huge issue. I think it's to me, there's three things that come up over and over and over again as we talk to people in terms of being built and cloud being cloud native wise and advantage. The first one is security and ransomware and we can go deeper, but the most obvious one that always comes up is every single backup you do with Drova is air gap offsite managed under a separate administrative domain so that you're not retrofitting any sort of air gap network and buying another appliance or setting up your own cloud environment to manage this every backup is ransomware protected, guaranteed. The second advantage is the scalability and this certainly plays into account as your business grows or in some cases as you shrink or repurpose workloads you're only paying for what you use but it also plays a big role again when you start thinking of ransomware recoveries because we can scale your recovery in cloud on premises as much or as little as you want. And then I think the third one is we're seeing basically things evolving new workloads, data sprawl, new threat factors and one of the nice parts of being a SaaS service in the cloud is you're able to roll out new functionality every two weeks and there's no upgrade cycle. There's no waiting, the customer doesn't have to say wow, I need it six months in the lab before I upgrade it and it's an 18 month, 24 month cycle before the functionality releases. You're getting it every two weeks and it's backed by Drova to make sure it works. That says, well, John, you got the product side it's a challenging job because you have so many customers asking for things probably on the roadmap you probably can go hour for that one but I want to get your thoughts on what you're hearing and seeing from customers. You know, we just reviewed the IDC with Phil how are you guys responding to your customer's needs because it seems that it's highly accelerated on the probably on the feature request but also structurally as ransomware continues to evolve what are you hearing? What's the key customer need? How are you guys responding? Yeah, actually I have two things that I hear very clearly when I talk to customers. One, I think after listening to their security problems and their vulnerability challenges because we see customers and help customers who are getting challenged by ransomware on a weekly basis. And what I find that this problem is not just a technology problem it's an operating model problem. So in order to really secure themselves they need a security operating model and a lot of them haven't figured out that security operating model in totality. Now where we come in as Dhruva is that we are providing them the cloud operating model and a data protection operating model combined with a data insights operating model which all fit into that overall security operating model that they are really owning and they need to manage and operate because this is just not about a piece of technology. On top of that, I think our customers are getting challenged by all the same challenges of not just spending time on keeping the lights on but innovating faster with less and that has been this age old problem do more with less but in this whole they're like trying to innovate in the middle of the war so to say, right? The war is happening, they're getting attacked but there's also new shadow IT challenges that's forcing them to make sure that they can manage all the new applications that are getting developed in the cloud. There is thousands of SaaS applications that they're consuming, not knowing which data is critical to their success and which ones to protect and govern and secure. So all of these things are coming at them at 100 miles per hour while they are just trying to live one day at a time and unless they really developed this overall security operating model helped by cloud native technologies like Dhruva that really providing them a true cloud native model of really giving like a touchless and an invisible protection infrastructure not just beyond backups, beyond just the data protection that we all know of into this kind of this mindset of kind of being able to look at where each of those functionalities need to lie. That's where I think they're grappling with. Now Dhruva is clearly helping them with keep up to pace with the public cloud innovations that they need to do and how to protect data. We just launched our EC2 offering to protect EC2 virtual machines back in AWS and we are going to be continuing to evolve that to further the many services that public clouds offer because our customers are really kind of consuming them at break next week. So the new workloads and new security capabilities love that good call out there. Steven, there's still the issue of their disruption side of it. You guys have a guarantee there's a cost to ownership as you get more tools. Can you talk about that angle of it? Because this is you got new workloads you got the new security needs. What's the disruption impact? Because we won't avoid that. How much is it gonna cost you? And you guys have this guarantee. Can you explain that? Yeah, absolutely. So Dhruva launched our $10 million data resiliency guarantee. And for us, there were really two key parts to this. The first obviously is $10 million means that we're willing to put our money where our mouth is. And that's a big deal, right? That we're willing to back this with the guarantee. But then the second part, and this is the part that I think reflects that sort of model that Anjan was talking about. We sort of look at this and we say, the goal of Dhruva is to do the job of protecting and securing your data for you so that you as a customer don't have to do it anymore. And so the guarantee actually protects you against multiple types of risks all with SLAs. So everything from your data is gonna be recoverable in the case of a ransomware attack. Okay, that's good. Of course, for it to be recoverable, we're also guaranteeing your backup success rate. We're also guaranteeing the availability of the service. We're guaranteeing that the data that we're storing for you can't be compromised or leaked externally. And we're guaranteeing the long-term durability of the data so that if you back up with us today and you need to recover 30 years from now, that data is gonna be recovered. So we wanted to really attack the end-to-end risks that affect our customers. Cyber security is a big deal, but it is not the only problem out there. And the only way for this to work is to have a service that can provide you SLAs across all of the risks because that means, again, as a SaaS vendor, we're doing the job for you. So you're buying results as opposed to technology. That's a great point. Ransomware isn't the only problem. That's the title of this presentation, but it's a big one. People are concerned about it. So great stuff. In the last five minutes, guys, if you don't mind, I'd love to have you share, what's on the horizon for Druva? You mentioned the new workloads on John. You mentioned this new security, you're hearing shift left, DevOps is now the developer model. They're running IT, you got data and security teams now stepping in and trying to be as high-velocity as possible for the developers and enterprises. What's on the horizon for Druva? What trends is the company watching and how are you guys putting that together to stay ahead in the marketplace and competition? Yeah, I think listening to our customers, what we realize is they need help with the public cloud number one. I think that's a big wave of consumption. People are consolidating their data centers, moving to the public cloud. They need help in expanding data protection, which becomes the basis of a lot of the security operating model that I talked about. They need that first from Druva before they can start to get into a much more advanced level of insights and analytics on that data to protect themselves and secure themselves and do interesting things with the data. So we are expanding our coverage on multiple fronts there. The second key thing is to really bring together a very insightful presentation layer, which I think is very unique to Druva because only we can look at multiple tenants, multiple customers because we are a SaaS vendor and look at insights and give them best practices and guidances and analytics that nobody else can give. There's no silo anymore because we are able to take a good big vision view and now help our customers with insights that otherwise that information map is completely missing. So we are able to guide them down a path where they can optimize which workloads need, what kind of protection and then how to secure them. So that is the second level of insights and analytics that we are building. And there's a whole plethora of security offerings that we are gonna build all the way from a feature level where we have things like a recycle bin that's already available to our customers today to prevent any anomalous behavior and attacks that would delete their backups and then they still have a way to recover from it. But also things to curate and get back to that point in time where it is safe to recover and help them with a sandbox which they can recover confidently knowing it's not going to jeopardize them again and reinfect the whole environment again. So there's a whole bunch of things coming but the key themes are public cloud data insights and security and that's where my focus is to go and get those features delivered. And Steven can add a few more things around services that Steven is looking to build and launch. Sure, so yeah, so John, I think one of the other areas that we see just an enormous groundswell of interest. So public cloud is important but there are more and more organizations that are running hundreds if not thousands of SaaS applications and a lot of those SaaS applications have data. So there's the obvious things like Microsoft 365, Google Workspace, but we're also seeing a lot of interest in protecting Salesforce because if you think about it, if someone deletes some really important records in Salesforce, that's actually kind of the record of your business. And so we're looking at more and more SaaS application protection and really getting deep in that application awareness. It's not just about backup and recovery when you look at something like a Salesforce or something like Microsoft 365, you do wanna look into sandboxing. You wanna look into long-term archival because this is the new record of the business. What used to be in your on-premises databases, that all lives in cloud and SaaS applications now. So that's a really big area of investment for us. The second one just to echo what Anjan said is, one of the great things of being a SaaS provider is I have metadata that spans across thousands of customers and tens of billions of backups a year. I'm tracking all sorts of interesting information that is going to enable us to do things like make backups more autonomous so that customers, again, I wanna do the job for them. We'll do all the tuning, we'll do all the management for them to be able to better detect ransomware attacks, better respond to ransomware attacks because we're seeing across the globe. And then, of course, being able to give them more insight into what's happening in their data environment so they can get a better security posture before any attack happens. Because let's face it, if you can set your data up more cleanly, you're gonna be a lot less worried and a lot less exposed when that attack happens. So we wanna be able to, again, cover those SaaS applications in addition to the public cloud. And then we wanna be able to use our metadata and use our analytics and use this massive pipeline we've got to deliver value to our customers, not just charts and graphs, but actual services that enable them to focus their attention on other parts of the business. That's great stuff, John. And remember, John, I think all this while keeping things really easy to consume, consumer-grade UI, APIs, and really the power of SaaS as a service, simplicity to kind of continue on amongst kind of keeping these complex technologies together. Andre, that's a great call out. I was gonna mention ease of use and self-service. Big part of the developer and IT experience expected is the table stakes. Love the analytic angle. I think that brings the scale to the table and faster time to value to get to learn best practices. But at the end of the day, automation, cross-cloud protection and security to protect and recover. This is huge. And this is a big part of not only just protecting against ransomware and other things, but really being fast and being agile. So really appreciate the insights. Thanks for sharing on this segment, really under the hood and really kind of the value of the product. Thanks for coming on. Appreciate it. Thank you very much. Okay, there it is. You got the expert talking about under the hood, the product of value, the future of what's going on with Druva and the future of cloud native, protecting and recovering. This is what it's all about. It's not just ransomware. They have to worry about it. In a moment, Dave Vellante will give you some closing thoughts on the subject here. You're watching theCUBE, the leader in high-tech enterprise coverage. As organizations migrate their business processes to multi-cloud environments, they still face numerous threats and risks of data loss. With a growing number of cloud platforms and fragmented applications, it leads to an increase in data silos, sprawl and management complexity. As workloads become more diverse, it's challenging to effectively manage data growth, infrastructure and resource costs across multiple cloud deployments. Using numerous backup vendor solutions for multiple cloud platforms can lead to management complexity. More importantly, the lack of centralized visibility and control can leave you exposed to security vulnerabilities, including ransomware that can cripple your business. The Druva Data Resiliency Cloud is the only 100% SaaS data resiliency platform that provides centralized, secure, air-gapped and immutable backup and recovery. With Druva, your data is safe with multiple layers of protection and is ready for fast recovery from cyber attacks, data corruption or accidental data loss. Through a simple, easy to manage platform, you can seamlessly protect fragmented, diverse data at scale across public clouds and your business-critical SaaS applications. Druva is the only 100% SaaS vendor that can manage, govern and protect data across multiple clouds and business-critical SaaS applications. It supports not just backup and recovery, but also data resiliency across high-value use cases, such as e-discovery, sensitive data governance, ransomware and security. No other vendor can match Druva for customer experience, infinite scale, storage optimization, data immutability and ransomware protection. The Druva Data Resiliency Cloud, your data, always safe, always ready. Visit druva.com today to schedule a free demo. One of the big takeaways from today's program is that in the scramble to keep business flowing over the past two plus years, a lot of good technology practices have been put into place, but there's much more work to be done. Specifically, because the frequency of attacks is on the rise and the severity of lost, stolen or inaccessible data is so much higher today, business resilience must be designed into architectures and solutions from the start. It cannot be an afterthought. Well, actually it can be, but you won't be happy with the results. Now, part of the answer is finding the right partners, of course, but it also means taking a system's view of your business, understanding the vulnerabilities and deploying solutions that can balance cost efficiency with appropriately high levels of protection, flexibility, and speed slash accuracy of recovery. You know, we hope you found today's program useful and informative. Remember, this session is available on demand in both its full format and the individual guest segments. All you got to do is go to thecube.net and you'll see all the content or you can go to druva.com. There are tons of resources available, including analyst reports, customer stories, there's this cool TCO calculator. You can find out what pricing looks like and lots more. Thanks for watching. Why ransomware isn't your only problem made possible by Druva, a collaboration with IDC and presented by theCUBE, your leader in enterprise and emerging tech coverage.


Hi, my name is Magnifique Mokonua and I am a senior at Tufts studying environmental health engineering and entrepreneurship. I'm from Rwanda and as I'm recording this video you know, I'm recording it from Rwanda and I'm very grateful for being home, you know in this pandemic. It's it's been a great time to be you know next to my family as I am finishing up my degree online. And I wanted to thank the Tufts community for having hosted me for four years. You've played a big part in my transition, everyone, my professors, mentors, you know fellow Tufts students, my friends, you know like different departments, of course including IGL for having tremendously supported me in the past four years so that I could explore and realize my dreams. IGL has greatly played a big part in my college career. I came in contact with IGL in 2017 as a sophomore. At that time I was looking for funding to go to Guatemala to be part of a medical brigade that was organized by the Tufts team in Global Health and I'm very grateful that I was able to go to Guatemala, be part of a team that is providing medical services to the disadvantaged population. And I again worked with IGL when I was selected as an Empower Fellow to do a project that I called to the Waters. To the Waters is an organization that I founded that tackles issues related to water, sanitation, poverty and more in rumor areas in Rwanda. I'm very grateful that IGL provided you know funding, mentorship in doing market research for it to the waters. I'm very happy that I was able to visit places connect with people in the social entrepreneurship sector, you know, speak to our stakeholders. I'm very grateful for that. For my next plans, I've accepted an offer from Pitvidura, which is a sanitation logistics company that is bringing dignity to communities and sanitation workers in Kigali, Rwanda. I'm very thankful to be part of this organization, this amazing company that is really providing essential services in these, you know, challenging times in history. I'll always be thankful for having attended TAFTS because the education, the opportunities, experience that I got from attending TAFTS has greatly transformed me. It has allowed me to learn about my passions and interests and I'm so thankful that IGL played a big part in my college journey. Thank you so much.