1 00:00:33,680 --> 00:00:39,760 The Welcome to the Other 4 Turtle broadcast. 2 00:00:39,960 --> 00:00:42,520 Have you ever found yourself confused about what a VCF 8 3 00:00:42,600 --> 00:00:45,320 instance or domain is? Well, I invited Gary Blake to 4 00:00:45,320 --> 00:00:47,920 the show to explain all of it. Hey, welcome to the show. 5 00:00:47,920 --> 00:00:50,240 Gary, how you looking? Hey, for those who don't know 6 00:00:50,240 --> 00:00:52,360 who you are, maybe you can explain what it is that you do 7 00:00:52,360 --> 00:00:55,360 for Broadcom slash Vienna. And maybe you can also include a 8 00:00:55,360 --> 00:00:58,200 highlight of your career because you've been at the company for a 9 00:00:58,200 --> 00:01:00,040 while now. So I'm interested to hear about 10 00:01:00,040 --> 00:01:02,000 that as well. Yeah, yeah, absolutely. 11 00:01:02,000 --> 00:01:04,720 Yeah. So, yeah, I've been in 15 years 12 00:01:04,720 --> 00:01:06,880 this year almost as long as you, right. 13 00:01:07,880 --> 00:01:12,480 So I guess in terms of my role, it really falls into a couple of 14 00:01:12,480 --> 00:01:15,880 areas. So primarily, you know, our team 15 00:01:15,920 --> 00:01:18,480 is focused on the architecture for VCF. 16 00:01:18,480 --> 00:01:21,360 So the a key deliverable is the design guide. 17 00:01:21,360 --> 00:01:24,400 So in the product documentation alongside, you know, the usual 18 00:01:24,400 --> 00:01:27,640 procedures and those kind of things, we have an architectural 19 00:01:27,640 --> 00:01:31,720 design where we lay out all of the options within the VCF 20 00:01:31,720 --> 00:01:33,960 platform. Obviously we'll talk about more 21 00:01:33,960 --> 00:01:38,760 about that later. And the second part of our role 22 00:01:38,760 --> 00:01:43,280 is really, I guess it's evangelism, but not evangelism 23 00:01:43,280 --> 00:01:46,760 in the same way that you do it. It's more of, you know, we get 24 00:01:46,760 --> 00:01:50,200 called into customer engagements, customer accounts, 25 00:01:50,200 --> 00:01:53,240 problem accounts, maybe someone's hit an issue, try to 26 00:01:53,240 --> 00:01:56,960 help resolving those problems. And as we move forward under the 27 00:01:56,960 --> 00:01:59,520 Broadcom world, we'll now be involved more with partners. 28 00:01:59,520 --> 00:02:02,200 So actually helping partners understand because there's a lot 29 00:02:02,200 --> 00:02:04,680 of change that's gone on within the organization, as you well 30 00:02:04,680 --> 00:02:07,440 know. And so, you know, we're, we're 31 00:02:07,440 --> 00:02:10,440 close to engineering, we're close to the product management 32 00:02:10,440 --> 00:02:11,960 teams. So, you know, we have good 33 00:02:11,960 --> 00:02:16,880 insight into the futures. So, yeah, we focus a lot on, on 34 00:02:16,880 --> 00:02:20,600 those core things and I guess from a highlight career 35 00:02:20,600 --> 00:02:24,240 highlight, you know, for me, the, the biggest aspect or 36 00:02:24,240 --> 00:02:26,920 biggest part of my career has probably been involved in the VM 37 00:02:26,920 --> 00:02:31,120 Ware validated designs. I think most people, you know, I 38 00:02:31,120 --> 00:02:34,520 ask in sessions, you know, anyone heard of the VVDS and 39 00:02:34,520 --> 00:02:37,480 nine times out of 10, at least 50% of the audience puts their 40 00:02:37,480 --> 00:02:39,040 hands up. So it's something that we 41 00:02:39,040 --> 00:02:45,480 produced as an organization what 10 years ago now, which really 42 00:02:45,800 --> 00:02:47,640 struck A chord with our with our customers. 43 00:02:47,640 --> 00:02:52,360 You know, we had a bunch of products that were very, you 44 00:02:52,360 --> 00:02:56,600 know, integrated, but not integrated well as you as you 45 00:02:56,600 --> 00:03:00,240 know. And what's interesting for me is 46 00:03:00,240 --> 00:03:03,040 seeing that evolution of where we are now as an organisations 47 00:03:03,040 --> 00:03:06,560 where we had sort of these 1015 things that we're now really 48 00:03:06,560 --> 00:03:09,560 trying to push with VM Ware Cloud Foundation as a as a 49 00:03:09,560 --> 00:03:11,640 single platform. So, yeah. 50 00:03:11,760 --> 00:03:15,040 And I guess the the big part of that was helping professional 51 00:03:15,040 --> 00:03:18,400 services teams in terms of building the service offering 52 00:03:18,400 --> 00:03:22,360 around VVD back in the day. So I kind of pioneered the the 53 00:03:22,360 --> 00:03:26,000 service offering before them being pulled in to what was the 54 00:03:26,000 --> 00:03:28,160 validated design team. Yeah. 55 00:03:28,160 --> 00:03:31,640 I think the VVDS were, well very important for customers, not 56 00:03:31,640 --> 00:03:35,000 just for customers, but also for folks internally because I think 57 00:03:35,000 --> 00:03:37,960 a lot of people were challenged with the adoption of all of the 58 00:03:37,960 --> 00:03:41,800 different components and creating a single clout out of 59 00:03:41,800 --> 00:03:43,760 it. So I think it's, yeah, exactly. 60 00:03:43,800 --> 00:03:46,760 I mean, you know, if we kind of go back 10 years, we had so many 61 00:03:46,760 --> 00:03:49,480 moving parts, so many different things, so many different ways 62 00:03:49,480 --> 00:03:53,640 of doing stuff that, you know, we really need to have some kind 63 00:03:53,640 --> 00:03:57,480 of blueprint glue that that brought it together. 64 00:03:57,480 --> 00:03:58,800 And, and I think you're absolutely right. 65 00:03:58,800 --> 00:04:00,680 I think there were a lot of teams internally within the 66 00:04:00,680 --> 00:04:05,520 organization started to realise how complex what we had as a 67 00:04:05,520 --> 00:04:10,400 portfolio really was becoming. So yeah, it was it was a state 68 00:04:10,440 --> 00:04:13,280 for for a long time until VCF came along, Yeah. 69 00:04:14,120 --> 00:04:15,760 I don't think that's still the case, to be honest. 70 00:04:15,760 --> 00:04:18,600 If if you look at VCF, it's still relatively complex. 71 00:04:18,600 --> 00:04:20,240 There are many different constructs involved. 72 00:04:20,240 --> 00:04:22,840 And that's actually going to be the topic of today, because I 73 00:04:22,840 --> 00:04:25,960 was talking to a bunch of people at the V Mag and they all 74 00:04:25,960 --> 00:04:28,840 mentioned that your session was probably one of the favourite 75 00:04:28,840 --> 00:04:31,640 sessions, sessions at the V Mag Connect event, which was 76 00:04:31,640 --> 00:04:34,360 fantastic to hear. And when I started looking at 77 00:04:34,360 --> 00:04:36,400 the content, and of course, I had seen some of the content 78 00:04:36,400 --> 00:04:39,000 already floating around and I've seen some of your sessions in 79 00:04:39,000 --> 00:04:41,360 the in the past, I figured it would be good to get you on the 80 00:04:41,360 --> 00:04:43,160 show to actually talk through some of that content. 81 00:04:43,160 --> 00:04:46,000 Because even for myself, and I've been involved in VM 82 00:04:46,000 --> 00:04:48,280 technology for the longest time, sometimes it's, it's still 83 00:04:48,280 --> 00:04:50,400 rather complex, especially when it comes to VCF. 84 00:04:50,880 --> 00:04:55,560 But before we dive into those specific constructs itself, it's 85 00:04:55,560 --> 00:04:58,520 also probably good to explain from, you know, the highest 86 00:04:58,520 --> 00:05:01,320 level what we really talk about when we talk about the VCF 87 00:05:01,320 --> 00:05:04,560 private cloud. Because even even to me, that's 88 00:05:04,560 --> 00:05:07,840 not always exactly clear what it what is it that that actually 89 00:05:07,840 --> 00:05:10,360 means to you, but also what should it mean for a customer? 90 00:05:10,360 --> 00:05:12,960 Yeah. And you know, I think I've 91 00:05:12,960 --> 00:05:15,400 personally struggled with the concept of a, of a private, you 92 00:05:15,400 --> 00:05:17,960 know, VCF private cloud. You know, we, we call it out as 93 00:05:17,960 --> 00:05:23,440 part of the taxonomy for VCF. And for me, it's not really a 94 00:05:23,440 --> 00:05:25,560 construct, it's more of a concept. 95 00:05:25,920 --> 00:05:29,960 So you know, as you know, you know, Broadcom's very focused 96 00:05:29,960 --> 00:05:33,280 now on private cloud. So you know, we're not really in 97 00:05:33,280 --> 00:05:38,200 the hyperscaler market now private cloud simply to me means 98 00:05:38,320 --> 00:05:40,120 it's private to that organization. 99 00:05:40,120 --> 00:05:42,640 So it's not shared with a another organization. 100 00:05:42,840 --> 00:05:46,760 So you know, a private cloud could be on Prem, it could be, 101 00:05:46,880 --> 00:05:49,400 you know, Co located, it could be a managed service. 102 00:05:49,400 --> 00:05:53,000 But the key thing is it's the dedicated, but the key thing is 103 00:05:53,000 --> 00:05:56,960 it's, it's trying to drive more of an operational model from a 104 00:05:56,960 --> 00:06:01,320 private cloud agile perspective. And that's kind of how I see it 105 00:06:01,320 --> 00:06:04,760 from from where we, you know, we're trying to drive VCF as a 106 00:06:04,760 --> 00:06:06,560 platform. Yeah, I think the operational 107 00:06:06,560 --> 00:06:11,160 model is a important aspect. Now, of course, besides the 108 00:06:11,160 --> 00:06:15,480 operational model, when we talk about VCF, there are also many 109 00:06:15,480 --> 00:06:17,200 different constructs that come into play. 110 00:06:17,600 --> 00:06:21,200 And I struggled with that a lot, especially when those new 111 00:06:21,200 --> 00:06:24,440 constructs started popping up, you know, something like a 112 00:06:24,440 --> 00:06:27,760 fleet, for instance. It wasn't something that existed 113 00:06:28,360 --> 00:06:30,960 back in the days when I was still doing implementations. 114 00:06:31,280 --> 00:06:35,000 You had a, you had a cluster, you had a vcentre server and 115 00:06:35,000 --> 00:06:36,480 there were multiple clusters, etcetera. 116 00:06:36,480 --> 00:06:40,320 But a fleet, it did not exist. So maybe we could start at the 117 00:06:40,320 --> 00:06:43,040 top and then work our way down. So some of the listeners were 118 00:06:43,040 --> 00:06:47,560 not that familiar with the VCF constructs or with VCF in 119 00:06:47,560 --> 00:06:51,680 general, can understand as well what that actually means and you 120 00:06:51,680 --> 00:06:54,080 know what that relates to or how they should look at it. 121 00:06:54,080 --> 00:06:55,880 So maybe we can start at that. What is a fleet? 122 00:06:55,880 --> 00:06:59,560 Yeah, exactly. And you know, I'll be honest, I 123 00:06:59,560 --> 00:07:01,320 struggled with the concept of a fleet as well. 124 00:07:01,320 --> 00:07:05,040 I'd heard the term in the industry and honestly I'd heard 125 00:07:05,040 --> 00:07:07,040 it more from a hyper scaler perspective. 126 00:07:07,040 --> 00:07:11,560 But in essence, what what we're trying to say is from a, the 127 00:07:11,560 --> 00:07:16,120 fleet concept is all about sort of a single set of management 128 00:07:16,120 --> 00:07:22,360 components to help you orchestrate, operate many pools 129 00:07:22,360 --> 00:07:25,080 of infrastructure from a single location. 130 00:07:25,080 --> 00:07:30,240 So think of a simple concept, and we kind of had this in VCF 131 00:07:30,240 --> 00:07:34,480 before 9 dot O things like certificate management, like 132 00:07:34,480 --> 00:07:38,240 being able to configure integration into your Microsoft 133 00:07:38,240 --> 00:07:43,280 CA in one location and then very easily from a single UI be able 134 00:07:43,280 --> 00:07:46,800 to, you know, update and cycle through certificate updates 135 00:07:47,320 --> 00:07:49,200 across your whole infrastructure. 136 00:07:49,360 --> 00:07:53,320 So rather than managing things and on an individual vcenter 137 00:07:53,320 --> 00:07:55,360 level, which is kind of what we've always done, right, it's 138 00:07:55,400 --> 00:07:58,400 you know, okay, you had it enhanced link mode, but it's 139 00:07:58,400 --> 00:08:01,240 very, you know, you do something in one vcenter, you go and do it 140 00:08:01,240 --> 00:08:03,320 again another vcenter and so on and so forth. 141 00:08:03,760 --> 00:08:07,120 So it's more about having this single management control plane 142 00:08:07,840 --> 00:08:11,200 where you have all your infrastructure easily managed. 143 00:08:11,200 --> 00:08:13,720 You can define policies centrally and then you can apply 144 00:08:13,720 --> 00:08:17,000 those policies down onto the underlying components. 145 00:08:17,760 --> 00:08:21,400 So that's the sort of like the top level in terms of of how 146 00:08:21,400 --> 00:08:24,960 we're kind of pushing VCF as a platform in that you create a 147 00:08:24,960 --> 00:08:28,200 fleet and within the fleet you then have all of your cascading 148 00:08:28,200 --> 00:08:30,480 components for your software defined data centre underneath. 149 00:08:31,040 --> 00:08:32,320 Yeah. And some of those cascading 150 00:08:32,320 --> 00:08:34,919 components of course are the, you probably already alluded to 151 00:08:34,919 --> 00:08:36,880 it in an earlier rounds of the instance. 152 00:08:37,200 --> 00:08:39,280 And then we've got a domain as well. 153 00:08:39,600 --> 00:08:42,679 So how does that relate to the fleet and how does that relate 154 00:08:42,679 --> 00:08:44,800 to each other? Because that also got me 155 00:08:44,800 --> 00:08:47,920 confused fairly fast. I mean, I love clusters and 156 00:08:47,920 --> 00:08:49,800 that's usually where it ends. And then of course, all of a 157 00:08:49,800 --> 00:08:52,360 sudden we've got a fleet, we've got an instance, we've got a 158 00:08:52,360 --> 00:08:54,000 domain. Explain it to. 159 00:08:54,000 --> 00:08:56,240 Me so. So first of all, the term VCF 160 00:08:56,240 --> 00:09:00,000 instance, so that that's obviously a well known term in 161 00:09:00,000 --> 00:09:04,480 terms of VCF. So you know in in 3234 and five 162 00:09:04,480 --> 00:09:09,480 we refer to AVCF instance. And the way that I describe 163 00:09:09,560 --> 00:09:12,560 instant AVCF instances is think of it as like a a control or 164 00:09:12,560 --> 00:09:16,320 management boundary. So the the concept of AVCF 165 00:09:16,320 --> 00:09:21,680 instance effectively in the old world is an STDC manager. 166 00:09:21,680 --> 00:09:24,360 So, you know, I think anybody that's familiar with VCF in the 167 00:09:24,360 --> 00:09:30,280 past will know STDC manager was kind of that fleet manager, but 168 00:09:30,280 --> 00:09:32,320 only for the things it controlled. 169 00:09:32,320 --> 00:09:35,720 So essentially the way that you should think about it is that 170 00:09:35,720 --> 00:09:40,040 we're moving the the sort of the the fleet management 171 00:09:40,040 --> 00:09:42,440 capabilities like the life cycle management, which is probably 172 00:09:42,440 --> 00:09:44,840 the biggest one. But again, referring back to 173 00:09:44,840 --> 00:09:47,840 that CERT management and password management capabilities 174 00:09:47,840 --> 00:09:51,640 that we have at the STC manager level, we're moving that up into 175 00:09:51,640 --> 00:09:54,000 the fleet. So you then can have multiple 176 00:09:54,000 --> 00:09:56,920 VCF instances and be able to control those policies. 177 00:09:57,920 --> 00:10:02,320 But an instance really is where you get down into the, the stuff 178 00:10:02,320 --> 00:10:06,640 that you and I know very well, you know, AV centre where you 179 00:10:06,640 --> 00:10:11,320 then have your compute, your resources, network storage, 180 00:10:11,320 --> 00:10:13,400 etcetera, from a software defined data centre. 181 00:10:14,120 --> 00:10:17,640 And when it comes to AVCF instance, we have this concept 182 00:10:17,640 --> 00:10:21,520 of VCF domains. So again, it's a slightly 183 00:10:21,520 --> 00:10:25,000 different change in language, but we're starting to refer to, 184 00:10:25,000 --> 00:10:29,040 you know, VCF instance has multiple VCF domains and then 185 00:10:29,040 --> 00:10:32,480 within the domains you have the next layer of the platform. 186 00:10:33,520 --> 00:10:37,120 Yeah, that that part I, I started to get used to it as as 187 00:10:37,120 --> 00:10:39,840 you mentioned because it was already part of the the VCF 188 00:10:39,840 --> 00:10:44,320 stack for a while now. What kind of confused me then is 189 00:10:44,320 --> 00:10:47,440 when I started looking at some of the diagrams is that if you 190 00:10:47,440 --> 00:10:50,840 look at some of the other products that are involved, 191 00:10:50,920 --> 00:10:56,200 things like VCF automation, VCF OPS, where that boundary is for 192 00:10:56,200 --> 00:10:58,320 those products. So can they actually span 193 00:10:58,320 --> 00:11:00,680 domains, Can they span instances? 194 00:11:01,080 --> 00:11:03,440 How does that actually work and what are your thoughts on? 195 00:11:03,440 --> 00:11:05,520 That yeah. So I guess this is where you 196 00:11:05,520 --> 00:11:08,160 start to bring it together. Now we understand what you know, 197 00:11:08,160 --> 00:11:10,400 a domain is VCF domain, what a fleet is. 198 00:11:11,600 --> 00:11:14,000 We then look at the the the component pieces. 199 00:11:14,000 --> 00:11:19,560 So to your point, VCF automation and VCF operations, those are 200 00:11:19,560 --> 00:11:23,520 referred to as what we define as the fleet level components. 201 00:11:24,000 --> 00:11:30,760 So from a construct perspective, those components sit as a fleet 202 00:11:30,760 --> 00:11:33,320 level. And then all of the VCF 203 00:11:33,320 --> 00:11:37,960 instances which contain your SDC manager, your V centres, your 204 00:11:37,960 --> 00:11:42,160 NSX manager components can all be managed from from those 205 00:11:42,160 --> 00:11:46,400 single fleet level. So as you start to scale out, 206 00:11:46,400 --> 00:11:49,920 you would add more VCF instances and they'll be managed from 207 00:11:50,000 --> 00:11:54,800 those individual VCF operations and automation components. 208 00:11:57,000 --> 00:12:03,400 So right now in VCF 9, for every fleet, you only have one 209 00:12:03,400 --> 00:12:06,080 automation instance and one operations instance. 210 00:12:06,800 --> 00:12:10,360 And I know that that has become, you know, a bit of a change for 211 00:12:10,360 --> 00:12:13,800 some organisations because if you think about certainly 212 00:12:13,800 --> 00:12:16,760 financial services is, is an interesting space because a lot 213 00:12:16,760 --> 00:12:20,240 of financial services have multiple platforms. 214 00:12:21,240 --> 00:12:23,400 And you'll be familiar with this in terms of, you know, they have 215 00:12:23,400 --> 00:12:25,840 a dev platform, but then they have their prod and their pre 216 00:12:25,840 --> 00:12:28,520 prod. Now in the, in the old world, 217 00:12:28,800 --> 00:12:31,360 that was very easy because you could easily segregate them. 218 00:12:31,360 --> 00:12:34,320 And you just say we'll have AV centre manage my dev, AV centre 219 00:12:34,320 --> 00:12:37,080 for my prod and AV centre for my pre prod. 220 00:12:38,800 --> 00:12:41,400 But now it's starting to get customers to think slightly 221 00:12:41,400 --> 00:12:44,400 differently that you've got to up level the management layer. 222 00:12:45,200 --> 00:12:47,200 So you could still have that separation. 223 00:12:47,200 --> 00:12:50,760 Now some organisations will require physical separation of 224 00:12:50,760 --> 00:12:54,440 those platforms, so that might be a compliance requirement. 225 00:12:54,760 --> 00:12:58,040 But by and large prod and pre prod, there doesn't need to be 226 00:12:58,040 --> 00:13:02,520 physical separation in terms of never the twain shell meat, but 227 00:13:02,600 --> 00:13:06,880 you can at least manage them from a specific, you know, from 228 00:13:06,880 --> 00:13:09,840 a fleet level point of view. So think about those VCF 229 00:13:09,840 --> 00:13:13,240 instances like I have AVCF instance which is purely prod 230 00:13:13,560 --> 00:13:15,720 and AVCF instance that is pre prod. 231 00:13:16,920 --> 00:13:21,160 And So what we'll see is as the platform evolves, we'll start to 232 00:13:21,160 --> 00:13:26,080 be able to provide additional service capabilities, but tied 233 00:13:26,080 --> 00:13:28,800 to a VCF instance level. So you kind of start to think 234 00:13:28,800 --> 00:13:32,480 about an instance as being sort of a management boundary or one 235 00:13:32,480 --> 00:13:35,720 way of controlling a set of software defined data center 236 00:13:35,720 --> 00:13:37,280 resources. Yeah. 237 00:13:37,280 --> 00:13:40,200 There are actually two things that I think are interesting to 238 00:13:40,200 --> 00:13:41,880 talk about next. Then is this. 239 00:13:41,880 --> 00:13:45,320 Of course, there's a lot of maximum configurations that we 240 00:13:45,320 --> 00:13:47,320 need to take into account. The other thing that you also 241 00:13:47,320 --> 00:13:49,360 mentioned is the physical separation. 242 00:13:49,360 --> 00:13:52,600 So we'll get into that as well. But let's start with the maximum 243 00:13:52,960 --> 00:13:55,400 maximums that we need to take into consideration and some of 244 00:13:55,400 --> 00:13:57,680 the limitations that there are from a product perspective, 245 00:13:57,680 --> 00:14:03,240 because we've got the fleet level, then of course we have 246 00:14:03,240 --> 00:14:05,280 the instance, we've got the domains. 247 00:14:05,680 --> 00:14:09,000 There are only so many numbers of V centre servers and clusters 248 00:14:09,000 --> 00:14:12,440 and hosts etcetera that you can have and even virtual machines 249 00:14:12,440 --> 00:14:16,040 have a limits on a per cluster basis, on a per vcenter server 250 00:14:16,040 --> 00:14:17,800 basis. So what are some of some of 251 00:14:17,800 --> 00:14:19,480 those things customers need to think about? 252 00:14:20,320 --> 00:14:23,520 Well, I mean, I'm assuming the smaller customers, they're 253 00:14:23,520 --> 00:14:25,760 probably not, you know, overly concerned about those things if 254 00:14:25,760 --> 00:14:29,320 you don't have 100,000 VMS. But what if I have 100,000 VMS? 255 00:14:29,720 --> 00:14:32,440 What does that actually look like and how do I go about 256 00:14:32,720 --> 00:14:34,040 constructing those? Things, yeah. 257 00:14:34,320 --> 00:14:36,680 And it's, I think this is probably the biggest challenge 258 00:14:36,680 --> 00:14:39,760 that our customers are finding actually is, you know, the 259 00:14:39,760 --> 00:14:42,560 concept of I want to control everything from a single fleet. 260 00:14:42,560 --> 00:14:44,560 I think everyone loves they're like, this is brilliant. 261 00:14:44,560 --> 00:14:47,880 I can define a policy once or multiple policies and just push 262 00:14:47,880 --> 00:14:51,800 them down to my infrastructure. In terms of the scales and 263 00:14:51,800 --> 00:14:55,240 imitations, what we've found with the conversations with with 264 00:14:55,240 --> 00:14:59,680 customers so far is they really fall into three key areas. 265 00:15:00,080 --> 00:15:02,400 First of all, you've already mentioned scale. 266 00:15:04,120 --> 00:15:08,480 Scale's an interesting topic and it's a really confusing topic in 267 00:15:08,480 --> 00:15:12,520 my view. You know, we are evolving the 268 00:15:12,520 --> 00:15:16,320 platform, we've etched each new update and each new release. 269 00:15:16,320 --> 00:15:19,320 And you know, the, the, the biggest challenge I think that 270 00:15:19,320 --> 00:15:23,360 we've, we've found is I think we underestimated the sort of the 271 00:15:23,360 --> 00:15:25,680 conversation around the scale numbers. 272 00:15:25,920 --> 00:15:29,840 Because if you, if you look up where we were, you know, 7 or 8 273 00:15:29,840 --> 00:15:32,440 individual products coming together as a single product, 274 00:15:32,960 --> 00:15:37,160 each one of those components had different scale limitations. 275 00:15:38,320 --> 00:15:42,160 And as a customer or, or even as an architect coming in at the 276 00:15:42,160 --> 00:15:46,120 platform and going, well, I've got 50,000 VMS. What does that 277 00:15:46,120 --> 00:15:48,600 look like from an architecture is a real challenge. 278 00:15:50,240 --> 00:15:54,360 So especially when different products use different values 279 00:15:54,360 --> 00:15:58,200 for their scale, Like, you know what, what's, you know, 1 system 280 00:15:58,200 --> 00:16:01,760 might be, it's all about VMS. Another system might be, it's 281 00:16:01,760 --> 00:16:04,680 about objects that you create in, in the platform. 282 00:16:05,760 --> 00:16:09,320 But I think the, the, the biggest, the biggest scale 283 00:16:09,320 --> 00:16:13,800 concern is really sort of if you think what we've done, we've 284 00:16:13,800 --> 00:16:17,080 made operations the centre of the universe for a fleet, right? 285 00:16:17,080 --> 00:16:22,360 So really the key aspect there is around the scale limitations 286 00:16:22,360 --> 00:16:24,960 of operations. And actually operations is 287 00:16:25,200 --> 00:16:26,920 pretty good from a scale perspective. 288 00:16:27,640 --> 00:16:30,960 But it's working out those, those numbers as to how big you 289 00:16:30,960 --> 00:16:33,320 need the appliances to be from the from the outset, because 290 00:16:33,320 --> 00:16:36,640 it's all around metrics being collected, all these objects and 291 00:16:36,640 --> 00:16:41,000 stuff. We continue to add and improve 292 00:16:41,000 --> 00:16:44,880 on those numbers, which I I think is starting to remove the 293 00:16:44,880 --> 00:16:48,120 conversation proof from a scale point of view because you know, 294 00:16:48,120 --> 00:16:50,240 customers do have big infrastructure. 295 00:16:50,240 --> 00:16:53,720 But I think the second limitation actually 296 00:16:54,160 --> 00:16:57,760 counterbalances the first on scale and that's network 297 00:16:57,760 --> 00:17:00,680 connectivity. So we've we've had many 298 00:17:00,680 --> 00:17:04,200 customers come to us and say, I'm a global organization, I 299 00:17:04,200 --> 00:17:06,200 want a single fleet to manage the world. 300 00:17:07,359 --> 00:17:11,319 And then, you know, you start talking latency, bam whips. 301 00:17:11,319 --> 00:17:13,480 And that's where the next challenge comes. 302 00:17:15,000 --> 00:17:18,480 And we've done a lot in the product recently to, to improve 303 00:17:18,480 --> 00:17:21,800 that. So as you know from a, from a 304 00:17:21,800 --> 00:17:25,119 storage, you know, you've got V SAN stretch cluster latency 305 00:17:25,119 --> 00:17:30,080 limitations, then you've got V centre, V motion, DRS latency 306 00:17:30,080 --> 00:17:33,160 limitations, and then you start to layer in operations as well 307 00:17:33,160 --> 00:17:36,720 on top. I think when we first released 308 00:17:37,520 --> 00:17:42,120 VCF 9, we were stating 150 milliseconds was the limitation 309 00:17:42,120 --> 00:17:45,280 for a fleet. Well, you can imagine how that 310 00:17:45,280 --> 00:17:47,640 that went down, right? Literally every customer's 311 00:17:47,640 --> 00:17:51,680 going, Yep, we'll be doing a fleet then because that's just 312 00:17:51,680 --> 00:17:53,200 not going to work in my organization. 313 00:17:54,080 --> 00:17:57,200 So we've we've actually been working quite heavily in those 314 00:17:57,200 --> 00:17:59,840 those areas. I know you know, members of 315 00:17:59,840 --> 00:18:02,520 engineering, the PM team have been focused on that recently. 316 00:18:02,840 --> 00:18:06,240 We recently published a new ports and protocols diagram. 317 00:18:07,040 --> 00:18:09,520 The key thing being 300 milliseconds, which was the 318 00:18:09,520 --> 00:18:14,080 target as being sort of like the the sort of limiting factor when 319 00:18:14,080 --> 00:18:18,680 it talks about fleet managing AVCF instance and such like. 320 00:18:18,680 --> 00:18:22,320 And I think, and this was a question I asked at the V mag 321 00:18:22,320 --> 00:18:26,040 connect in Amsterdam that we were at together, you know, how 322 00:18:26,040 --> 00:18:29,200 many people could actually withstand 300 milliseconds? 323 00:18:29,240 --> 00:18:32,160 And surprisingly, most people in the room put their hands up. 324 00:18:32,160 --> 00:18:35,560 Now, I'm assuming that's because they're not large necessarily 325 00:18:35,560 --> 00:18:38,680 global enterprises because you've always got the odd few 326 00:18:38,680 --> 00:18:42,800 here and there that, you know, will will want to be managing 327 00:18:42,800 --> 00:18:47,960 sort of Asia Pacific plus America's and, you know, Europe 328 00:18:47,960 --> 00:18:50,760 at the same time. And then the third dynamic is 329 00:18:50,760 --> 00:18:52,560 really around organizational placement. 330 00:18:54,440 --> 00:18:58,040 Organizational structure may in itself mean that you need to 331 00:18:58,040 --> 00:19:01,320 consider whether a single fleet makes sense if you've got, you 332 00:19:01,320 --> 00:19:03,680 know, operationally different teams managing different 333 00:19:03,680 --> 00:19:07,360 regions. And so that in itself could mean 334 00:19:07,360 --> 00:19:12,360 that actually one single fleet isn't really a possibility and 335 00:19:12,360 --> 00:19:15,240 that you start to need then already need to sort of consider 336 00:19:15,520 --> 00:19:18,120 maybe multiple fleets as at least an entry point. 337 00:19:18,120 --> 00:19:22,240 But at least you're with the fleet concept, you can I think 338 00:19:22,240 --> 00:19:26,720 scale the the boundary of what you're managing operation 339 00:19:26,720 --> 00:19:29,800 organizationally so that you can start to get those operational 340 00:19:29,800 --> 00:19:31,920 efficiencies of of cloud like infrastructure. 341 00:19:33,080 --> 00:19:35,120 Yeah. I mean, if I look at most of the 342 00:19:35,120 --> 00:19:38,640 customers I talk to on a daily basis, I think for the majority 343 00:19:38,640 --> 00:19:41,800 of them, a single fleet would work, unless we're actually 344 00:19:41,800 --> 00:19:45,360 specifically talking about a solution where, for instance, 345 00:19:45,360 --> 00:19:49,400 disaster recovery or ransomware recovery comes into play. 346 00:19:49,720 --> 00:19:52,520 And The funny thing is that I hadn't actually given this much 347 00:19:52,520 --> 00:19:54,280 thought. But when I started talking 348 00:19:54,280 --> 00:19:57,440 about, for instance, ransomware recovery, the first question one 349 00:19:57,440 --> 00:20:00,280 of the VCF customers I asked is, OK, what do I do from a fleet 350 00:20:00,280 --> 00:20:03,040 management perspective? Because we're also talking about 351 00:20:03,040 --> 00:20:05,440 authentication domain. So what is your opinion on that? 352 00:20:05,440 --> 00:20:08,440 When we talk about those types of constructs, Dr. A ransomware 353 00:20:08,440 --> 00:20:12,400 recovery. So, yeah, so I think the 354 00:20:12,400 --> 00:20:16,040 challenge is that even with any ransomware platform, you've got 355 00:20:16,040 --> 00:20:19,000 some kind of connectivity. So it's more about controlling 356 00:20:19,000 --> 00:20:20,920 the flow and the access controls. 357 00:20:22,200 --> 00:20:24,600 And I don't know if if people listen to this, we're actually 358 00:20:24,600 --> 00:20:28,960 aware, but we did release in 9.0 time frame. 359 00:20:28,960 --> 00:20:31,000 We actually had AVM Ware validated solution. 360 00:20:31,000 --> 00:20:33,640 So I didn't mention this at the top, top of the session. 361 00:20:33,640 --> 00:20:36,680 But I was also tech lead for VM Ware validated solutions for 362 00:20:36,680 --> 00:20:38,680 about 3 years. So that was kind of like the 363 00:20:38,720 --> 00:20:43,200 evolution of VVD as VCF was taking off and how we lay down 364 00:20:43,200 --> 00:20:45,040 additional capabilities on top of the platform. 365 00:20:45,600 --> 00:20:50,000 And we worked very closely with the PM and engineering teams to 366 00:20:50,000 --> 00:20:55,120 build the first ransomware on Prem ransomware recovery. 367 00:20:56,720 --> 00:20:59,560 And in terms of that architecture, the concept is 368 00:20:59,560 --> 00:21:01,560 it's a single fleet. It's just that you've got an 369 00:21:01,560 --> 00:21:04,320 isolated workload domain in the recovery instance. 370 00:21:04,320 --> 00:21:08,160 And then of course, you need to lay down the various components 371 00:21:08,160 --> 00:21:09,800 to make sure you've got the security. 372 00:21:09,800 --> 00:21:13,200 So ensuring that you've got no V defend firewalls so that 373 00:21:13,200 --> 00:21:17,280 replication be sent in. You have immutable snapshot 374 00:21:17,640 --> 00:21:21,560 storage clusters that can be used for storing your VM 375 00:21:21,560 --> 00:21:26,360 replication, that kind of stuff. So I don't feel like customers 376 00:21:26,360 --> 00:21:29,400 need to or I need another fleet just to be able to do ransomware 377 00:21:29,400 --> 00:21:32,880 recovery. I think we have a story, and as 378 00:21:32,880 --> 00:21:35,960 you know, we've been working on improving that story coming in 379 00:21:35,960 --> 00:21:40,840 9.1 with better integration, more automated workflow, because 380 00:21:40,840 --> 00:21:44,320 a lot of the stuff we did in the 9 dot O release was very sort of 381 00:21:45,360 --> 00:21:47,800 relying on the technology that was available, but some of the 382 00:21:47,800 --> 00:21:49,520 orchestrated workflows weren't there. 383 00:21:50,360 --> 00:21:53,960 So I think the ransomware story for me is that, you know, we can 384 00:21:53,960 --> 00:21:56,440 deliver it and we can deliver it within a fleet. 385 00:21:56,440 --> 00:21:59,520 So we shouldn't have to go and build another set of 386 00:21:59,520 --> 00:22:01,640 infrastructure from a fleet management point of view. 387 00:22:01,920 --> 00:22:04,400 But obviously we need to make sure that, you know, we've got 388 00:22:04,600 --> 00:22:07,400 that clear isolated worker domain for the recovery 389 00:22:07,400 --> 00:22:12,680 instance, integrated endpoint detection response solutions to 390 00:22:12,680 --> 00:22:16,840 help do it, and then V Defend, you know, V Defend Firewall not 391 00:22:16,840 --> 00:22:19,160 only helps us secure the communication between the 392 00:22:19,160 --> 00:22:22,760 instances, but also enduring the recovery process. 393 00:22:22,840 --> 00:22:24,560 Yeah. And I guess if you do want to do 394 00:22:24,560 --> 00:22:27,880 an additional fleet just from a, you know, separation 395 00:22:27,880 --> 00:22:29,960 perspective, you can still do that, right. 396 00:22:29,960 --> 00:22:32,000 So it's not. You have the option here. 397 00:22:32,200 --> 00:22:34,400 Absolutely, Yeah. Yeah, there's nothing stopping 398 00:22:34,400 --> 00:22:36,400 you from doing it. I think, you know, we just don't 399 00:22:36,400 --> 00:22:40,000 feel that you have to do it because you know, from an 400 00:22:40,000 --> 00:22:43,400 authentication point of view, and we haven't talked about this 401 00:22:43,400 --> 00:22:45,760 at all, but one of the new features that we have in nine is 402 00:22:45,760 --> 00:22:50,120 the identity broker with what we refer to as VCF single sign on. 403 00:22:51,160 --> 00:22:54,840 And VCF single sign on can be done at different levels. 404 00:22:54,840 --> 00:22:57,840 So you can have instance specific or you can have fleet 405 00:22:57,840 --> 00:23:00,160 wide. So from an authentication point 406 00:23:00,160 --> 00:23:02,720 of view, there's nothing stopping you not enabling the 407 00:23:02,720 --> 00:23:07,120 VCF single sign on features within that instance. 408 00:23:07,120 --> 00:23:10,920 That's your recovery site and that you, you fall back to local 409 00:23:10,920 --> 00:23:14,440 account management or even you create your own dedicated 410 00:23:14,960 --> 00:23:18,640 localised instance of the identity broker to be able to 411 00:23:18,640 --> 00:23:20,960 manage that as a separate authentication domain. 412 00:23:21,440 --> 00:23:24,520 So I think there's, there's enough stuff in the product from 413 00:23:24,520 --> 00:23:27,400 a capability point of view that we can deal with a lot of the 414 00:23:27,400 --> 00:23:31,120 security concerns. It's still early days, I would 415 00:23:31,120 --> 00:23:34,400 say in terms of the on Prem cyber recovery aspect. 416 00:23:35,760 --> 00:23:41,760 But knowing how how popular the cloud version was, the fact that 417 00:23:41,760 --> 00:23:46,240 we're now bringing it on Prem, I wonder how much of sort of, you 418 00:23:46,240 --> 00:23:49,040 know, being part of a single fleet is a concern for, for 419 00:23:49,040 --> 00:23:51,920 organisations because they've already removed it from the, you 420 00:23:51,920 --> 00:23:53,560 know, they were doing it to the cloud. 421 00:23:53,840 --> 00:23:55,800 That involves them going out to the Internet. 422 00:23:55,800 --> 00:23:59,320 So already they're kind of, you know, bringing back on Prem to 423 00:23:59,320 --> 00:24:01,440 help with the security lab. Yeah, I think it's going to be 424 00:24:01,440 --> 00:24:06,040 one of those solutions that will literally, you know, create an 425 00:24:06,040 --> 00:24:09,080 explosion within the the company in terms of people looking for 426 00:24:09,080 --> 00:24:12,240 knowledge everywhere to understand what it is that we're 427 00:24:12,240 --> 00:24:14,240 trying to solve here. Because even with the 428 00:24:14,240 --> 00:24:16,920 conversations that I'm having with customers, sometimes you'll 429 00:24:16,920 --> 00:24:19,840 find yourself, you know, Googling acronyms as you go 430 00:24:19,840 --> 00:24:22,360 through the conversation itself because there's so many new 431 00:24:22,360 --> 00:24:25,920 terms popping up everywhere. It's it's almost impossible. 432 00:24:25,920 --> 00:24:27,440 Now. The other thing also which I 433 00:24:27,440 --> 00:24:30,760 found interesting is when we talk about availability, 434 00:24:30,760 --> 00:24:33,800 recovery ability, etcetera, from AVCF perspective, of course, I 435 00:24:33,800 --> 00:24:36,800 know we support stress clusters. It's one of those things which 436 00:24:37,520 --> 00:24:40,040 you know, a lot of customers, especially in Europe are asking, 437 00:24:40,200 --> 00:24:42,640 asking for. But there's also replication at 438 00:24:42,640 --> 00:24:45,480 the storage level, replication at the VM level. 439 00:24:46,120 --> 00:24:49,800 We also do some things at the application level and that also 440 00:24:49,800 --> 00:24:53,400 can or may apply to the management stack. 441 00:24:53,880 --> 00:24:56,760 So what is it that you typically see customers implemented? 442 00:24:56,760 --> 00:24:59,560 Because I think that's also a big part of what your team does, 443 00:24:59,560 --> 00:25:01,640 right, being involved with the implementation. 444 00:25:01,640 --> 00:25:03,720 So I would be interested in understanding what it is that 445 00:25:03,720 --> 00:25:07,440 customers do. Yeah, and you know, it's an 446 00:25:07,440 --> 00:25:09,720 evolving story when it comes to the management stack. 447 00:25:09,720 --> 00:25:14,760 So, you know, I'd like to say that we have a fully fledged 448 00:25:14,760 --> 00:25:17,920 out, you know, recoverability and availability storage VCF. 449 00:25:18,280 --> 00:25:21,280 The fact of the matter is, you know, 9 dot O was the first 450 00:25:21,280 --> 00:25:25,400 release. As you know, a lot of the focus 451 00:25:25,400 --> 00:25:28,520 was on the single UIS, you know, single operational stack. 452 00:25:29,680 --> 00:25:32,520 We still have some work to do from a recoverability point of 453 00:25:32,520 --> 00:25:36,120 view. But you know, if I kind of go 454 00:25:36,120 --> 00:25:39,640 back to the VVD days, we had pretty good story there. 455 00:25:39,760 --> 00:25:43,360 Recoverability from a management stack point of view was you 456 00:25:43,360 --> 00:25:48,520 know, you have application level HA, so pretty much most 457 00:25:48,520 --> 00:25:53,280 components have, you know, an HA story. 458 00:25:53,280 --> 00:25:56,640 So if you think about things like log management, you think 459 00:25:56,640 --> 00:25:59,600 about automation and VCF operations, you have choices 460 00:25:59,600 --> 00:26:03,720 there. V centre has always been the 461 00:26:03,720 --> 00:26:07,320 interesting one from an application high availability, 462 00:26:07,320 --> 00:26:14,760 you know, we have V centre HAI think probably I don't know how 463 00:26:14,760 --> 00:26:17,520 I would put this, but our team's always been a little bit sort of 464 00:26:17,520 --> 00:26:21,600 hesitant to include V centre HA into our architecture designs. 465 00:26:22,760 --> 00:26:28,040 We've always felt that the the sort of the pain of configuring, 466 00:26:28,040 --> 00:26:32,960 maintaining and operating was far greater than the benefit you 467 00:26:32,960 --> 00:26:35,760 received compared to V sphere HA, right. 468 00:26:35,760 --> 00:26:37,840 Just to be brutally blunt on the topic. 469 00:26:39,240 --> 00:26:42,640 So, you know, VCN, VCN has always been a bit of a single 470 00:26:42,640 --> 00:26:46,240 point of failure except for, well, VCF HA recovers and you 471 00:26:46,240 --> 00:26:49,760 know, how much do you need it from a day-to-day running of the 472 00:26:49,760 --> 00:26:51,440 business application. It's just, you know, when it 473 00:26:51,440 --> 00:26:52,720 comes to management, there's an issue. 474 00:26:54,520 --> 00:26:58,080 Now, obviously, you know, the way that we're building VCF 9 475 00:26:58,080 --> 00:27:05,080 now is, is continuing to evolve. You know, we introduced more of 476 00:27:05,080 --> 00:27:09,240 a containerized platform and you know, we have some limitations 477 00:27:09,240 --> 00:27:11,640 like things like life recovery, being able to protect a 478 00:27:11,640 --> 00:27:13,360 container, right? It's not there. 479 00:27:13,400 --> 00:27:15,000 It's something that we're looking at and you know, 480 00:27:15,000 --> 00:27:18,160 hopefully that will come. So I think we still have sort of 481 00:27:18,160 --> 00:27:24,360 HA from a management component for most aspects of the stack, 482 00:27:25,840 --> 00:27:28,360 backup and restore. Obviously, you know, everyone 483 00:27:28,360 --> 00:27:29,760 needs to be backing up and restore. 484 00:27:31,320 --> 00:27:34,520 You know, we, we have some, some, some areas like automation 485 00:27:34,520 --> 00:27:38,160 is a bit more of a backup and restore for Dr. today that 486 00:27:38,160 --> 00:27:42,320 hopefully will evolve over time. And of course, you know, some 487 00:27:42,320 --> 00:27:44,760 pieces we can still replicate using storage replication. 488 00:27:44,760 --> 00:27:47,520 So you know, we've been a big user of Visa replication in the 489 00:27:47,520 --> 00:27:49,560 past. We now have V SAN replication 490 00:27:49,560 --> 00:27:53,840 built in. So I think the options and the 491 00:27:53,840 --> 00:27:58,040 availability is constantly improving in, in terms of what 492 00:27:58,040 --> 00:28:00,840 we, what we've seen in the past, we've we've certainly seen 493 00:28:02,000 --> 00:28:05,440 stretch clusters in Europe is a big, big thing. 494 00:28:06,840 --> 00:28:08,800 It's, it's always interesting when you talk about V sphere 495 00:28:08,800 --> 00:28:12,640 stretch cluster, you know, is that availability or is that 496 00:28:12,640 --> 00:28:15,720 disaster recovery? Not going to get into that 497 00:28:15,720 --> 00:28:18,920 debate here, but you know, I've had, I've heard customers say 498 00:28:18,920 --> 00:28:23,080 things that I've, I totally disagree with snapshots. 499 00:28:23,200 --> 00:28:25,000 Oh, it's a backup. Is it, is it though? 500 00:28:25,640 --> 00:28:27,360 You know, those kind of conversations that we've 501 00:28:27,360 --> 00:28:30,120 probably had many times and you know, I see you smiling. 502 00:28:30,120 --> 00:28:31,760 You probably had those conversations as well. 503 00:28:33,560 --> 00:28:40,040 So, you know, I think stretched is, is definitely a hot topic in 504 00:28:40,040 --> 00:28:42,200 Europe. US becomes a bit more of a 505 00:28:42,200 --> 00:28:46,080 challenge. So replication, being able to 506 00:28:46,080 --> 00:28:49,080 replicate within the hypervisor obviously is a, is a massive 507 00:28:49,080 --> 00:28:53,280 win, massive capability there to be able to protect stuff. 508 00:28:53,280 --> 00:28:57,960 So it's definitely sort of, you know, we've got a lot of 509 00:28:57,960 --> 00:29:00,360 customers using the storage replication as well, right? 510 00:29:00,360 --> 00:29:06,240 So having orchestrated recovery with live recovery as well, I 511 00:29:06,240 --> 00:29:08,640 think we'll start to see a lot more in that space, which is 512 00:29:08,640 --> 00:29:11,920 actually quite exciting for me because I, I started out as a 513 00:29:12,000 --> 00:29:15,040 consultant, a professional services, as you know, in the 514 00:29:15,040 --> 00:29:19,800 team that used to be in and a big part of my day job was site 515 00:29:19,800 --> 00:29:22,240 recovery manager projects. I did an awful lot of, of 516 00:29:22,240 --> 00:29:27,280 disaster recovery engagements. And yeah, obviously it was all 517 00:29:27,280 --> 00:29:29,800 storage replication back then. So I think sort of, you know, 518 00:29:29,800 --> 00:29:33,960 having the flexibility and choice is definitely making 519 00:29:33,960 --> 00:29:36,840 making the optionality a lot, a lot better for our customers. 520 00:29:37,520 --> 00:29:39,720 I did the very first implementation of Site Recovery 521 00:29:39,720 --> 00:29:43,720 Manager worldwide. And at this point in time, I 522 00:29:43,720 --> 00:29:45,960 mean I haven't done much with Site Recovery Manager since 523 00:29:45,960 --> 00:29:49,040 then, probably not in the last 15 years or so. 524 00:29:49,040 --> 00:29:51,440 But it's all coming back again now with Live recovery and 525 00:29:51,440 --> 00:29:55,120 especially with the ransomware effort that we have have ongoing 526 00:29:55,120 --> 00:29:57,040 and the conversations that we're having with the customers, it 527 00:29:57,040 --> 00:29:59,240 seems to be more important than ever before. 528 00:29:59,680 --> 00:30:02,080 Now you've mentioned that you've seen some of the customers 529 00:30:02,080 --> 00:30:04,720 implementing that before the management stack. 530 00:30:04,720 --> 00:30:08,800 I'm assuming that also applies to their workload domains then, 531 00:30:08,800 --> 00:30:11,240 right? Are they implementing similar 532 00:30:11,240 --> 00:30:12,720 technologies or what are they doing? 533 00:30:13,040 --> 00:30:14,640 Yeah, I think, I think there's a mixture there. 534 00:30:15,280 --> 00:30:18,680 So obviously, you know, there's, there's massive shift to, to 535 00:30:18,760 --> 00:30:21,000 what we refer to as modern applications, right. 536 00:30:21,680 --> 00:30:26,680 And I, I think certainly where customers can, they're, they're 537 00:30:26,680 --> 00:30:29,480 sort of reviewing their applications, how the 538 00:30:29,480 --> 00:30:33,520 applications are built, shifting a little bit away from 539 00:30:34,560 --> 00:30:37,520 infrastructure being the thing that does availability to 540 00:30:37,520 --> 00:30:39,760 actually, well, let's build into the application natively, 541 00:30:39,760 --> 00:30:41,480 because then actually we don't really care about the 542 00:30:41,480 --> 00:30:43,560 infrastructure. It just becomes pools of 543 00:30:43,560 --> 00:30:47,280 resource. So, you know, we see a lot of 544 00:30:47,280 --> 00:30:51,520 that, but where that's not possible, I, I think, you know, 545 00:30:51,720 --> 00:30:54,080 go back to the live recovery visa application. 546 00:30:54,080 --> 00:30:57,440 Those tools work just as well to be able to do the recovery. 547 00:30:58,880 --> 00:31:00,800 I guess the, the biggest challenge with a lot of these 548 00:31:00,800 --> 00:31:04,400 these organisations and lots of customers is fully understanding 549 00:31:04,400 --> 00:31:08,320 the impact of an application. You know, we talked about 15 550 00:31:08,320 --> 00:31:10,400 years ago, I don't think the world has changed that much 551 00:31:10,400 --> 00:31:13,080 because organization, you know, the personnel change, people 552 00:31:13,080 --> 00:31:16,920 that had knowledge move on. So I think the biggest challenge 553 00:31:16,920 --> 00:31:20,640 with application recovery is, well, what happens when this 554 00:31:20,640 --> 00:31:23,360 component fails and what does it talk to and what do I need to 555 00:31:23,360 --> 00:31:25,920 fail with? It has always been the, the 556 00:31:25,920 --> 00:31:29,040 biggest issue and that was always the biggest part of most 557 00:31:29,040 --> 00:31:32,640 of my consultancy engagements was helping them understand and 558 00:31:32,640 --> 00:31:35,920 doing the discovery of what they need to protect as a group of 559 00:31:36,240 --> 00:31:39,080 services to actually fail over an application. 560 00:31:39,080 --> 00:31:42,360 Because, you know, it's very easy to go, well, that's, that's 561 00:31:42,360 --> 00:31:45,280 my application server. But if it talks to three other 562 00:31:45,280 --> 00:31:47,960 things and they're critical, you know, and you don't know about 563 00:31:47,960 --> 00:31:50,480 it, then you don't really have a disaster recovery plan. 564 00:31:50,560 --> 00:31:54,200 And I guess the same applies to to that from a VCF constructs 565 00:31:54,200 --> 00:31:55,920 perspective, right? If you don't know what is 566 00:31:55,920 --> 00:31:58,920 talking to what, how do you know which virtual machines or 567 00:31:58,920 --> 00:32:03,440 services should be part of the same domain instance slash 568 00:32:03,440 --> 00:32:05,400 fleet? I guess the same applies there 569 00:32:05,400 --> 00:32:06,560 as well. Yeah. 570 00:32:06,760 --> 00:32:09,280 And also understanding, you know, not just the 571 00:32:09,280 --> 00:32:11,680 communication, but actually which bits are critical. 572 00:32:11,680 --> 00:32:15,640 And you know, we had this debate internally where product 573 00:32:15,640 --> 00:32:19,200 management was going, well, we need to recover components 574 00:32:19,200 --> 00:32:22,520 ABCDEFG. And then, you know, we look at 575 00:32:22,520 --> 00:32:26,640 it from our experience of going, why we're going to recover AV 576 00:32:26,680 --> 00:32:30,760 Centre that is only managing infrastructure in that data 577 00:32:30,760 --> 00:32:33,040 centre, in the primary data centre. 578 00:32:33,360 --> 00:32:35,720 If the primary data centre has failed and the only thing it 579 00:32:35,720 --> 00:32:38,560 manages is in that data centre, why do I care about recovering 580 00:32:38,560 --> 00:32:40,840 it? So you know, we've had those 581 00:32:40,840 --> 00:32:43,160 conversations. I think it goes, it goes back to 582 00:32:43,160 --> 00:32:46,920 understanding on like you say, what's talking to where, what is 583 00:32:46,920 --> 00:32:49,600 critical versus what's non critical. 584 00:32:50,440 --> 00:32:54,240 Otherwise you can, you know, you can start to be protecting 10 585 00:32:54,240 --> 00:32:56,280 times more than you really need to protect. 586 00:32:56,480 --> 00:32:59,640 And like, you know, if, if you if there's certain things you 587 00:32:59,640 --> 00:33:03,840 want to protect like that, I think you got bigger problems in 588 00:33:03,880 --> 00:33:07,120 your environment than just trying to recover something so 589 00:33:07,120 --> 00:33:09,160 low down in the stack. Yeah, I think it's a valid 590 00:33:09,160 --> 00:33:10,440 point. I've had those conversations 591 00:33:10,440 --> 00:33:13,360 many times in the past where I'm asking the customer the 592 00:33:13,360 --> 00:33:16,400 question, OK, what is it that it actually does and why is it 593 00:33:16,400 --> 00:33:18,560 important? I can understand even why you 594 00:33:18,560 --> 00:33:20,720 would want to replicate it because the cost of replication 595 00:33:20,720 --> 00:33:24,120 may be, you know, fairly low. But do we actually need to fail 596 00:33:24,120 --> 00:33:27,160 over that particular component at this point in time? 597 00:33:27,160 --> 00:33:30,120 Because there's going to be a cost associated with failing it 598 00:33:30,120 --> 00:33:31,680 over. It needs to be powered on. 599 00:33:31,960 --> 00:33:35,200 It's going to claim resources which can't be claimed by other 600 00:33:35,200 --> 00:33:37,400 components. So do we really need it or not? 601 00:33:37,400 --> 00:33:39,560 So I think that is is very valid. 602 00:33:39,560 --> 00:33:44,280 Now, if you look at VCF itself, it's fairly prescriptive and I 603 00:33:44,280 --> 00:33:48,320 know there's a lot of different decisions still to be made. 604 00:33:48,440 --> 00:33:51,040 I mean, we spoke at a bunch of about a bunch of these, right? 605 00:33:51,320 --> 00:33:54,680 Some of the limitations that we have and some of the concerts 606 00:33:55,200 --> 00:33:57,680 that we have. Now when it comes to all of 607 00:33:57,680 --> 00:34:01,560 these design decisions and best practices, where should 608 00:34:01,560 --> 00:34:04,680 customers actually go to or people listening to this episode 609 00:34:04,680 --> 00:34:06,120 if they want to find out more about it? 610 00:34:06,120 --> 00:34:09,040 Because I know your team has written a lot and I know there's 611 00:34:09,040 --> 00:34:11,719 many sessions online, and I'll make sure to Add all of the 612 00:34:11,719 --> 00:34:14,760 links to the show notes so if you have any examples that you 613 00:34:14,760 --> 00:34:17,080 can share, that will be fantastic so people can start 614 00:34:17,080 --> 00:34:18,840 Googling straight away. Yeah. 615 00:34:19,120 --> 00:34:22,080 And so I guess as I mentioned at the beginning, you know, a core 616 00:34:22,080 --> 00:34:25,639 part of what we do is we build this thing called the VCF design 617 00:34:25,639 --> 00:34:28,520 Guide. So that's the thing that I think 618 00:34:28,520 --> 00:34:30,960 customers should go look at first and foremost. 619 00:34:32,360 --> 00:34:37,960 You know, you talk about VCF being prescriptive, I think it's 620 00:34:37,960 --> 00:34:42,199 become more optionality. So it's less prescriptive 621 00:34:42,199 --> 00:34:44,480 ultimately. You know, back in the sort of 622 00:34:44,480 --> 00:34:47,800 the two and three days, it literally, you know, you Click 623 00:34:47,800 --> 00:34:50,480 to go, it did its automation and the thing was built. 624 00:34:51,760 --> 00:34:55,520 You know, one of the things that that has sort of been emphasized 625 00:34:55,520 --> 00:35:00,000 with 9 dot O is that in order to get customers to move us on the 626 00:35:00,000 --> 00:35:03,160 journey to the VCF Private Cloud, we need to meet customers 627 00:35:03,160 --> 00:35:06,760 where they are. So just take vsphere for 628 00:35:06,760 --> 00:35:09,320 example. There are so many configurations 629 00:35:09,320 --> 00:35:13,800 and widgets and dials you can do inside vsphere alone. 630 00:35:14,240 --> 00:35:19,360 So, you know, we've had to sort of expand what we support as a 631 00:35:19,480 --> 00:35:25,000 sort of deployment mechanism. And so really, you know, if we 632 00:35:25,000 --> 00:35:27,640 talk about mentioning validated designs, again, you know, that 633 00:35:27,640 --> 00:35:30,400 was a very prescriptive design. You know, we basically told you 634 00:35:30,400 --> 00:35:32,360 exactly which components to deploy. 635 00:35:32,760 --> 00:35:37,680 We told you exactly how to deploy each component in VCF 9. 636 00:35:38,000 --> 00:35:41,440 You now have choices. You know, at the simplest level, 637 00:35:41,440 --> 00:35:46,600 if you look up VCF operations, which is as we mentioned is like 638 00:35:46,720 --> 00:35:50,360 the central management for the fleet, you can deploy that in 639 00:35:50,360 --> 00:35:52,640 three modes. You can have a single VCF 640 00:35:52,880 --> 00:35:56,680 operations instance, or you can have one that uses multiple 641 00:35:56,680 --> 00:36:00,520 nodes to create an HA in a single site, or you can deploy 642 00:36:00,520 --> 00:36:04,360 it in a continuous availability mode where you actually deploy 643 00:36:04,360 --> 00:36:07,720 it in two separate locations. So optionality has become a big 644 00:36:07,720 --> 00:36:10,080 thing. So we've had to really kind of 645 00:36:10,080 --> 00:36:13,680 rethink our design guide. So we still believe design 646 00:36:13,680 --> 00:36:19,120 decisions are key because that's helped set how each of these 647 00:36:19,120 --> 00:36:22,960 things are deployed in the design guide. 648 00:36:22,960 --> 00:36:25,640 Now we talk about requirements versus recommendations. 649 00:36:25,640 --> 00:36:28,520 So again, in the VVD world, it was everything was a 650 00:36:28,520 --> 00:36:30,040 requirement. This is how you build it. 651 00:36:30,040 --> 00:36:32,320 If you want to be successful, if you want to de risk your 652 00:36:32,320 --> 00:36:35,720 environment and you want the greatest return on investment in 653 00:36:35,720 --> 00:36:40,480 a fast pace, you do what we say. Whereas now what we've had to do 654 00:36:40,480 --> 00:36:42,760 is to take the design decisions and really split them into the, 655 00:36:42,800 --> 00:36:44,920 these are the things that VCF is going to give you as a 656 00:36:44,920 --> 00:36:48,360 requirement and these are the things that we would recommend 657 00:36:48,360 --> 00:36:50,920 you do on top as a best practice. 658 00:36:50,960 --> 00:36:53,800 Doesn't mean you have to, but we're at least giving you a bit 659 00:36:53,800 --> 00:36:55,640 more of a prescriptive way of doing it. 660 00:36:56,720 --> 00:37:00,120 So in that design guide, really it's kind of split into 3 661 00:37:00,120 --> 00:37:03,600 sections. First of all, we have what we 662 00:37:03,600 --> 00:37:06,000 call the architectural options. So this is where I talk about 663 00:37:06,000 --> 00:37:09,200 the optionality. So giving you sort of the 10,000 664 00:37:09,200 --> 00:37:12,680 feet view of, OK, each component that I'm deploying can be 665 00:37:12,680 --> 00:37:15,440 deployed in, you know, 1-2, three or four ways. 666 00:37:15,960 --> 00:37:18,280 What are the benefits and attributes of each? 667 00:37:19,120 --> 00:37:24,680 And that allows you to kind of pick the right model for your 668 00:37:24,680 --> 00:37:26,280 requirements, right, for your needs. 669 00:37:27,600 --> 00:37:29,960 That then flips into the bottom of the document which talks 670 00:37:29,960 --> 00:37:32,840 about the design, detailed design, essentially. 671 00:37:32,840 --> 00:37:36,160 So very similar to the way we used to do VVD, bit more detail 672 00:37:36,160 --> 00:37:40,280 around what your design options are, detail around the design 673 00:37:40,280 --> 00:37:42,240 decisions. But what we also introduced in 674 00:37:42,240 --> 00:37:44,320 that design guide this time around was something called 675 00:37:44,320 --> 00:37:48,240 blueprints. So this again is, is a little 676 00:37:48,240 --> 00:37:52,080 bit back to our roots of a validated design because if 677 00:37:52,080 --> 00:37:55,320 you've now got optionality, you're now elongating the 678 00:37:55,320 --> 00:37:59,800 architecture design process. So what we wanted to do was to 679 00:37:59,800 --> 00:38:02,880 say, you know, from our experience in the last 10-15 680 00:38:02,880 --> 00:38:06,280 years working with a lot of customers, we know that there 681 00:38:06,280 --> 00:38:11,560 are typical deployment models that customers follow, you know, 682 00:38:11,560 --> 00:38:16,560 single site versus multi site versus multi availability zones 683 00:38:16,560 --> 00:38:20,400 across those. So typically 4 core topologies 684 00:38:20,400 --> 00:38:22,640 that most organisations fall into. 685 00:38:24,160 --> 00:38:26,240 Then of course, there's the sort of the minimal footprint. 686 00:38:26,240 --> 00:38:28,080 How do I get this thing up and running like a lab? 687 00:38:28,080 --> 00:38:31,480 So what we decided to do was to build out these blueprints. 688 00:38:31,480 --> 00:38:36,240 So we have 5 blueprints within the zone guide, and each 689 00:38:36,240 --> 00:38:40,680 blueprint has a design profile where we define, from a business 690 00:38:40,680 --> 00:38:42,920 point of view, kind of what we're trying to achieve from 691 00:38:42,920 --> 00:38:46,880 that blueprint. And then each blueprint simply 692 00:38:46,880 --> 00:38:50,560 selects the model of the component that aligns to the 693 00:38:50,560 --> 00:38:53,920 design profile. And all intents and purposes, 694 00:38:53,920 --> 00:38:57,280 all we're trying to do is to say, hey, you're probably going 695 00:38:57,280 --> 00:39:01,080 to align to one of these. You may not be 100% aligned. 696 00:39:01,080 --> 00:39:04,160 In fact, I would argue probably no customer is ever 100% 697 00:39:04,160 --> 00:39:07,040 aligned. But here is a blueprint which at 698 00:39:07,040 --> 00:39:11,040 least gives you the sort of the starter for 10 in terms of your 699 00:39:11,040 --> 00:39:13,400 high level design. And then of course, you would do 700 00:39:13,400 --> 00:39:16,120 your typical architecture design workshops where you'd look at 701 00:39:16,120 --> 00:39:19,320 each component, understand whether you know there's any 702 00:39:19,400 --> 00:39:22,600 adjustments you need. The example I use is like 703 00:39:22,600 --> 00:39:27,840 distributed switches, right? You know, a simple thing like I 704 00:39:27,920 --> 00:39:30,360 think, I think each of our blueprints, we use a single, we 705 00:39:30,360 --> 00:39:32,080 use the single distributive switch model, right? 706 00:39:32,080 --> 00:39:34,560 It's the simplest. It's 2 next happy days. 707 00:39:35,000 --> 00:39:39,720 But let's say you've got an organizational procurement 708 00:39:39,720 --> 00:39:43,400 process that dictates 4 NICs in every single server, right? 709 00:39:43,400 --> 00:39:45,360 Maybe that's your standard and that's, that's fine. 710 00:39:45,720 --> 00:39:48,840 So you can immediately go to the distributed switch section and 711 00:39:48,840 --> 00:39:50,960 go, well, actually we have 4 NICs. 712 00:39:51,040 --> 00:39:53,080 That's what we always buy. That's our standard. 713 00:39:53,360 --> 00:39:57,360 So you can go and swap the model out and pick the model that uses 714 00:39:57,360 --> 00:39:59,040 the four NICs. Now that could be storage 715 00:39:59,040 --> 00:40:03,120 separation because you're using V SAN, or it could be workload 716 00:40:03,240 --> 00:40:06,080 network separation depending on what the requirements are. 717 00:40:06,720 --> 00:40:09,080 So, you know, that's kind of what we've tried to do with with 718 00:40:09,080 --> 00:40:11,120 the design guide. And that's, that's really where 719 00:40:11,120 --> 00:40:13,880 I would tell customers, go look at this, look at the 720 00:40:13,880 --> 00:40:17,280 architectural options, understand your choices, then 721 00:40:17,280 --> 00:40:20,840 look at the blueprint and see which blueprint best matches 722 00:40:20,840 --> 00:40:23,560 what you're trying to deliver. And then take that. 723 00:40:24,400 --> 00:40:26,960 And we do this internally, right with, with our customer 724 00:40:26,960 --> 00:40:28,840 engagements. We take a blueprint or we 725 00:40:28,920 --> 00:40:32,440 understand the customer, understand the the sites, the 726 00:40:32,440 --> 00:40:35,320 the Wan link community limitations, some of the scale 727 00:40:35,320 --> 00:40:39,280 requirements and try to pin a blueprint as the discussion 728 00:40:39,280 --> 00:40:43,000 point and then from there start to dig down into the detail. 729 00:40:44,040 --> 00:40:47,360 Now you've mentioned it a few times and you said customer 730 00:40:47,360 --> 00:40:51,840 engagements. So if I was a customer, how do I 731 00:40:51,840 --> 00:40:55,160 get Gary or someone else from your team like Paulie O'rien on 732 00:40:55,160 --> 00:40:56,680 site, How does that actually work? 733 00:40:56,680 --> 00:40:58,000 I need to ask for those listening. 734 00:40:59,960 --> 00:41:04,360 Yeah. So for our team, it's obviously 735 00:41:04,360 --> 00:41:08,880 an internal Broadcom where we have certain accounts that are, 736 00:41:09,720 --> 00:41:13,400 you know, strategic or maybe there's, you know, opportunities 737 00:41:13,400 --> 00:41:16,000 on the table. So, so we'll, we get involved 738 00:41:16,000 --> 00:41:19,000 very heavily with with those types of customers. 739 00:41:19,240 --> 00:41:23,080 You know, we have a top customer program as you know, most of 740 00:41:23,120 --> 00:41:25,880 well, in fact every one of those top customers has one of my team 741 00:41:26,240 --> 00:41:30,200 aligned with it. But I guess you know, ultimately 742 00:41:30,640 --> 00:41:32,600 there's, there's a big shift towards partners. 743 00:41:33,600 --> 00:41:37,200 Partners are really the, the, the folks now that are going to 744 00:41:37,200 --> 00:41:40,240 be doing, you know, the deployments, a lot of the 745 00:41:40,240 --> 00:41:43,040 architecture designs, you know, we're going to start working 746 00:41:43,040 --> 00:41:46,760 very closely with partners, sharing our knowledge with them 747 00:41:46,760 --> 00:41:50,960 to upskill those people. So I guess to get access to me, 748 00:41:51,600 --> 00:41:54,920 you've got to be lucky, right? You've got to be one of the 749 00:41:54,920 --> 00:41:59,560 right customers on the list. But you know, most of our team 750 00:41:59,560 --> 00:42:04,520 blog, we share information, we do V mug sessions, those kind of 751 00:42:04,520 --> 00:42:05,840 things. So there's always opportunity to 752 00:42:05,840 --> 00:42:08,120 come, you know, and talk to us if if we're at one of those 753 00:42:08,120 --> 00:42:11,240 events, you know, the explores explore on tours. 754 00:42:11,560 --> 00:42:16,320 I'm sure we'll be be on on those shows, those Rd. shows this 755 00:42:16,320 --> 00:42:18,280 year. So yeah. 756 00:42:18,640 --> 00:42:19,800 Yeah. And it makes sense as well to 757 00:42:19,800 --> 00:42:22,120 enable the partners because there's only one Gary, there's 758 00:42:22,120 --> 00:42:25,200 only one party. There are only so many customers 759 00:42:25,200 --> 00:42:26,760 you can meet with. So that makes sense. 760 00:42:27,160 --> 00:42:28,040 Yeah, that's the biggest problem. 761 00:42:28,040 --> 00:42:30,760 It's scale. You know, we really need to make 762 00:42:30,760 --> 00:42:33,320 sure that that we're helping, we're helping the, you know, the 763 00:42:33,320 --> 00:42:36,600 trusted advisors out there that we can, we have access to that 764 00:42:36,600 --> 00:42:39,040 we can help, help them to then help customers. 765 00:42:39,320 --> 00:42:41,920 Yeah, just so people understand, I've mentioned two people, the 766 00:42:41,920 --> 00:42:44,920 two names so far, but of course the the team is much larger than 767 00:42:44,920 --> 00:42:47,160 that. So it's it's not just Porty and 768 00:42:47,160 --> 00:42:49,440 Gary who are part of the team. I'm just mentioning those names 769 00:42:49,440 --> 00:42:52,320 because every once in a while when I get a customer question, 770 00:42:52,640 --> 00:42:55,040 those are the two names that pop up in my head as well. 771 00:42:55,040 --> 00:42:59,160 And I've unfortunately for Pori, I've involved him in in many 772 00:42:59,160 --> 00:43:02,000 very difficult conversations. Whenever he sees a message from 773 00:43:02,000 --> 00:43:04,400 me popping up, he's like, Oh my God, there we go again. 774 00:43:05,080 --> 00:43:09,920 It's another 16 weeks gone. Hey, thanks, Gary, that was 775 00:43:09,920 --> 00:43:11,840 fantastic. Now before I let you go, any 776 00:43:11,840 --> 00:43:14,480 famous last words or any final thoughts you would just like to 777 00:43:14,480 --> 00:43:18,400 share with the audience? So, you know, I guess we've 778 00:43:18,400 --> 00:43:20,800 talked about a lot today, right? We've we've talked about sort of 779 00:43:20,800 --> 00:43:24,600 very high level concepts. You know, what I would say to, 780 00:43:24,600 --> 00:43:28,360 to the customers listening to this is go look at the material, 781 00:43:28,360 --> 00:43:32,200 go understand the architecture. You know, I think there's 782 00:43:32,200 --> 00:43:35,760 probably a lot of V sphere only customers, maybe V sphere with 783 00:43:35,760 --> 00:43:39,000 OPS that they're going to be looking to move to VCF in the 784 00:43:39,000 --> 00:43:42,680 future. So, you know, use the resources 785 00:43:42,680 --> 00:43:47,520 out there, use the design guide. Obviously, you know, if you find 786 00:43:47,520 --> 00:43:50,920 me on LinkedIn, reach out. Happy to, to kind of engage, 787 00:43:52,040 --> 00:43:55,040 work with your trusted advisors, so your partners, maybe you work 788 00:43:55,040 --> 00:43:58,480 directly with Broadcom, your account teams ask the right 789 00:43:58,480 --> 00:44:01,360 questions. And obviously use the community. 790 00:44:01,360 --> 00:44:04,840 You know, the VMO community is, you know, invaluable when it 791 00:44:04,840 --> 00:44:07,240 comes to sharing information. There's a lot of great blogs out 792 00:44:07,240 --> 00:44:09,960 there. As I mentioned, you know, I do 793 00:44:09,960 --> 00:44:14,680 blog when I find time. Most of my team have blogs, you 794 00:44:14,680 --> 00:44:17,320 know, just just sort of, you know, chat amongst yourselves. 795 00:44:17,320 --> 00:44:19,200 You know, it's amazing. Mainly what you couldn't learn 796 00:44:19,200 --> 00:44:23,680 from each other and that I think the V MO community certainly 797 00:44:23,680 --> 00:44:28,600 instills that that confidence and and sharing between between 798 00:44:28,600 --> 00:44:30,280 learnings. Fantastic. 799 00:44:30,280 --> 00:44:33,320 Well, if there's anything new popping up in the VCF space, 800 00:44:33,320 --> 00:44:35,320 I'll make sure to invite you again, Gary, Thank you. 801 00:44:35,600 --> 00:44:36,560 Thank you. Thanks, Duncan. 802 00:44:36,600 --> 00:44:38,240 And that's it. Thanks for tuning into the 803 00:44:38,240 --> 00:44:41,080 Unexplored Territory podcast. If you enjoyed this episode, 804 00:44:41,280 --> 00:44:43,400 don't forget to subscribe and leave a reviewer rating wherever 805 00:44:43,400 --> 00:44:45,200 possible. And please join us again next 806 00:44:45,200 --> 00:44:47,640 time as we cover more insights into cutting edge solutions 807 00:44:47,640 --> 00:44:50,680 shaping the world of IT. Until then, staying comfortable, 808 00:44:50,880 --> 00:44:51,120 keep it.