1 00:00:25,120 --> 00:00:39,160 None. Welcome to the Young Sport 2 00:00:39,160 --> 00:00:41,520 Territor podcast. With this episode I invited our 3 00:00:41,520 --> 00:00:44,760 cash back to the show to talk us through the VCF Native S3 object 4 00:00:44,760 --> 00:00:46,840 storage announcement. Welcome back to the show, 5 00:00:46,840 --> 00:00:49,640 Rakesh. Thank you, Duncan, as always, 6 00:00:49,640 --> 00:00:52,080 excited to be here and have a great conversation with you. 7 00:00:52,400 --> 00:00:54,320 Yeah, the last time you were here, we were actually talking 8 00:00:54,320 --> 00:00:57,160 about VCENT over Fibre Channel. Today we're going to be talking 9 00:00:57,160 --> 00:00:59,720 about the native S3 solution that we just announced. 10 00:01:00,120 --> 00:01:02,840 But before we do, not everyone may have listened to the 11 00:01:02,840 --> 00:01:05,560 previous episode, so maybe you can first introduce yourself. 12 00:01:05,760 --> 00:01:07,160 Who is Rakesh and what do you do? 13 00:01:08,000 --> 00:01:10,640 Sure. At VM Ware Broadcom, my current 14 00:01:10,640 --> 00:01:12,800 role is Senior Director of Product Management. 15 00:01:13,000 --> 00:01:16,120 I'm the product head for storage data and data protection. 16 00:01:16,760 --> 00:01:18,840 I've been with VM Ware for 12 years now. 17 00:01:18,920 --> 00:01:21,280 I came in through a startup that we sold to VM Ware. 18 00:01:21,800 --> 00:01:25,560 I was the first PM to bootstrap VSAN, which as you know is the 19 00:01:25,600 --> 00:01:27,920 flagship software defined storage offering from VMware. 20 00:01:28,800 --> 00:01:32,320 We grew VSAN together along with you from zero to a billion 21 00:01:32,320 --> 00:01:35,160 dollar product line and at one point it became the fastest 22 00:01:35,160 --> 00:01:38,960 growing product in VM Ware. These days I am driving new 23 00:01:38,960 --> 00:01:44,000 initiatives in VCF such as Storage for AI, Cyber Recovery 24 00:01:44,000 --> 00:01:47,320 and Database as a service. I think that's a nice one to 25 00:01:47,320 --> 00:01:49,440 have on your LinkedIn, right? I grew the business to a billion 26 00:01:49,440 --> 00:01:52,120 dollars. So yes, absolutely. 27 00:01:52,200 --> 00:01:55,200 I did a podcast with Pete Keeler not too long ago when we spoke 28 00:01:55,200 --> 00:01:58,160 about the 9.1 release and specifically of course about V 29 00:01:58,160 --> 00:02:01,200 San and were really cool features that were part of the 30 00:02:01,200 --> 00:02:03,280 launch. Now, besides Native S3, because 31 00:02:03,280 --> 00:02:05,840 I know you you are really excited about that one, what 32 00:02:05,840 --> 00:02:08,280 else excited you about the VCF 9.1 launch? 33 00:02:08,560 --> 00:02:12,400 Yeah, super question. So there are two things that 34 00:02:12,400 --> 00:02:16,800 excite me about VCF 9.1 from a storage and data standpoint. 1 35 00:02:16,800 --> 00:02:20,400 is we actually G8V send global deduplication, right. 36 00:02:20,400 --> 00:02:22,680 And I think I've mentioned this in other podcasts. 37 00:02:22,800 --> 00:02:26,840 It is truly global compared to an array or you know, we, we we 38 00:02:26,840 --> 00:02:31,200 have a much larger deduplication domain which results in very 39 00:02:31,200 --> 00:02:35,680 high PCO savings, right. So, so that is a significant 40 00:02:37,080 --> 00:02:39,720 capability that we have introduced especially in these 41 00:02:39,720 --> 00:02:43,960 times when you know there's so many hardware, there are 42 00:02:44,480 --> 00:02:47,680 hardware shortage and and the cost of hardware is so high, 43 00:02:47,840 --> 00:02:50,320 this is going to help our customers reduce their TCO 44 00:02:50,320 --> 00:02:53,200 significantly. So that's one and the other one 45 00:02:53,400 --> 00:02:58,360 is our flagship VCF cyber recovery feature, which we are 46 00:02:58,360 --> 00:03:03,360 launching basically providing an end to end fully automated 47 00:03:03,480 --> 00:03:08,160 workflow to recover from a cyber, a cyber attack or a 48 00:03:08,160 --> 00:03:12,240 ransomware attack with, you know, complete automation built 49 00:03:12,240 --> 00:03:14,560 in end to end. I know you've done several demos 50 00:03:14,560 --> 00:03:17,320 and you've spoken about this in many forums as well. 51 00:03:18,120 --> 00:03:20,880 To me, these are the two big capabilities I'm excited about 52 00:03:20,880 --> 00:03:23,720 with VCF 9.1. Yeah, and I actually had jotting 53 00:03:23,720 --> 00:03:25,760 on the podcast a few times to talk about this. 54 00:03:25,760 --> 00:03:28,440 And I've also just invited Velina to the show because she 55 00:03:28,440 --> 00:03:30,920 hasn't been on the show yet and I think she's a fantastic PM 56 00:03:30,920 --> 00:03:32,800 show. I'm getting her on to talk about 57 00:03:32,800 --> 00:03:35,440 the evolution of Dr. to ransomware recovery. 58 00:03:35,880 --> 00:03:38,120 Now today, of course, as I mentioned, we'll be going to be 59 00:03:38,120 --> 00:03:41,520 talking about the native S3 solution that we've just 60 00:03:41,520 --> 00:03:43,320 announced. But there's one question that I 61 00:03:43,320 --> 00:03:45,480 got to ask first, because this is a question that has been 62 00:03:45,480 --> 00:03:48,760 asked a lot the last couple of weeks because people are 63 00:03:48,760 --> 00:03:51,640 downloading 9.1 and they cannot find the S3 solution. 64 00:03:51,640 --> 00:03:54,640 So when can they expect it? When does it actually ship? 65 00:03:54,640 --> 00:03:56,080 Do you know and can you share it? 66 00:03:56,600 --> 00:03:59,840 Yes, I can share it. So you know, although 67 00:03:59,840 --> 00:04:03,160 technically native S 3 was launched as part of nine One, 68 00:04:03,560 --> 00:04:07,640 it'll be available in the product in nine dot 1.1, which 69 00:04:07,640 --> 00:04:12,800 is the 1st update release of Nine one plan for around August 70 00:04:12,800 --> 00:04:15,800 of this year. It's going to be a tech preview 71 00:04:15,800 --> 00:04:17,920 for non production workload workloads. 72 00:04:18,440 --> 00:04:21,440 We plan to tech preview. We have a bunch of design 73 00:04:21,839 --> 00:04:24,200 partner customers. We're going to tech preview this 74 00:04:24,400 --> 00:04:29,960 for three months and then we plan to G8 in 912, which is 3 75 00:04:29,960 --> 00:04:32,680 months after, likely in the November time frame. 76 00:04:33,200 --> 00:04:35,360 You got to add a caveat there because you never know, right? 77 00:04:35,360 --> 00:04:37,000 With these types of things, we know how it goes with 78 00:04:37,000 --> 00:04:38,600 engineering and. Absolutely, Yeah. 79 00:04:39,880 --> 00:04:42,640 This, this is all planned and no commitment here. 80 00:04:42,640 --> 00:04:44,920 This all planned, planned releases and timelines, Yeah. 81 00:04:44,960 --> 00:04:47,240 Yeah, I'll make sure to add a disclaimer to this particular 82 00:04:47,240 --> 00:04:50,000 episode just in case. Now, for those who are not 83 00:04:50,000 --> 00:04:52,840 familiar with S3 Object storage, and I'm guessing most people 84 00:04:52,840 --> 00:04:55,400 are, but for those not familiar with it, maybe you can briefly 85 00:04:55,400 --> 00:04:59,160 explain what it is before we go into the next bar, which is what 86 00:04:59,160 --> 00:05:01,240 we just brought to market or what we just announced. 87 00:05:01,240 --> 00:05:05,840 So what is S3 Object Storage? OK, so as you know, historically 88 00:05:05,840 --> 00:05:09,600 we SAN has supported block and file as the primary data data 89 00:05:09,600 --> 00:05:13,280 types for storage, right? So, but what we've seen is that 90 00:05:13,280 --> 00:05:16,880 with the advent of Kubernetes, you know, a lot of Kubernetes 91 00:05:16,880 --> 00:05:20,520 and dev OPS workloads landing on the private cloud and also a lot 92 00:05:20,520 --> 00:05:22,360 of AI workloads landing on the private cloud. 93 00:05:23,160 --> 00:05:28,920 These applications almost always need an S3 compatible interface 94 00:05:29,440 --> 00:05:32,480 for storage. So S3 object storage is nothing 95 00:05:32,480 --> 00:05:38,320 but you know, our native offering of V SAN in in the S3 96 00:05:38,320 --> 00:05:41,440 format compatible with Amazon S3. 97 00:05:41,640 --> 00:05:47,320 So now applications that require S3, they require the ability to 98 00:05:47,320 --> 00:05:50,880 store data, access the data through, you know traditional S3 99 00:05:50,880 --> 00:05:54,840 get input commands. We allow that, but but what it 100 00:05:54,840 --> 00:05:57,600 really is is it's a scale out storage offering. 101 00:05:57,600 --> 00:05:59,440 It's a scale out St. storage offering. 102 00:05:59,720 --> 00:06:04,280 It brings all the benefits of V SAN and all the benefits of the 103 00:06:04,280 --> 00:06:06,640 storage policy based management and things like that. 104 00:06:06,800 --> 00:06:09,720 So extending that from block in file to scale out object 105 00:06:09,720 --> 00:06:12,640 storage. Now, one of the things we always 106 00:06:12,640 --> 00:06:15,200 emphasize in the early days of V San was that it's not a 107 00:06:15,200 --> 00:06:18,600 distributed file system, but it's distributed storage. 108 00:06:18,640 --> 00:06:22,280 And to be more correct, it's distributed objects storage. 109 00:06:22,880 --> 00:06:26,680 You know, when I hear S3 object storage and I hear V SAN object 110 00:06:26,680 --> 00:06:29,440 storage, the question of course obviously that then arises is, 111 00:06:29,440 --> 00:06:31,520 is that the same thing? Will developers get direct 112 00:06:31,520 --> 00:06:33,600 access to V SAN or is it different? 113 00:06:34,240 --> 00:06:36,520 No, it's different. So yeah, I know, I know there's 114 00:06:36,520 --> 00:06:39,400 a bit of confusion with that word object. 115 00:06:39,560 --> 00:06:43,680 So see AV SAN object, right? Historically refers to the 116 00:06:43,680 --> 00:06:47,680 logical software defined unit of storage created by VMS, 117 00:06:47,680 --> 00:06:49,560 hyperconverged infrastructure, right? 118 00:06:49,720 --> 00:06:53,000 And historically it's primary function was a block storage at 119 00:06:53,000 --> 00:06:54,560 the hardware or hypervisor level. 120 00:06:54,880 --> 00:06:58,400 Each V SAN object is a collection of components like a 121 00:06:58,400 --> 00:07:02,440 VMDK, snapshots or namespaces designed specifically to run 122 00:07:02,720 --> 00:07:04,160 virtual machines and applications. 123 00:07:04,400 --> 00:07:08,160 That's what we send object to us right now when we talk about S3 124 00:07:08,160 --> 00:07:12,360 object or this native S3 object that we are launching that is 125 00:07:12,400 --> 00:07:15,400 nothing. But you know, strictly if you 126 00:07:15,400 --> 00:07:18,640 look at traditional objects, storage data is flattened into 127 00:07:18,640 --> 00:07:22,960 an unstructured pool where files in are and their accompanying 128 00:07:22,960 --> 00:07:26,560 metadata are assigned a unique flat identifier rather than 129 00:07:26,560 --> 00:07:28,760 being placed in a nested directory tree. 130 00:07:29,040 --> 00:07:32,360 So this is when we talk about we send native S3 object. 131 00:07:32,360 --> 00:07:37,240 This is completely different. It is the traditional S3 format 132 00:07:37,400 --> 00:07:41,240 that the industry is used to. It is an additional data type to 133 00:07:41,240 --> 00:07:45,680 block and file, and we'll shortly talk about all the use 134 00:07:45,680 --> 00:07:47,640 cases we plan to support. Yeah. 135 00:07:47,640 --> 00:07:51,640 So I guess it's, we're offering a different interface and yeah, 136 00:07:51,880 --> 00:07:53,760 I mean, I like the mechanism and I know there's a lot of 137 00:07:53,760 --> 00:07:55,640 customers excited about this. Now. 138 00:07:55,640 --> 00:07:58,360 I when I looked into it, one of the things that surprised me was 139 00:07:58,360 --> 00:08:00,080 the way you had to enable and configure it. 140 00:08:00,080 --> 00:08:02,400 It's not something that I expected, so you probably should 141 00:08:02,400 --> 00:08:04,680 be talking about that as well. So how do people configure 142 00:08:05,280 --> 00:08:07,360 native S3 object storage services? 143 00:08:07,360 --> 00:08:09,520 How does that actually work? Yeah. 144 00:08:09,760 --> 00:08:12,720 So see, first of all, we have to recognize as you know, you know, 145 00:08:12,720 --> 00:08:17,000 I've been trying to get objects storage prioritized in VM Ware 146 00:08:17,000 --> 00:08:20,120 for a long time, right? And we, we have been able to do 147 00:08:20,120 --> 00:08:24,160 that and deliver this primarily because the, because of the 148 00:08:24,160 --> 00:08:27,840 advent of new use cases such as dev OPS and AI, where the 149 00:08:27,840 --> 00:08:32,360 application developer needs access to programmatic storage, 150 00:08:32,360 --> 00:08:34,280 right? Without the need to go and file 151 00:08:34,280 --> 00:08:36,720 an IT ticket if they want to actually they want to be able to 152 00:08:36,720 --> 00:08:38,640 directly interact with the storage. 153 00:08:38,919 --> 00:08:44,159 So, so this is the context in which we are building it and 154 00:08:44,159 --> 00:08:48,240 it's very Kubernetes centric. Therefore, as you know, our 155 00:08:48,240 --> 00:08:53,440 flagship product for all of Kubernetes of automation is what 156 00:08:53,440 --> 00:08:58,360 we call VCFA or VCF automation. So we have all the workflows 157 00:08:58,360 --> 00:09:03,120 built into VCFA for a the provider admin or the 158 00:09:03,120 --> 00:09:06,200 infrastructure admin to set up the object storage service 159 00:09:06,400 --> 00:09:08,200 right? And then create supervisor with 160 00:09:08,200 --> 00:09:11,920 the VSAN cluster, assign zones and regions and things like 161 00:09:11,920 --> 00:09:14,120 that. Then we have a set of workflows 162 00:09:14,120 --> 00:09:17,440 for the tenant admin to provision that storage and 163 00:09:17,440 --> 00:09:19,800 manage users. So create an object store and 164 00:09:19,800 --> 00:09:23,120 add tenant user access to object store like other services. 165 00:09:23,760 --> 00:09:27,400 And three finally the the main user that we are targeting the 166 00:09:27,400 --> 00:09:31,320 app dev, they just come in once it's all done, they come in into 167 00:09:31,320 --> 00:09:33,440 their tenant org and they consume that object store. 168 00:09:33,440 --> 00:09:36,520 They create buckets, manage up buckets, objects and so on and 169 00:09:36,520 --> 00:09:40,280 so forth. So all of this is built into VCF 170 00:09:40,280 --> 00:09:44,480 automation natively and it takes advantage of all the 171 00:09:44,480 --> 00:09:47,280 self-service and multi tenant capabilities as well. 172 00:09:47,480 --> 00:09:50,040 So all of that is offered in VCF automation. 173 00:09:50,520 --> 00:09:53,680 It's something that came up during a meeting I had two weeks 174 00:09:53,680 --> 00:09:54,680 ago. It was probably the first 175 00:09:54,680 --> 00:09:56,600 question that they had. It's because they were all about 176 00:09:56,840 --> 00:09:58,760 multi tenancy. Now the interesting thing is 177 00:09:58,760 --> 00:10:01,360 that the next meeting that they had, the customer said, well, 178 00:10:01,920 --> 00:10:04,560 you know, VCFA looks nice, but I've got my own tools that I use 179 00:10:04,560 --> 00:10:07,040 for automation. So for those types of customers, 180 00:10:07,040 --> 00:10:10,000 will they also be able to, for instance, you know, configure it 181 00:10:10,000 --> 00:10:12,600 in a different way through the VC vsphere interface or how does 182 00:10:12,600 --> 00:10:14,280 that work? What are the options for them? 183 00:10:15,000 --> 00:10:18,760 Absolutely, yes, right. So we realized that, you know, 184 00:10:18,760 --> 00:10:23,320 VCF automation is something that we have just, you know, recently 185 00:10:23,320 --> 00:10:25,560 launched and we we realized customers have their own 186 00:10:25,560 --> 00:10:29,280 tooling, some of them may not be comfortable moving to VCF 187 00:10:29,280 --> 00:10:33,240 automation anytime now. So therefore, you know, going by 188 00:10:33,240 --> 00:10:39,440 our API first strategy, we've ensured that every piece of S3 189 00:10:39,440 --> 00:10:42,200 code is available through an API. 190 00:10:42,560 --> 00:10:45,400 So I talked about how the provider admin sets up the 191 00:10:45,400 --> 00:10:49,320 infrastructure. So we have APIs from VC, VC APIs 192 00:10:49,320 --> 00:10:53,240 that customers can use to set up the object store and then all 193 00:10:53,240 --> 00:10:57,120 the other activities like the tenant admin, you know, managing 194 00:10:57,120 --> 00:11:00,480 users and the users actually consuming the storage assigned 195 00:11:00,480 --> 00:11:02,120 to them in a multi tenant fashion. 196 00:11:02,280 --> 00:11:04,920 All of that can also be done through the APIs. 197 00:11:05,080 --> 00:11:08,560 So in fact, you know, you bring up a good point, I've talked to 198 00:11:08,560 --> 00:11:11,840 customers, 50% of the customers I've talked to have their own 199 00:11:11,840 --> 00:11:15,200 tooling and their own automation and they would just like to do 200 00:11:15,200 --> 00:11:18,720 this by consuming APIs. So we saw this well in advance 201 00:11:18,760 --> 00:11:22,280 and we made sure that this works for even customers who are not 202 00:11:22,280 --> 00:11:23,800 planning to adopt PCF automation. 203 00:11:24,400 --> 00:11:26,880 Yeah, it's it's interesting because I went through the 204 00:11:26,880 --> 00:11:30,240 exercise of configuring it and if I look at how you do it 205 00:11:30,240 --> 00:11:34,880 through the API or you do it through VCFAVCFA, feels much 206 00:11:34,880 --> 00:11:37,120 easier to me and especially the multi tenancy aspect. 207 00:11:37,120 --> 00:11:39,840 Is that your idea as well or how do you see that? 208 00:11:40,320 --> 00:11:42,600 Absolutely. Like if if you take the APIs in 209 00:11:42,600 --> 00:11:45,200 general right. If you look at the APIs and it's 210 00:11:45,200 --> 00:11:49,080 always more complicated to set up a multi tenant infrastructure 211 00:11:49,080 --> 00:11:51,960 with APIs and make sure that everything works fine and you 212 00:11:51,960 --> 00:11:55,000 put in all the guardrails correctly, even the self-service 213 00:11:55,000 --> 00:11:57,880 aspects, right. In many cases for many customers 214 00:11:58,040 --> 00:12:02,880 who are think about customers who are not as savvy on with 215 00:12:02,880 --> 00:12:06,280 containers and DevOps as you know, you know, many of these 216 00:12:06,280 --> 00:12:10,800 traditional VM customers moving to that, you know, they the, the 217 00:12:10,920 --> 00:12:15,360 automation that we provide with VCFA specifically around 218 00:12:15,360 --> 00:12:18,680 self-service and multi tenancy makes their life much easier. 219 00:12:19,720 --> 00:12:24,520 You know, rather than building all these automation through 220 00:12:24,520 --> 00:12:28,160 scripts and AP is now those who have AP is and scripts and 221 00:12:28,160 --> 00:12:31,760 they're very familiar with this. Yes, this might work, might be 222 00:12:31,760 --> 00:12:34,880 incremental, but strictly speaking I strongly believe that 223 00:12:34,880 --> 00:12:39,240 VCFA provides a lot of value and a lot of simplicity for things 224 00:12:39,240 --> 00:12:41,000 like self self-service and multi tenancy. 225 00:12:41,680 --> 00:12:44,320 And I think the multi tenancy aspect is really important. 226 00:12:44,720 --> 00:12:47,360 And one of the things that of course came up during the 227 00:12:47,360 --> 00:12:50,880 discussions I had with customers as well is that they've tried to 228 00:12:50,880 --> 00:12:52,800 use, for instance, Visa and file services. 229 00:12:52,800 --> 00:12:55,520 Because when I talk about the solution that we have, you bring 230 00:12:55,520 --> 00:12:58,440 up object storage, which is the block interface. 231 00:12:58,440 --> 00:13:01,080 And then of course, and we have a file interface as well. 232 00:13:01,080 --> 00:13:03,640 And of course immediately customers say, well, if I look 233 00:13:03,640 --> 00:13:07,160 at file services, I can't really do multi tenancy from a 234 00:13:07,160 --> 00:13:10,440 networking perspective. I only can enable it using a 235 00:13:10,440 --> 00:13:13,280 single authentication domain, I can only use a single DNS 236 00:13:13,280 --> 00:13:15,560 server, there are no namespaces, etcetera. 237 00:13:15,760 --> 00:13:18,800 So how is that ever going to work with native estuary object 238 00:13:18,800 --> 00:13:20,440 storage? So what would you say to them? 239 00:13:21,360 --> 00:13:22,960 Yeah, it's a great question, right. 240 00:13:22,960 --> 00:13:25,920 So first of all, before I answer this question, we have to 241 00:13:25,920 --> 00:13:30,160 understand where we came from historically, what was fees and 242 00:13:30,160 --> 00:13:33,800 file services meant to be right? It it was not, you know, in the 243 00:13:33,800 --> 00:13:36,120 initial days when we launched it and we sent files has been 244 00:13:36,120 --> 00:13:41,040 around for a while. It was not targeted for this 245 00:13:41,200 --> 00:13:44,360 these DevOps kind of use cases where, you know, multi tenancy 246 00:13:44,360 --> 00:13:47,840 becomes super critical, right? It was your traditional file 247 00:13:47,840 --> 00:13:50,680 shares and things like that. So yes, it had limitations 248 00:13:50,680 --> 00:13:52,960 around networking, authentication, you know, 249 00:13:52,960 --> 00:13:55,960 configuring those things and stuff because the goal was never 250 00:13:55,960 --> 00:13:59,280 to provide direct access to the developer. 251 00:13:59,600 --> 00:14:03,040 OK. So in some sense when we looked 252 00:14:03,040 --> 00:14:06,760 at native S3, which is all as I said focused around the 253 00:14:06,760 --> 00:14:11,040 developer, the networking in S3 for example is VPC based, right, 254 00:14:11,040 --> 00:14:14,360 which is required to enable multi tenancy with object, you 255 00:14:14,360 --> 00:14:17,080 get bucket level isolation so that even if the object stores 256 00:14:17,080 --> 00:14:20,160 are stored within AVPC, they're completely secure and isolated, 257 00:14:20,160 --> 00:14:22,040 right? Coke will not know about Pepsi, 258 00:14:22,160 --> 00:14:25,200 HR will not know about finance. So we built all that into native 259 00:14:25,200 --> 00:14:28,320 S3. So now what we're doing is we 260 00:14:28,320 --> 00:14:33,400 are also planning to introduce file services as a first, as a, 261 00:14:33,920 --> 00:14:42,040 as a first class citizen in, in VCFA and provided the same level 262 00:14:42,040 --> 00:14:44,880 of multi tenant capabilities, simplifying all of that 263 00:14:44,880 --> 00:14:47,760 networking and everything as we are doing for native S3. 264 00:14:48,000 --> 00:14:52,240 So, so to to answer your question, the limitations, 265 00:14:52,240 --> 00:14:55,480 current limitations of VSAN file services does not apply to S3 266 00:14:55,840 --> 00:14:59,200 because you know, it's fully, we provide full self-service multi 267 00:14:59,200 --> 00:15:03,240 tenancy through VCFA and we take it a step further, even file 268 00:15:03,240 --> 00:15:06,680 services, we are providing the same level of isolation and 269 00:15:07,120 --> 00:15:10,040 multi tenancy and things like that in VCFA. 270 00:15:10,160 --> 00:15:13,480 So we're actually improving VSAN file services to address the 271 00:15:13,480 --> 00:15:16,360 same use case because there are several applications in this dev 272 00:15:16,360 --> 00:15:19,360 OPS space which require file and not object. 273 00:15:19,360 --> 00:15:23,080 So we need to bring both file and object to the same level in 274 00:15:23,080 --> 00:15:26,520 terms of capabilities and in terms of simplicity of usage 275 00:15:26,520 --> 00:15:29,200 with VCFA. Yeah, I think that's fantastic. 276 00:15:29,200 --> 00:15:32,000 I'm pretty sure that the customers and partners that I 277 00:15:32,000 --> 00:15:34,240 spoke with, because as you can imagine, some of those are the 278 00:15:34,480 --> 00:15:37,440 cloud partners as well, will be very interested in having a 279 00:15:37,440 --> 00:15:40,120 solution like that. Now one other thing that I 280 00:15:40,120 --> 00:15:43,720 noticed, which was also interesting is when I set it up, 281 00:15:43,720 --> 00:15:47,120 I actually had the ability to create one or multiple S3 282 00:15:47,120 --> 00:15:49,480 instances. And then within those instances, 283 00:15:49,480 --> 00:15:51,480 I could have one or multiple buckets. 284 00:15:52,000 --> 00:15:54,840 Now at first when I saw that, I wasn't really sure what that was 285 00:15:54,840 --> 00:15:56,840 for. And I think I'm, I'm guessing 286 00:15:56,840 --> 00:16:00,440 that the listeners will also kind of get confused when they 287 00:16:00,440 --> 00:16:02,920 go through that effort. So maybe you can explain why you 288 00:16:02,920 --> 00:16:06,120 would have multiple instances versus just one instance. 289 00:16:06,120 --> 00:16:09,040 Because to me, when I work for an enterprise, I would probably 290 00:16:09,040 --> 00:16:11,160 just create 1 instance and a whole bunch of buckets and 291 00:16:11,160 --> 00:16:14,480 assign access to it. So why did we introduce that 292 00:16:14,480 --> 00:16:17,280 capability? Yeah, great question. 293 00:16:17,440 --> 00:16:20,600 See the use case is essentially to provide a less level of 294 00:16:20,600 --> 00:16:23,120 isolation required for multiple tenants. 295 00:16:23,440 --> 00:16:26,280 So you know, there is a concept of tenant even within the 296 00:16:26,280 --> 00:16:29,520 private cloud, even within large and enterprises, there's a 297 00:16:29,520 --> 00:16:33,360 concept of you know, engineering can be a tenant, HR marketing, 298 00:16:33,400 --> 00:16:35,120 so on. And so there's an organization. 299 00:16:35,400 --> 00:16:39,480 So we support multiple S3 instances within an object store 300 00:16:39,480 --> 00:16:43,960 service, OK, each instance represents a single tenant or an 301 00:16:43,960 --> 00:16:47,320 independent organization. Now within each org you can have 302 00:16:47,320 --> 00:16:49,840 multiple projects. Like I said, engineering, HR, 303 00:16:49,840 --> 00:16:53,520 marketing, each project can have multiple buckets and then the 304 00:16:53,520 --> 00:16:57,160 set of users assigned within that tenant org can access one 305 00:16:57,280 --> 00:17:00,240 or multiple buckets based on their access control privileges. 306 00:17:00,520 --> 00:17:04,240 So it's really the multiple instances is to be able to 307 00:17:04,240 --> 00:17:07,040 provide a level of isolation required at a tenant level. 308 00:17:07,480 --> 00:17:09,560 Yeah. I think that's going to be very 309 00:17:09,560 --> 00:17:11,960 useful and I think it's going to be very appreciated, especially 310 00:17:11,960 --> 00:17:15,160 by the cloud providers because it adds an additional level of 311 00:17:15,160 --> 00:17:17,839 security or layer of security. Now the other thing of course 312 00:17:17,839 --> 00:17:21,040 that is also asked fairly frequently is when it comes to 313 00:17:21,040 --> 00:17:22,920 the S3 object storage implementation. 314 00:17:23,240 --> 00:17:26,160 Most people of course immediately make a comparison to 315 00:17:26,160 --> 00:17:29,560 AWS because they created it. But of course there's many 316 00:17:29,560 --> 00:17:32,080 different implementations out there, at least different 317 00:17:32,080 --> 00:17:33,920 solutions out there. Now, when it comes to our 318 00:17:33,920 --> 00:17:37,400 specific implementation, will we offer all the functionality that 319 00:17:37,640 --> 00:17:40,040 AWS offers from day one? What will that look like? 320 00:17:40,720 --> 00:17:44,080 Yeah. You know, so this conversation 321 00:17:44,080 --> 00:17:48,240 can get a little misleading. If I talk about how many APIs of 322 00:17:49,160 --> 00:17:52,640 S3 do I support, that is less relevant. 323 00:17:52,800 --> 00:17:55,560 I would like to talk about this in terms of the functionality. 324 00:17:55,560 --> 00:17:59,000 So we support all the at MBP, we support all the CRUD 325 00:17:59,040 --> 00:18:02,160 functionality which is create, read, update, delete, 326 00:18:02,760 --> 00:18:05,080 authentication, access controls, etcetera. 327 00:18:05,480 --> 00:18:09,400 We even support some advanced S3 capabilities such as multi part 328 00:18:09,880 --> 00:18:12,200 which is for large object optimization. 329 00:18:12,640 --> 00:18:14,760 You know when you have really large objects, how do you 330 00:18:14,760 --> 00:18:17,200 transfer them across the pipe in an efficient manner. 331 00:18:17,760 --> 00:18:20,520 You know, we support things like sync to and sync from which you 332 00:18:20,520 --> 00:18:25,560 can use to copy or replicate the data across across sites. 333 00:18:25,560 --> 00:18:30,520 Even so, the, the initial set of capabilities in terms of the 334 00:18:30,520 --> 00:18:37,360 APIs that we support for S3 is supports all those foundational 335 00:18:37,360 --> 00:18:41,520 use cases that required crowd authentication, access control, 336 00:18:41,520 --> 00:18:44,280 multipath, moving the data from one place to the other. 337 00:18:44,480 --> 00:18:47,760 So, so that that's what that's what the focus was to provide a 338 00:18:47,760 --> 00:18:52,920 fully functional S3 object store interface that addresses all 339 00:18:52,920 --> 00:18:56,720 these use cases which are critical for DevOps as well As 340 00:18:56,720 --> 00:19:00,720 for AI. OK, now in the future we have 341 00:19:00,920 --> 00:19:05,120 plans to extend this implementation to things like S3 342 00:19:05,120 --> 00:19:10,560 select, which is a more optimized way of, you know, 343 00:19:10,560 --> 00:19:13,280 finding the data that you need and transferring, reduce the 344 00:19:13,280 --> 00:19:17,360 amount of transfer on the pipe, object versioning, object lock, 345 00:19:17,360 --> 00:19:19,960 life cycle policies. Those will come in the next 346 00:19:19,960 --> 00:19:24,760 release, but I think the the the the capabilities that I referred 347 00:19:24,760 --> 00:19:28,880 to on MVP should be more than good enough for all customers to 348 00:19:28,880 --> 00:19:31,200 start off with our object storage solution. 349 00:19:31,760 --> 00:19:33,120 Yeah. And I guess as you mentioned, 350 00:19:33,120 --> 00:19:36,720 the first release is a MVP order or even the tech preview in the 351 00:19:36,720 --> 00:19:40,160 next one is an MVP. So it'll make sense to expand on 352 00:19:40,160 --> 00:19:42,600 that. Now we're looking at thinking 353 00:19:42,600 --> 00:19:44,840 about those customers. What are the use cases that you 354 00:19:44,840 --> 00:19:48,080 have in mind when it comes to these, you know, first couple of 355 00:19:48,080 --> 00:19:50,040 releases? What are you thinking about? 356 00:19:50,600 --> 00:19:53,080 Yeah. So you know, I look at it from 357 00:19:53,080 --> 00:19:57,560 2, two different perspectives. And one is I look at the use 358 00:19:57,560 --> 00:20:01,120 cases, as you know, from an infrastructure standpoint, what 359 00:20:01,120 --> 00:20:03,440 are the, you know, what are, what infrastructure are we 360 00:20:03,440 --> 00:20:05,800 providing? And then there's the application 361 00:20:05,800 --> 00:20:08,160 centric use cases. So from an infrastructure 362 00:20:08,160 --> 00:20:12,200 standpoint, you know, the main, one of the main use cases, as I 363 00:20:12,200 --> 00:20:15,480 mentioned already is primary storage for dev OPS. 364 00:20:15,600 --> 00:20:16,720 That's one. OK. 365 00:20:17,040 --> 00:20:19,480 And then I'll talk about this a little bit more in detail. 366 00:20:20,560 --> 00:20:24,920 The second big use case is S3 for AI, right, training, 367 00:20:24,920 --> 00:20:27,800 inferencing and analytics. So that's the second use case. 368 00:20:28,000 --> 00:20:31,000 And the third is S3 as a secondary storage where it's a 369 00:20:31,000 --> 00:20:34,040 cyber vault or an archive or something like that, right. 370 00:20:34,360 --> 00:20:36,000 So that's the infrastructure pieces. 371 00:20:36,000 --> 00:20:39,360 Those are three use cases. Then on the application centric 372 00:20:39,360 --> 00:20:42,600 use cases, we have many customers who want S3 object for 373 00:20:42,760 --> 00:20:46,120 a CICD pipeline, right? We support service accounts 374 00:20:46,120 --> 00:20:49,160 which can be pre created and fed into the CICD pipeline with 375 00:20:49,160 --> 00:20:51,800 tools like Jenkins. And so that's fully automated. 376 00:20:51,920 --> 00:20:55,360 So we support that, right? And S3 can be a artifact 377 00:20:55,360 --> 00:20:57,360 repository for that CICD pipeline. 378 00:20:57,360 --> 00:21:00,040 That's one. And the second is like a backup 379 00:21:00,040 --> 00:21:02,800 repository for Kubernetes applications where you can 380 00:21:03,000 --> 00:21:06,000 backup the entire Kubernetes cluster or selected 381 00:21:06,000 --> 00:21:09,480 applications, namespaces, labels, resources and so on and 382 00:21:09,480 --> 00:21:10,760 so forth. So those are some of the 383 00:21:10,760 --> 00:21:14,000 application centric use cases that we are targeting with MVP. 384 00:21:14,480 --> 00:21:18,200 About knowing you and I know the way that your brain works, so 385 00:21:18,200 --> 00:21:19,920 I'm pretty sure that this is correct. 386 00:21:20,280 --> 00:21:24,120 You probably already have ideas in terms of how the platform can 387 00:21:24,120 --> 00:21:27,640 evolve and what are the use case we can potentially support in 388 00:21:27,640 --> 00:21:29,480 the future. And there could be 12 or 18 389 00:21:29,480 --> 00:21:30,640 months out, even longer than that. 390 00:21:30,640 --> 00:21:33,200 So what are your ideas around those, if you can share? 391 00:21:33,200 --> 00:21:34,840 Because I know not everything can be shared. 392 00:21:34,840 --> 00:21:37,360 So maybe, you know, you can give a hint of what you're thinking 393 00:21:37,360 --> 00:21:39,440 about for the future. Absolutely. 394 00:21:39,440 --> 00:21:42,920 See, here's the thing, right, Ideas are always a function of 395 00:21:43,160 --> 00:21:46,320 some customer actually trying out something that we didn't 396 00:21:46,320 --> 00:21:49,360 expect them to try out. If you remember, Duncan, in the 397 00:21:49,360 --> 00:21:53,520 initial days of VSAN, right, 12 years back, we advertised VSAN 398 00:21:53,520 --> 00:21:57,360 as a Tier 2 storage, you know, don't put Tier 1 workloads and 399 00:21:57,360 --> 00:21:58,920 stuff. And we had hundreds of 400 00:21:58,920 --> 00:22:00,560 customers. They ended up putting Tier 1 401 00:22:00,560 --> 00:22:04,760 workloads anyways, and they said, hey, look, vsan supports 402 00:22:04,760 --> 00:22:06,320 all this already. And then we just went and 403 00:22:06,320 --> 00:22:08,400 claimed support, right? So we learn new things from 404 00:22:08,400 --> 00:22:10,520 customers. So I was very, very, very 405 00:22:10,520 --> 00:22:14,680 surprised when I found out because, you know, now with VCF, 406 00:22:14,680 --> 00:22:17,120 we offer one terabyte per core of VSAN. 407 00:22:17,120 --> 00:22:20,040 That's a lot of vsan, right? So with 100,000 cores, that's 408 00:22:20,040 --> 00:22:22,760 100 petabytes. So customers got creative, 409 00:22:23,160 --> 00:22:26,360 right? And they already started using 410 00:22:26,360 --> 00:22:29,840 vsan for AI use cases. OK. 411 00:22:30,000 --> 00:22:34,880 So right now they're using the vsan file service like a read 412 00:22:34,880 --> 00:22:38,920 write many volume. So 1 is that they're using vsan 413 00:22:39,240 --> 00:22:42,560 for VLLM, right? A model store that you want to 414 00:22:42,560 --> 00:22:46,280 store their models which can be loaded to run all the agentic 415 00:22:46,280 --> 00:22:49,160 workflows, right? They, they, they do that with 416 00:22:49,160 --> 00:22:51,440 files and customers came back and said, you know what, I'd 417 00:22:51,440 --> 00:22:53,680 like to do the same thing with object, right? 418 00:22:54,000 --> 00:22:58,320 And then, you know, they use files for an unstructured 419 00:22:58,320 --> 00:23:00,560 database for RAG for RAG workflows. 420 00:23:00,840 --> 00:23:05,280 Again, they feel that S3 object is better suited for the 421 00:23:05,280 --> 00:23:07,760 unstructured database. So customers are asking me for 422 00:23:07,760 --> 00:23:10,360 that. And then, you know, we have a 423 00:23:10,360 --> 00:23:13,920 big partnership with our data Tanzu data intelligence team 424 00:23:14,760 --> 00:23:18,240 where green plum runs on top of V San and it does time based 425 00:23:18,240 --> 00:23:20,920 tearing. OK, so by that what I mean is 426 00:23:20,920 --> 00:23:25,640 that any data that is less than one year old, you know, hot data 427 00:23:25,800 --> 00:23:29,000 that lands on that can land on V San block, right, with high 428 00:23:29,000 --> 00:23:31,840 performance storage. And then you know, they they 429 00:23:31,880 --> 00:23:35,560 automatically tear that data, you know, 1 to 9 years, it gets 430 00:23:35,560 --> 00:23:38,440 teared to an S3 storage, right with QLC. 431 00:23:38,680 --> 00:23:42,600 Now guess what, now we have S3 support now we support QLC. 432 00:23:42,720 --> 00:23:46,240 So this becomes up a very fundamental use case, right? 433 00:23:46,360 --> 00:23:49,120 So these are three things, three use cases, the unstructured 434 00:23:49,120 --> 00:23:52,840 database for RAG, the model store and the time based tearing 435 00:23:52,840 --> 00:23:55,520 with green Plum that I just learned from customers that 436 00:23:55,960 --> 00:23:58,520 they're either they're already using some for sort of we sent 437 00:23:58,520 --> 00:24:00,920 for that or they're considering our object storage for that, 438 00:24:01,120 --> 00:24:02,640 right. So these are like in the near 439 00:24:02,640 --> 00:24:07,080 term, as soon as our S 3 is out, I expect us to support all three 440 00:24:07,080 --> 00:24:09,200 use cases right now. OK. 441 00:24:09,600 --> 00:24:14,400 Now in terms of road map, in terms of more advanced use cases 442 00:24:14,640 --> 00:24:18,480 on VSAN object store in the future, we are working on a 443 00:24:18,480 --> 00:24:22,440 number of things, right, like MCP readiness, which is model 444 00:24:22,440 --> 00:24:25,400 context protocol. It enables AI agents and LLMS to 445 00:24:25,400 --> 00:24:28,800 natively access VSAN buckets as context sources. 446 00:24:28,800 --> 00:24:30,160 You don't need a custom middleware. 447 00:24:30,400 --> 00:24:34,600 So that's one semantic tagging. We are natural language 448 00:24:34,600 --> 00:24:37,680 processing, you know it automatically we go and classify 449 00:24:37,680 --> 00:24:41,160 and tag objects at ingest. And so this enables semantic 450 00:24:41,160 --> 00:24:43,080 search and intelligent data governance. 451 00:24:43,600 --> 00:24:46,040 You know, combined with tons of data intelligence, this is going 452 00:24:46,040 --> 00:24:48,760 to be even more kick ass right when we bring this technology 453 00:24:48,760 --> 00:24:50,760 together. Then other things like, you 454 00:24:50,760 --> 00:24:53,600 know, integrating with vector DB, you know, packaging a native 455 00:24:53,600 --> 00:24:57,840 vector DB with V SAN object store, you know, I talked about 456 00:24:57,840 --> 00:25:01,680 S3 select earlier, which is like a more efficient way to reduce 457 00:25:01,680 --> 00:25:03,760 the data transfer for green plum queries. 458 00:25:04,880 --> 00:25:08,640 You know, as the scale of S3 increases, we will start looking 459 00:25:08,640 --> 00:25:13,160 at things like S3 over RDMA because RDMA transport for S3 IO 460 00:25:13,360 --> 00:25:16,320 eliminates CPU bottlenecks on high throughput AI training 461 00:25:16,320 --> 00:25:19,000 workloads, you know, so that's something that we're looking for 462 00:25:19,000 --> 00:25:21,920 in the future. And then, you know, GPU direct 463 00:25:21,920 --> 00:25:26,400 storage, right, enabling direct GPU to S3 storage, direct DMA 464 00:25:26,400 --> 00:25:30,280 paths, bypassing CPU RAM for AI model loading and checkpointing 465 00:25:30,280 --> 00:25:32,200 at scale. So those are like some of the 466 00:25:32,800 --> 00:25:34,840 real forward-looking things that we are working on. 467 00:25:34,840 --> 00:25:38,840 Super excited as you can see that the entire team is now 468 00:25:38,840 --> 00:25:44,080 focused on delivering all this AI innovation road map for V SAN 469 00:25:44,080 --> 00:25:47,480 object storage going forward. Yeah, I'm already excited about 470 00:25:47,480 --> 00:25:49,840 the the session that we're going to be delivering at Explore 471 00:25:49,840 --> 00:25:53,280 hopefully because I know we're going to reveal a lot of the the 472 00:25:53,280 --> 00:25:55,320 future functionality that you're now working on. 473 00:25:55,320 --> 00:25:58,960 Now, before I let you go, Rakesh, any famous last words or 474 00:25:58,960 --> 00:26:01,120 any final thoughts we'd like to share with the audience? 475 00:26:01,760 --> 00:26:08,400 Yeah, you know, it's, it's funny, my the PM on my team who 476 00:26:08,400 --> 00:26:13,440 is actually developing A3 object store, he actually has he 477 00:26:13,440 --> 00:26:16,960 carries buckets with him into a car wash. 478 00:26:17,200 --> 00:26:20,720 Okay. And his bucket recently went 479 00:26:20,720 --> 00:26:22,960 missing. Okay, so he was stuck in the car 480 00:26:22,960 --> 00:26:27,560 wash he had No, it's one of those car washes do your own car 481 00:26:27,560 --> 00:26:30,320 wash kind of a thing. And he had nothing to actually 482 00:26:33,640 --> 00:26:36,440 clean his car. But it turns out that in his 483 00:26:36,440 --> 00:26:40,520 boot he had another bucket, OK, which is his wife had left that 484 00:26:40,520 --> 00:26:42,120 in the boot. So he took that and he was able 485 00:26:42,120 --> 00:26:43,600 to clean his car. All right. 486 00:26:43,760 --> 00:26:48,200 So I so I joked with him that look, you need replication, you 487 00:26:48,200 --> 00:26:51,800 need, you need 2 copies, you need multiple sites. 488 00:26:51,800 --> 00:26:54,480 So you were lucky that you had another S like, you know, 489 00:26:54,480 --> 00:26:57,560 analogous to an S3 bucket. You had another bucket there. 490 00:26:57,800 --> 00:27:02,840 And so, you know, at that point we said, you know, S3 to S3 491 00:27:02,840 --> 00:27:06,040 replication is a super critical feature because how do you 492 00:27:06,040 --> 00:27:08,720 really protect your S3? How do you really, you know, 493 00:27:08,720 --> 00:27:12,040 there's no real way to backup S3 or protect it unless you provide 494 00:27:12,040 --> 00:27:15,040 a replication? So I love this S3 bucket analogy 495 00:27:15,040 --> 00:27:16,600 and it happened with my S 3:00 PM. 496 00:27:16,840 --> 00:27:20,560 And so, so yeah, that's a big thing I wanted to mention is 497 00:27:20,560 --> 00:27:23,840 that we will be providing native replication with S3 in the 498 00:27:23,840 --> 00:27:26,280 product also in the coming in, in the near future. 499 00:27:27,040 --> 00:27:28,680 Fantastic. Thank you very much, Prakash. 500 00:27:28,840 --> 00:27:31,280 Awesome, thank you Duncan. Hope this is useful. 501 00:27:31,320 --> 00:27:34,920 I look forward to having more conversations with you on other 502 00:27:34,920 --> 00:27:36,600 topics in the future. And that's it. 503 00:27:36,760 --> 00:27:39,120 Thanks for tuning in to the Unexplored Territory podcast. 504 00:27:39,320 --> 00:27:41,680 If you enjoyed this episode, don't forget to subscribe and 505 00:27:41,680 --> 00:27:43,280 leave a reviewer rating wherever possible. 506 00:27:43,280 --> 00:27:45,960 And please join us again next time as we cover more insights 507 00:27:45,960 --> 00:27:48,040 into cutting edge solutions shaping the world of IT. 508 00:27:48,520 --> 00:27:50,960 Until then, staying comfortable, keep exploring.