WEBVTT 1 00:00:00.480 --> 00:00:02.160 Michael Novinson: Hello, this is Michael Novinson with 2 00:00:02.160 --> 00:00:05.070 Information Security Media Group. I'm joined today by 3 00:00:05.070 --> 00:00:08.550 Poojan Kumar. He is the co-founder and CEO at Clumio. 4 00:00:09.000 --> 00:00:10.410 Good afternoon, Poojan. How are you? 5 00:00:11.010 --> 00:00:13.620 Poojan Kumar: Good, Michael. I'm great. How are you doing? 6 00:00:13.620 --> 00:00:15.600 Michael Novinson: I'm doing really well. Thank you so much 7 00:00:15.600 --> 00:00:18.990 here for the time. Why don't you start off by talking about an 8 00:00:18.990 --> 00:00:21.900 announcement you made in early November of some new data 9 00:00:21.900 --> 00:00:25.500 protection and recovery capabilities for S3? A two-part 10 00:00:25.500 --> 00:00:29.070 question for you to start with. First off, why did you decide to 11 00:00:29.070 --> 00:00:31.200 launch this? And then secondly, what are some of the biggest 12 00:00:31.200 --> 00:00:33.660 challenges around securing S3 buckets? 13 00:00:34.290 --> 00:00:38.910 Poojan Kumar: Yeah, absolutely. As we all know, a lot of the 14 00:00:38.910 --> 00:00:41.940 application development is happening in the public cloud 15 00:00:41.940 --> 00:00:45.960 now. You know, there's been a huge transition of applications 16 00:00:45.960 --> 00:00:49.020 moving from data centers into the public cloud. And the 17 00:00:49.020 --> 00:00:53.670 foundation behind a lot of these applications has been S3, was 18 00:00:53.670 --> 00:00:59.520 basically the first service launched by AWS more than 15 19 00:00:59.520 --> 00:01:03.300 years ago at this point, if my memory serves right. But more 20 00:01:03.300 --> 00:01:07.860 and more, it went from being a dumping ground of data to 21 00:01:07.890 --> 00:01:12.240 becoming the data store for critical applications built in 22 00:01:12.240 --> 00:01:15.300 the public cloud, right? So much so that if you see a lot of the 23 00:01:15.300 --> 00:01:19.440 SAS applications of today, are all, you know, have their data 24 00:01:19.440 --> 00:01:25.620 sitting in S3. And so as that has happened, I would say it has 25 00:01:25.620 --> 00:01:31.260 become a very important source of, you know, both deletions 26 00:01:31.260 --> 00:01:33.720 happening accidentally because of the amount of data sitting 27 00:01:33.720 --> 00:01:37.410 there, a place for attacks, because there's so much 28 00:01:37.410 --> 00:01:41.910 important data sitting there where bad actors can essentially 29 00:01:41.910 --> 00:01:46.380 go after S3 data, and also software bugs that could 30 00:01:46.380 --> 00:01:50.160 essentially create, you know, issues around the deletion of S3 31 00:01:50.160 --> 00:01:54.870 data. So protecting and backing up that S3 data has become super 32 00:01:54.870 --> 00:01:59.910 important. And so to that effect, we were the first vendor 33 00:01:59.910 --> 00:02:03.930 and the pioneers in going and saying, "S3 backup and S3 data 34 00:02:03.930 --> 00:02:07.710 protection is needed." And we launched a service, you know, an 35 00:02:07.710 --> 00:02:10.830 extension to our existing platform to go and start backing 36 00:02:10.830 --> 00:02:16.320 up S3, about close to nine months to a year ago. More 37 00:02:16.320 --> 00:02:21.180 recently, we have enhanced that S3 backup and data protection 38 00:02:21.180 --> 00:02:26.400 with three big things, right? One is really reducing the 39 00:02:27.090 --> 00:02:30.270 frequency in which you can essentially go and back up your 40 00:02:30.270 --> 00:02:33.810 data. So essentially, every 15 minutes, you can essentially 41 00:02:33.810 --> 00:02:38.700 have a copy of the data so that you can restore to any point, 42 00:02:39.060 --> 00:02:41.940 and within the 15-minute intervals. That's number one. 43 00:02:42.300 --> 00:02:46.500 Number two, we have gone and drastically scaled the offering, 44 00:02:46.500 --> 00:02:51.720 and basically gone and said that we can do 50 billion in objects 45 00:02:51.840 --> 00:02:55.170 in a bucket. And even with that kind of scale, which some 46 00:02:55.170 --> 00:02:58.320 enterprises do have that kind of scale already. And it's very 47 00:02:58.320 --> 00:03:01.230 easy to get to, you know, hundreds of millions and 48 00:03:01.230 --> 00:03:05.490 billions of objects scale in S3. And even in that scale, since 49 00:03:05.490 --> 00:03:09.630 the Clumio platform was natively built in the public cloud, for 50 00:03:09.630 --> 00:03:12.780 the first time, we can essentially go and protect any 51 00:03:12.780 --> 00:03:15.870 of that scale. So that was the second big announcement. And the 52 00:03:15.870 --> 00:03:20.520 third big announcement last month or earlier this month was 53 00:03:20.520 --> 00:03:25.590 really around recovery, because what is in a backup without 54 00:03:25.590 --> 00:03:27.960 recovery, right? There's no point of backing up if you can't 55 00:03:27.960 --> 00:03:32.820 recover and especially can't recover fast. And so as you go 56 00:03:32.820 --> 00:03:35.520 into S3 and kind of scale environments, it becomes very 57 00:03:35.520 --> 00:03:38.310 important to go and recover fast. And sometimes, you want to 58 00:03:38.310 --> 00:03:41.250 recover because, you know, you're to recover the data. And 59 00:03:41.250 --> 00:03:42.990 sometimes you want to recover because you need to test 60 00:03:42.990 --> 00:03:46.620 something out, or an application needs some access to a part of 61 00:03:46.620 --> 00:03:49.050 the bucket and stuff like that. So to that effect, we announced 62 00:03:49.050 --> 00:03:53.100 what we call instant recovery, right? And so basically zero 63 00:03:54.810 --> 00:03:58.440 recovery time objective and essentially, an ability to 64 00:03:58.500 --> 00:04:03.480 instantly recover any part of your S3 backup directly from 65 00:04:03.510 --> 00:04:08.040 Clumio. And that is huge. And it opens up a lot of new use cases 66 00:04:08.430 --> 00:04:09.330 for S3 backup. 67 00:04:11.190 --> 00:04:12.750 Michael Novinson: What are some of the key differences between 68 00:04:12.750 --> 00:04:16.170 recovering in a traditional IT on-premises environment versus 69 00:04:16.380 --> 00:04:18.840 attempting to recover in AWS and S3? 70 00:04:19.860 --> 00:04:22.320 Poojan Kumar: Yeah, it's night and day, right? Because I think 71 00:04:22.350 --> 00:04:27.960 the big difference is in the cloud, the scale at which you're 72 00:04:27.960 --> 00:04:31.770 dealing with things is very different. So that's number one, 73 00:04:31.800 --> 00:04:37.440 right? The level at which you're going and scaling and recovering 74 00:04:37.440 --> 00:04:41.760 is very different. Number two is really around the architecture. 75 00:04:41.940 --> 00:04:45.240 Because your on-premises environment is a lot more 76 00:04:45.240 --> 00:04:49.020 controlled. And, you know, you have control over how you 77 00:04:49.020 --> 00:04:51.960 recover and the cost structure and so on and so forth, right? 78 00:04:52.290 --> 00:04:55.380 In the cloud, if you don't do it the right way, sometimes these 79 00:04:55.380 --> 00:04:58.920 recoveries can be super expensive, so which is where our 80 00:04:58.920 --> 00:05:02.700 ability to go and really target - if I only want to recover a 81 00:05:02.700 --> 00:05:06.090 certain bucket, or within a bucket a certain prefix, because 82 00:05:06.090 --> 00:05:09.300 every other thing sitting in the bucket could be logged data, for 83 00:05:09.300 --> 00:05:13.710 my application data was prefixed by a certain prefix and only 84 00:05:13.740 --> 00:05:17.070 being able to go and recover that particular prefix and all 85 00:05:17.070 --> 00:05:19.920 the objects corresponding to that prefix, and figuring out 86 00:05:19.920 --> 00:05:23.400 which location I want to recover into, all of these things become 87 00:05:23.400 --> 00:05:27.090 much more important, because we did not have an S3 like thing 88 00:05:27.330 --> 00:05:29.730 that people would build applications on in the on-prem 89 00:05:29.730 --> 00:05:30.030 world. 90 00:05:32.220 --> 00:05:34.350 Michael Novinson: Interesting. And why don't you share a sense 91 00:05:34.350 --> 00:05:37.680 in terms of the broader context of where do data protection 92 00:05:37.680 --> 00:05:41.220 recovery fit into the overall S3 security posture? How 93 00:05:41.220 --> 00:05:43.560 significant are these pieces to the overall mission? 94 00:05:44.920 --> 00:05:47.410 Poojan Kumar: Yeah, so I think this is where, if you think 95 00:05:47.410 --> 00:05:54.310 about it, as more and more data is landing on S3, what has 96 00:05:54.310 --> 00:05:58.090 happened is some of these things have become a top of mind. Now, 97 00:05:58.090 --> 00:06:03.220 there's a lot of overall things that you have to think about in 98 00:06:03.220 --> 00:06:06.040 the S3 context. Obviously, we are important piece of the 99 00:06:06.070 --> 00:06:08.470 puzzle in terms of going and recovering your data, because 100 00:06:08.740 --> 00:06:12.580 the cloud vendor tells you that the infrastructure resiliency 101 00:06:12.790 --> 00:06:16.690 and the security of the cloud is their responsibility, but the 102 00:06:16.690 --> 00:06:20.260 security of your data, and being able to back up and protect your 103 00:06:20.260 --> 00:06:24.910 data is your responsibility. And so to that effect, people have 104 00:06:24.910 --> 00:06:30.100 to think about, in the context of S3 specifically, is like 105 00:06:30.100 --> 00:06:35.230 visibility into the data, really coming to know what data is 106 00:06:35.320 --> 00:06:38.500 leaving their environment, what data is staying, what data is 107 00:06:38.500 --> 00:06:41.080 getting deleted, is the right data getting deleted, or there's 108 00:06:41.080 --> 00:06:44.290 some rogue script or runaway script that's going and deleting 109 00:06:44.530 --> 00:06:47.020 the wrong set of data, and so on, and so forth. So there's a 110 00:06:47.020 --> 00:06:51.700 lot of things both in terms of keeping into account, data 111 00:06:51.700 --> 00:06:54.310 leaving the environment like exfiltration, type solutions, 112 00:06:54.340 --> 00:07:00.160 and deletions, both by manually or by a script. All of these 113 00:07:00.160 --> 00:07:03.700 things are a holistic thing that people have to think about when 114 00:07:03.700 --> 00:07:06.610 they think about an S3 backup and data protection. 115 00:07:08.620 --> 00:07:10.792 Michael Novinson: In terms of the public cloud providers, in 116 00:07:10.844 --> 00:07:13.844 recent years, we've seen them increasingly taking steps to 117 00:07:13.895 --> 00:07:16.844 offer their own security tools and products, particularly 118 00:07:16.895 --> 00:07:19.533 Microsoft, but some of the others as well. From the 119 00:07:19.585 --> 00:07:22.844 standpoint of a customer, why is it beneficial to engage with a 120 00:07:22.895 --> 00:07:25.688 third party like Clumio for security, rather than just 121 00:07:25.740 --> 00:07:28.947 purchasing some of these add-on security offerings that an AWS 122 00:07:28.999 --> 00:07:29.620 might offer? 123 00:07:29.000 --> 00:07:31.646 Poojan Kumar: Yeah, there's multiple reasons. So, think 124 00:07:31.711 --> 00:07:35.455 about Clumio offering. A lot of times, you know, customers 125 00:07:35.520 --> 00:07:39.135 actually want data and the security to be outside of the 126 00:07:39.200 --> 00:07:42.750 security domain. So when somebody backs up with Clumio, 127 00:07:42.815 --> 00:07:46.107 they know for a fact that the data is leaving their 128 00:07:46.172 --> 00:07:50.174 environment and going into the Clumio service, which is a very 129 00:07:50.239 --> 00:07:54.112 good thing because now it's basically leaving their security 130 00:07:54.177 --> 00:07:58.179 domain into the Clumio security domain, so to speak. And there 131 00:07:58.244 --> 00:08:02.182 is no way for anybody, there's no delete button in our UI, so 132 00:08:02.246 --> 00:08:06.249 that you can go and essentially delete the backup, if assuming 133 00:08:06.313 --> 00:08:10.058 you were to be hacked and stuff like that. If you built it 134 00:08:10.122 --> 00:08:14.125 yourself, at the end of the day, it's in your security domain. 135 00:08:14.189 --> 00:08:17.611 And if your primary gets compromised, the chances are 136 00:08:17.675 --> 00:08:21.484 very high that, you know, you could get compromised on your 137 00:08:21.549 --> 00:08:25.164 backup too, and that could be true for your own software 138 00:08:25.229 --> 00:08:28.521 having a bug and deletions happening. So it becomes 139 00:08:28.586 --> 00:08:32.524 extremely important to use a third-party service like ours to 140 00:08:32.588 --> 00:08:36.591 really have that benefit. That's number one. Number two is the 141 00:08:36.655 --> 00:08:40.529 focus, means while, you know, the cloud vendors and folks do 142 00:08:40.593 --> 00:08:44.531 build solutions, but they are going extremely wide, they have 143 00:08:44.596 --> 00:08:48.534 to go and build everything from an AI, ML service to security 144 00:08:48.598 --> 00:08:52.665 service to a backup service to a database service. And you name 145 00:08:52.730 --> 00:08:56.474 it, right. So it's extremely broad, this thing. So this is 146 00:08:56.539 --> 00:09:00.025 where you will see more and more, you know, ISPs we're 147 00:09:00.089 --> 00:09:03.834 already seeing a lot of ISPs around - look at what Datadog 148 00:09:03.898 --> 00:09:07.901 does and what Snowflake does, what Confluent does and now what 149 00:09:07.965 --> 00:09:11.645 Clumio does. More and more ISPs going and building a true 150 00:09:11.710 --> 00:09:15.777 enterprise grade solution on the public cloud for that specific 151 00:09:15.841 --> 00:09:19.844 use case and delivering it in a multicloud offering over time. 152 00:09:19.908 --> 00:09:23.717 And so that is something that you'll continue to see. While 153 00:09:23.782 --> 00:09:27.655 there'll be solutions from the cloud vendors themselves, but 154 00:09:27.720 --> 00:09:31.077 the best of breed, like it always happened in on the 155 00:09:31.141 --> 00:09:35.208 on-prem side, the best of breed is always going to come from an 156 00:09:35.273 --> 00:09:36.500 ISP vendor outside. 157 00:09:36.000 --> 00:09:38.631 Michael Novinson: So let's talk a little bit about that market 158 00:09:38.691 --> 00:09:42.578 landscape, the ISP landscape, so particularly when you're talking 159 00:09:42.638 --> 00:09:45.569 about AWS security or S3 security, if you're in a 160 00:09:45.629 --> 00:09:49.098 competitive bid scenario, who are you going up against the 161 00:09:49.157 --> 00:09:52.985 most frequently and what do you feel sets Clumio apart from some 162 00:09:53.045 --> 00:09:54.780 of your most frequent rivals? 163 00:09:55.680 --> 00:09:59.640 Poojan Kumar: Yeah, our big advantage is we were natively 164 00:09:59.640 --> 00:10:04.560 built from day one, which basically, you know, the ability 165 00:10:04.560 --> 00:10:07.500 to do these things, all the innovations we have come up 166 00:10:07.500 --> 00:10:10.140 with, like we were the first ones to do S3, were the first 167 00:10:10.140 --> 00:10:14.370 ones to even come close to doing an instant recovery. In the 168 00:10:14.370 --> 00:10:17.520 billions of objects scale, all of these things are continuous 169 00:10:17.520 --> 00:10:21.210 backups that we just talked about. Everything that you see, 170 00:10:21.240 --> 00:10:26.160 we are the first. And the reason we are the first again and again 171 00:10:26.370 --> 00:10:31.500 is because architecture matters. And so, while there's a bunch of 172 00:10:31.500 --> 00:10:34.680 companies in the space, but they were really, you know, born and 173 00:10:34.680 --> 00:10:36.690 built. And they're phenomenal companies, but they're all 174 00:10:36.690 --> 00:10:40.230 really born and built in the on-premises world. And so for 175 00:10:40.230 --> 00:10:43.830 them to go pivot to the cloud, both the scale doesn't work, the 176 00:10:43.830 --> 00:10:47.580 cost structure doesn't work, the architecture doesn't really, you 177 00:10:47.580 --> 00:10:52.620 know, is not optimized to work at the cloud scale and deliver a 178 00:10:52.620 --> 00:10:55.410 solution at the right cost. So there's so many limitations, 179 00:10:55.440 --> 00:10:59.370 right? For any other solution, that typically, the only 180 00:10:59.370 --> 00:11:02.700 competition that we face, generally, when we talk to a 181 00:11:02.730 --> 00:11:05.670 customer in the public cloud is customer trying to basically, 182 00:11:05.970 --> 00:11:09.060 you know, doing it themselves basically on AWS is like a bunch 183 00:11:09.060 --> 00:11:12.780 of Lego blocks that I need to go and build my Lego. Whereas when 184 00:11:12.810 --> 00:11:16.590 Clumio comes in, we are essentially delivering the Lego 185 00:11:16.830 --> 00:11:20.640 to the customer. And, you know, delivering it at obviously in an 186 00:11:20.670 --> 00:11:24.210 architecture that scales the right price point. And obviously 187 00:11:24.540 --> 00:11:27.720 a solution that is naturally air gapped, and so on and so forth. 188 00:11:27.720 --> 00:11:32.340 So do it yourself is typically the big competition. And that's 189 00:11:32.340 --> 00:11:35.460 not to be, you know, and that's not unexpected, because before 190 00:11:35.460 --> 00:11:37.740 we existed, people were looking to solve this problem, and they 191 00:11:37.740 --> 00:11:39.270 were forced to kind of do it themselves. 192 00:11:40.890 --> 00:11:43.650 Michael Novinson: Interesting. I know we've talked quite a bit 193 00:11:43.650 --> 00:11:46.140 about data protection and recovery, the new capability you 194 00:11:46.140 --> 00:11:49.350 have. Wanted to talk about kind of overall across the Clumio 195 00:11:49.350 --> 00:11:51.810 product portfolio to get a better sense of what's been the 196 00:11:51.810 --> 00:11:55.380 fastest growing area to Clumio business in 2022, and why? 197 00:11:56.430 --> 00:11:59.910 Poojan Kumar: Yeah, for us, it is been around, you know, we 198 00:11:59.970 --> 00:12:02.550 obviously have a comprehensive service that if you think about 199 00:12:02.550 --> 00:12:08.910 it, we go in, protect pretty much all services that matter on 200 00:12:08.910 --> 00:12:14.580 the AWS side, your EC2, EBS, RDS, Dynamo, you know, S3 and so 201 00:12:14.580 --> 00:12:17.070 on, and so forth. So we basically cover your bases in 202 00:12:17.070 --> 00:12:20.640 the entire application, we have Microsoft 365 that we also 203 00:12:20.670 --> 00:12:25.710 protect, we also support VMware running on AWS, so it's a pretty 204 00:12:25.980 --> 00:12:30.540 broad offering, but our fastest growing is S3. Because, again, I 205 00:12:30.540 --> 00:12:34.470 think there was a lot of pent up demand on the S3 side, and more 206 00:12:34.470 --> 00:12:38.580 and more, we're getting asked for a lot of newer things on the 207 00:12:38.580 --> 00:12:58.950 S3 side, because again, every cloud-native application has 208 00:12:45.090 --> 00:12:47.157 Michael Novinson: Why don't you talk a little bit about the 209 00:12:47.207 --> 00:12:50.232 macroeconomic environment. In recent months, there have been 210 00:12:50.282 --> 00:12:53.408 increasing discussions about a slowdown due to rising interest 211 00:12:53.458 --> 00:12:56.483 rates due to supply chain issues due to inflation. And I was 212 00:12:56.534 --> 00:12:59.357 wondering, how are you seeing that manifested in Clumio, 213 00:12:58.980 --> 00:13:04.380 some element of S3, if not all of it around it. 214 00:12:59.407 --> 00:13:02.382 either in terms of customer buying behavior, or in terms of 215 00:13:02.432 --> 00:13:05.760 actions you've taken at the company to adjust to this new reality? 216 00:13:05.000 --> 00:13:07.838 Poojan Kumar: Yeah, I mean, I think there's definitely a bunch 217 00:13:07.897 --> 00:13:11.267 of uncertainties around this thing. Now, I think the good 218 00:13:11.326 --> 00:13:14.874 news, at least for a company like ours is, at the end of the 219 00:13:14.933 --> 00:13:18.363 day, there is still a lot of movement to the public cloud. 220 00:13:18.422 --> 00:13:21.970 But now I think more and more, there is going to be a lot of 221 00:13:22.029 --> 00:13:25.281 optimization that needs to happen in the cloud, because 222 00:13:25.340 --> 00:13:28.888 people are looking at how the budget looks like for the next 223 00:13:28.947 --> 00:13:32.318 year, and they're looking at the costs and looking at the 224 00:13:32.377 --> 00:13:35.865 revenue. And so obviously, there's a lot of belt tightening 225 00:13:35.924 --> 00:13:39.236 that is happening. So for us, it's been, at least from a 226 00:13:39.295 --> 00:13:42.843 customer-facing perspective, it's been great, because one of 227 00:13:42.902 --> 00:13:46.450 the things we also do is we give the right visibility to the 228 00:13:46.509 --> 00:13:50.056 customer, and we help them in terms of the costs, on the AWS 229 00:13:50.116 --> 00:13:53.427 costs, specifically on the protection side, which again, 230 00:13:53.486 --> 00:13:56.975 ultimately, helps in their overall costs and visibility. So 231 00:13:57.034 --> 00:14:00.818 that part of the message for us actually has been good synergist 232 00:14:00.877 --> 00:14:04.543 in a very synergistic in terms of what the next 12 months look 233 00:14:04.602 --> 00:14:07.677 like. Having said that, obviously, I think it really 234 00:14:07.736 --> 00:14:10.929 matters in terms of the initiative the customer has at 235 00:14:10.988 --> 00:14:14.773 the end of the day. And more and more, at least we see that even 236 00:14:14.832 --> 00:14:18.143 though there is a lot of tightening happening, the right 237 00:14:18.202 --> 00:14:21.632 areas do get the investments. So, it's for us, it's really 238 00:14:21.691 --> 00:14:24.943 about going and attaching ourselves to the digitization 239 00:14:25.002 --> 00:14:28.550 initiatives, which ultimately, you know, moves the customers 240 00:14:28.609 --> 00:14:32.216 forward. So, we're seeing more and more of that, and it's not 241 00:14:32.275 --> 00:14:35.705 really impacting us from that perspective. But having said 242 00:14:35.764 --> 00:14:38.780 that, we're also very cautious as we get into 2023. 243 00:14:38.000 --> 00:14:40.656 Michael Novinson: Let me ask you here. Finally, I'll ask you to 244 00:14:40.715 --> 00:14:44.138 gaze into your crystal ball and take a look ahead to 2023. 245 00:14:44.197 --> 00:14:47.149 What's your customers or prospects watching for at 246 00:14:47.208 --> 00:14:50.691 Clumio? What are the biggest things you're hoping to invest 247 00:14:50.750 --> 00:14:52.580 in our work, in the year ahead? 248 00:14:53.710 --> 00:14:57.610 Poojan Kumar: Yeah, I mean, for us, we're just getting started 249 00:14:57.850 --> 00:15:01.030 with this whole thing. If you think about it, it's all about 250 00:15:01.030 --> 00:15:04.690 the data, right? Everybody knows that. And we are in the business 251 00:15:04.720 --> 00:15:08.440 today of going and backing up and protecting the data of the 252 00:15:08.440 --> 00:15:11.860 customer across all of their services. There's still a lot 253 00:15:11.860 --> 00:15:15.730 more to go in terms of where the data resides for the customer. 254 00:15:15.730 --> 00:15:20.530 So Clumio's innovation and roadmap is really aligned into, 255 00:15:20.530 --> 00:15:25.870 I would say, three fundamental pillars. Number one is going and 256 00:15:26.110 --> 00:15:32.290 expanding, right? In terms of all of the avenues that the 257 00:15:32.290 --> 00:15:36.370 customer data is in, number two is going and building deeper 258 00:15:36.370 --> 00:15:41.080 innovation, like we talked about with the instant recovery piece, 259 00:15:41.110 --> 00:15:45.070 which really enables a bunch of other use cases. So going deep 260 00:15:45.070 --> 00:15:49.390 in the innovation side in the data, and number three is 261 00:15:49.870 --> 00:15:53.290 essentially going and deriving more value in the data of the 262 00:15:53.290 --> 00:15:57.250 customer. So there's a lot of vectors in which you can expect 263 00:15:57.250 --> 00:16:00.130 a ton of innovation to come out from Clumio. 264 00:16:01.540 --> 00:16:03.610 Michael Novinson: So definitely be interesting to watch. Poojan, 265 00:16:03.610 --> 00:16:04.810 thank you so much here for the time. 266 00:16:05.440 --> 00:16:06.940 Poojan Kumar: Thank you, Michael. Really appreciate the 267 00:16:06.940 --> 00:16:08.500 time. You're very welcome. 268 00:16:08.500 --> 00:16:10.540 Michael Novinson: We've been speaking with Poojan Kumar. He 269 00:16:10.540 --> 00:16:14.470 is the co-founder and CEO of Clumio. For Information Security 270 00:16:14.470 --> 00:16:17.620 Media Group, this is Michael Novinson. Have a nice day.