Episode 378 – Azure Compute Fleet

June 06, 2024

Episode Transcript

Welcome to Episode 378 of the Microsoft Cloud IT Pro Podcast. In this episode we discuss Azure Compute Fleet, a new Preview service announced at Microsoft Build 2024. Azure Compute Fleet is a new Azure infrastructure service that lets you deploy Azure compute capacity across different virtual machine SKUs, availability zones, and pricing models. It’s all about acquiring VM capacity at scale. If you’re familiar with AWS EC2 and Spot fleet, this is effectively the equivalent in Azure.

Like what you hear and want to support the show? Check out our membership options.

Show Notes

About the sponsors

Would you like to become the irreplaceable Microsoft 365 resource for your organization? Let us know!

See full episode transcriptTranscript is autogenerated by AI

1 00:00:03,617 --> 00:00:05,923 Welcome to episode 378 2 00:00:05,923 --> 00:00:09,421 of the Microsoft cloud It pro podcast recorded 3 00:00:09,421 --> 00:00:11,835 live. On 05/31/2024. 4 00:00:12,155 --> 00:00:14,554 This is a show about Microsoft 3 65 5 00:00:14,554 --> 00:00:16,714 in Azure from the perspective of It pros 6 00:00:16,714 --> 00:00:19,114 and end users where we discuss a topic 7 00:00:19,114 --> 00:00:21,364 or news and how it relates to you. 8 00:00:21,922 --> 00:00:24,315 Today, we're diving into a new preview feature 9 00:00:24,315 --> 00:00:26,628 that was recently announced at Microsoft build, 10 00:00:27,266 --> 00:00:28,303 Microsoft compute. 11 00:00:28,782 --> 00:00:31,104 Scott and Ben dive into what exactly the 12 00:00:31,104 --> 00:00:33,648 services is and some of the intricacies of 13 00:00:33,648 --> 00:00:36,907 what it entails. They also discuss what a 14 00:00:36,907 --> 00:00:40,028 deployment involves and what some of the possible 15 00:00:40,028 --> 00:00:42,426 use cases they see of the service based 16 00:00:42,426 --> 00:00:44,664 on the features implemented within the preview. 17 00:00:46,981 --> 00:00:48,580 You wanna get in a smash or adventures 18 00:00:48,580 --> 00:00:52,732 today? Yes. Like fleets, Azure fleets, boat fleets, 19 00:00:53,448 --> 00:00:54,164 helicopter fleets. 20 00:00:54,801 --> 00:00:58,321 Compute fleets of what? Azure compute fleets, fleets 21 00:00:58,321 --> 00:00:58,821 of 22 00:00:59,278 --> 00:01:01,749 computers. Yeah. III figured it's been a hot 23 00:01:01,749 --> 00:01:04,242 minute since we talked about Smash stuff and 24 00:01:04,792 --> 00:01:06,141 it's only fair that we get back to 25 00:01:06,141 --> 00:01:08,681 it. And this is a new preview feature 26 00:01:08,681 --> 00:01:11,697 that came out or was announced in the 27 00:01:11,697 --> 00:01:13,855 build time frame. What was that? Week ago, 28 00:01:14,014 --> 00:01:15,918 2 weeks ago. Something like that. I don't 29 00:01:15,918 --> 00:01:17,425 know. Time has no meeting to me anymore. 30 00:01:17,663 --> 00:01:19,091 Could've have been, like, a month ago. 31 00:01:20,360 --> 00:01:22,775 A But it recently at Microsoft built. Yeah. 32 00:01:23,254 --> 00:01:25,034 May 20 24 33 00:01:25,334 --> 00:01:28,248 is when this 1 publicly came out. And 34 00:01:28,862 --> 00:01:32,542 landed in public preview. So I figured between 35 00:01:33,315 --> 00:01:33,871 virtual machines, 36 00:01:34,985 --> 00:01:37,291 virtual machine scale sets or Vms s, 37 00:01:38,104 --> 00:01:39,625 virtual machines scale sets, 38 00:01:40,265 --> 00:01:43,224 flex or Vms s Flex, which we've talked 39 00:01:43,224 --> 00:01:45,398 about in the past. And now compute fleet. 40 00:01:45,557 --> 00:01:49,451 We've got yet another perm mutation for at 41 00:01:49,451 --> 00:01:51,223 scale deployment of 42 00:01:51,835 --> 00:01:53,835 virtual machines. And I think this 1 is 43 00:01:53,835 --> 00:01:56,715 kind of interesting when it comes to the 44 00:01:57,008 --> 00:01:59,840 quote unquote scale aspect of it because it 45 00:02:00,038 --> 00:02:02,101 goes a little bit above and beyond what 46 00:02:02,101 --> 00:02:04,164 things like Vms do today, 47 00:02:04,878 --> 00:02:07,337 just with the units of compute that can 48 00:02:07,337 --> 00:02:09,659 be deployed, like, if you're thinking, like individual 49 00:02:09,818 --> 00:02:10,535 Vm counts, 50 00:02:11,093 --> 00:02:13,324 things like that. So real quick just to 51 00:02:13,324 --> 00:02:17,387 kinda ground everybody. So compute, like I said 52 00:02:17,387 --> 00:02:20,453 is this new thing. It's effectively a new 53 00:02:20,909 --> 00:02:21,808 infrastructure service 54 00:02:22,344 --> 00:02:26,092 within Azure around compute. And it's meant to 55 00:02:26,092 --> 00:02:26,705 kinda just 56 00:02:27,221 --> 00:02:30,902 streamline end to end that whole provisioning and 57 00:02:30,959 --> 00:02:32,016 management aspect 58 00:02:32,390 --> 00:02:34,879 of provisioning compute... Compute capacity 59 00:02:35,349 --> 00:02:36,867 across a whole bunch of different Vm types, 60 00:02:37,347 --> 00:02:38,545 potentially at the same time, 61 00:02:39,264 --> 00:02:41,901 availability zones, kinda of mix and match to 62 00:02:41,901 --> 00:02:43,020 your pricing model. 63 00:02:43,594 --> 00:02:46,335 Also that you can get to Vm deployments 64 00:02:46,395 --> 00:02:49,534 at scale that are performance because 65 00:02:49,835 --> 00:02:51,675 let's be honest, it's a little bit hard 66 00:02:51,675 --> 00:02:54,875 to do like multi vm deployments today, especially 67 00:02:54,875 --> 00:02:56,705 if you're doing, like, a scripted deployment or 68 00:02:56,705 --> 00:02:59,012 something, say with, like, powershell and just en, 69 00:02:59,171 --> 00:03:00,859 like, Hey. I'm gonna spin up a Vm, 70 00:03:00,938 --> 00:03:02,133 and then I'm gonna wait, and I'm gonna 71 00:03:02,133 --> 00:03:03,408 spin up another Vm, and I'm gonna spin 72 00:03:03,408 --> 00:03:05,400 up another Vm. It's a lot of Api 73 00:03:05,400 --> 00:03:08,269 calls. It's a lot of potential polling operations, 74 00:03:08,508 --> 00:03:10,358 things like that. So the cool thing about 75 00:03:10,358 --> 00:03:12,755 this is we need to kinda talk about 76 00:03:12,755 --> 00:03:14,054 it as, like, a 77 00:03:14,753 --> 00:03:17,070 infrastructure service or an infrastructure component. 78 00:03:17,724 --> 00:03:21,025 It's a single Api call to 79 00:03:21,485 --> 00:03:25,745 do an Azure compute fleet deployment, which is 80 00:03:26,696 --> 00:03:29,470 really kind of a cool thing, especially when 81 00:03:29,470 --> 00:03:31,372 you think about the scale of it. So 82 00:03:31,372 --> 00:03:33,433 you can deploy up to 10000 vms, 83 00:03:34,083 --> 00:03:36,412 in a single call through 84 00:03:36,786 --> 00:03:37,264 compute fleet. 85 00:03:38,059 --> 00:03:39,808 You've got a bunch of different settings in 86 00:03:39,808 --> 00:03:43,091 there where you can prioritize things like deployment 87 00:03:43,148 --> 00:03:43,387 speed, 88 00:03:43,958 --> 00:03:44,936 you could prioritize 89 00:03:45,390 --> 00:03:48,197 operational costs, say, like spot compute versus 90 00:03:48,731 --> 00:03:50,322 regular, pay go, compute, 91 00:03:50,974 --> 00:03:52,647 you can kinda have a mix and match 92 00:03:52,647 --> 00:03:56,254 model, potentially balance both those dimensions together 93 00:03:56,631 --> 00:03:59,180 because you're deploying different units of compute and 94 00:03:59,180 --> 00:04:01,909 those different units of compute the Skews underlying 95 00:04:01,990 --> 00:04:04,949 Skus and compute. They all have different costs 96 00:04:04,949 --> 00:04:06,870 associated with them. You've also got to, kinda 97 00:04:06,870 --> 00:04:08,069 cost management aspects. 98 00:04:08,723 --> 00:04:10,469 And being able to mix and match pricing 99 00:04:10,469 --> 00:04:14,438 models in a wide swath single Api call 100 00:04:14,438 --> 00:04:14,835 deployment. 101 00:04:16,581 --> 00:04:17,137 What else Oh? 102 00:04:17,870 --> 00:04:20,829 You can also... Because you're deploying potentially so 103 00:04:20,829 --> 00:04:23,629 many virtual machines at a time. Like, but 104 00:04:23,629 --> 00:04:26,430 deploying 10000 Vms at once isn't necessarily a 105 00:04:26,430 --> 00:04:28,700 small ask. When it comes to things like 106 00:04:28,917 --> 00:04:31,706 quotas, availability of that compute in a region, 107 00:04:32,105 --> 00:04:33,481 anything along that 108 00:04:33,858 --> 00:04:36,026 dimension as well. So it's kinda nice from 109 00:04:36,026 --> 00:04:37,781 the fire in forget aspect to say, hey, 110 00:04:38,179 --> 00:04:40,572 fire off an Api call and kinda load 111 00:04:40,572 --> 00:04:43,364 me up based on what my quota is 112 00:04:43,364 --> 00:04:46,638 for my subscription. A given region things like 113 00:04:46,638 --> 00:04:49,571 that along the way. So it looks like 114 00:04:49,571 --> 00:04:52,837 a kind of fun nifty new feature. It 115 00:04:52,837 --> 00:04:55,693 is definitely not an f for everybody feature, 116 00:04:55,851 --> 00:04:58,470 I think, given the scale aspect of it. 117 00:04:58,946 --> 00:05:00,533 I don't know that many people are looking 118 00:05:00,533 --> 00:05:02,079 to deploy deploy 10000 119 00:05:02,928 --> 00:05:05,151 vms at once, at least not broadly. 120 00:05:05,786 --> 00:05:09,555 But there's definitely customers out there that would 121 00:05:09,611 --> 00:05:11,461 love to deploy 10000 122 00:05:11,993 --> 00:05:14,716 and frankly, more than 10000 virtual machines 123 00:05:15,249 --> 00:05:17,472 at a given and go to get through 124 00:05:17,472 --> 00:05:18,762 some of the stuff. So you think about, 125 00:05:18,841 --> 00:05:22,931 like, customers with a large Ai training workload 126 00:05:22,989 --> 00:05:24,824 kind of thing. That's a ton of compute, 127 00:05:25,063 --> 00:05:27,456 ton jeep can be fairly ep. 128 00:05:28,028 --> 00:05:29,381 So, you know, you might not wanna run 129 00:05:29,381 --> 00:05:30,813 the thing the whole time. But, like, yeah, 130 00:05:30,972 --> 00:05:32,801 Definitely, while we're training a model, we need 131 00:05:32,801 --> 00:05:34,949 to get that. Those units have compute up 132 00:05:34,949 --> 00:05:37,351 and running and those Vms configured all those 133 00:05:37,351 --> 00:05:40,453 kinds of things along the way. So looks 134 00:05:40,453 --> 00:05:42,601 like a fun 1. Yeah. This was interesting 135 00:05:42,601 --> 00:05:44,125 and you first brought it up me We're 136 00:05:44,125 --> 00:05:45,869 like, hey, ben. Go check this 1 out 137 00:05:45,869 --> 00:05:46,369 because 138 00:05:47,216 --> 00:05:49,198 can't remember. It was a couple months ago. 139 00:05:49,356 --> 00:05:51,753 We were talking about Av. And I was 140 00:05:51,753 --> 00:05:54,624 creating some maybe the environments where we were 141 00:05:54,624 --> 00:05:56,639 actually, like, destroying and 142 00:05:57,256 --> 00:06:00,048 rebuilding or tearing down and recreating Vms on 143 00:06:00,048 --> 00:06:00,925 a nightly basis, 144 00:06:01,339 --> 00:06:02,612 and we were only doing... 145 00:06:03,010 --> 00:06:04,443 I mean, we're only doing like, 30 or 146 00:06:04,443 --> 00:06:05,080 40 Vms. 147 00:06:05,557 --> 00:06:07,309 But we were running into issues where when 148 00:06:07,309 --> 00:06:08,741 we did all 30 of them at once. 149 00:06:09,234 --> 00:06:10,671 Again, it was a bunch of single Api 150 00:06:10,671 --> 00:06:12,028 calls. Not all of them are coming back 151 00:06:12,028 --> 00:06:13,704 up. We split it up into 5 or 152 00:06:13,704 --> 00:06:16,099 05:10 vms at once. And it worked better. 153 00:06:16,258 --> 00:06:17,296 And you're were like, hey Ben, now you 154 00:06:17,296 --> 00:06:19,068 can do complete. Compete and do, like, 155 00:06:19,788 --> 00:06:22,265 do compute fleet and do, like, a whole 156 00:06:22,265 --> 00:06:24,183 bunch from that once. And it led to 157 00:06:24,183 --> 00:06:26,340 a little bit of like that use case 158 00:06:26,340 --> 00:06:26,840 where 159 00:06:27,235 --> 00:06:29,875 this is very much, like, when you stand 160 00:06:29,875 --> 00:06:31,875 up a compute fleet, go to play a 161 00:06:31,875 --> 00:06:34,034 bunch of them, but then you have to 162 00:06:34,034 --> 00:06:34,534 continue 163 00:06:35,074 --> 00:06:37,161 managing it through the fleet. And that was 164 00:06:37,161 --> 00:06:39,070 1 thing I was curious about when you 165 00:06:39,070 --> 00:06:40,104 told me to go check it out is 166 00:06:40,104 --> 00:06:42,093 it's like, can I use a fleet to 167 00:06:42,093 --> 00:06:45,610 go deploy 30 vms? And then like, in 168 00:06:45,610 --> 00:06:47,205 the case of Av, if I wanna scale 169 00:06:47,205 --> 00:06:48,480 up or scale down, 170 00:06:49,118 --> 00:06:51,749 how does that look within a compute fleet? 171 00:06:51,988 --> 00:06:54,312 Like, can I go? Turn Vms off or 172 00:06:54,312 --> 00:06:55,608 delete them or 173 00:06:55,983 --> 00:06:58,371 how do I manage these museums once it's 174 00:06:58,371 --> 00:06:59,428 the fleet. And 175 00:06:59,803 --> 00:07:01,395 this is not really for that use case. 176 00:07:01,554 --> 00:07:03,504 Like you said, this is I'm gonna go 177 00:07:03,805 --> 00:07:05,564 deploy a bunch of Vms, but then you 178 00:07:05,564 --> 00:07:06,625 continue to manage 179 00:07:07,164 --> 00:07:08,305 that capacity 180 00:07:08,764 --> 00:07:10,064 of Vms 181 00:07:10,617 --> 00:07:13,080 within the fleet, and it's not something that 182 00:07:13,080 --> 00:07:13,977 you could easily... 183 00:07:14,509 --> 00:07:15,621 I would say it's not something you can 184 00:07:15,621 --> 00:07:17,686 easily scale. It's like what you said. We 185 00:07:17,686 --> 00:07:19,513 wanna go spin up 10000 vms. We're gonna 186 00:07:19,513 --> 00:07:22,392 go spin 5000 vms for a workload and 187 00:07:22,392 --> 00:07:24,541 we were even talking probably more of like 188 00:07:24,541 --> 00:07:26,611 an a a ep type workload where it's... 189 00:07:27,089 --> 00:07:29,251 We're gonna go train something for a week 190 00:07:29,251 --> 00:07:32,192 or train something for a month or... 191 00:07:32,668 --> 00:07:34,576 I mean, certain industries have certain times a 192 00:07:34,576 --> 00:07:36,101 year where it's busy and they're spinning up 193 00:07:36,101 --> 00:07:39,124 a huge number of Vms. Think of shopping 194 00:07:39,124 --> 00:07:41,590 sites over the month of November and December 195 00:07:41,590 --> 00:07:44,055 where... Mh. They need a massively scale up. 196 00:07:44,309 --> 00:07:46,694 For a short period of time, and then 197 00:07:46,694 --> 00:07:48,522 they scale back down or they just frankly, 198 00:07:48,601 --> 00:07:50,827 like blow them away. It's like, we hit 199 00:07:50,827 --> 00:07:51,804 the middle of January, 200 00:07:52,433 --> 00:07:55,142 nobody's shopping anymore because everybody spends their Christmas 201 00:07:55,142 --> 00:07:57,293 money and has done shopping. Let's just delete 202 00:07:57,293 --> 00:08:00,024 everything. Like, this is very much 203 00:08:00,480 --> 00:08:02,088 spin up a bunch of Vms for a 204 00:08:02,088 --> 00:08:04,481 short period of time and then get rid 205 00:08:04,481 --> 00:08:07,034 of them all. Is kinda how I interpret 206 00:08:07,034 --> 00:08:10,485 this. It's the Nuance potentially of that statement 207 00:08:10,782 --> 00:08:11,282 of 208 00:08:12,072 --> 00:08:14,379 compute fleet is kind of like an infrastructure 209 00:08:14,379 --> 00:08:14,879 service 210 00:08:15,412 --> 00:08:15,912 versus 211 00:08:16,526 --> 00:08:17,582 a holistic 212 00:08:18,673 --> 00:08:19,786 compute management service. 213 00:08:20,278 --> 00:08:22,343 Right? So I think about things maybe, like, 214 00:08:22,502 --> 00:08:23,002 the 215 00:08:23,376 --> 00:08:26,632 Vms s or Vms Flex as being a 216 00:08:26,632 --> 00:08:28,950 little bit more feature rich there. Like, 1 217 00:08:28,950 --> 00:08:31,568 of the things with compute fleet, at least 218 00:08:31,727 --> 00:08:32,838 I haven't seen a way to do it. 219 00:08:33,076 --> 00:08:34,052 It's not documented 220 00:08:34,583 --> 00:08:37,148 nor, like, that I see, like, an easy 221 00:08:37,148 --> 00:08:38,746 way to do it through the Api surface 222 00:08:38,746 --> 00:08:40,264 or the portal or anything like that. But, 223 00:08:40,344 --> 00:08:42,202 like, 1 of the big differences is is 224 00:08:42,342 --> 00:08:43,940 when you deploy a compute, 225 00:08:44,514 --> 00:08:45,014 you're 226 00:08:45,553 --> 00:08:49,309 deploying compute, you're not necessarily configuring that compute. 227 00:08:49,789 --> 00:08:51,707 So when I think about, like, a traditional 228 00:08:51,707 --> 00:08:54,276 single Vm deployment or, like, a Vms fast 229 00:08:54,276 --> 00:08:57,000 deployment things like that. It's not just about 230 00:08:57,215 --> 00:09:00,551 deploying the compute. It's also about configuring and 231 00:09:00,551 --> 00:09:03,433 managing that compute throughout its life cycle. So 232 00:09:03,663 --> 00:09:05,571 I don't know. Maybe I'm standing up, like 233 00:09:05,571 --> 00:09:09,228 that, you know, traditional multi tier web application 234 00:09:09,228 --> 00:09:10,897 thing where, you know, I've got a front 235 00:09:10,897 --> 00:09:12,646 end, some middle wear and a back end. 236 00:09:13,139 --> 00:09:15,128 I might do that in S flex, and 237 00:09:15,128 --> 00:09:16,743 then within my deployment 238 00:09:17,277 --> 00:09:20,461 configuration, I would say, hey for this Ubuntu 239 00:09:20,461 --> 00:09:22,610 based front end deploy Ng x on it. 240 00:09:22,944 --> 00:09:26,081 And load these Ssl cert and do this 241 00:09:26,380 --> 00:09:27,658 configuration for Ng x. 242 00:09:28,537 --> 00:09:30,889 My middle aware, do this kinda 243 00:09:31,267 --> 00:09:35,334 configuration for my Api hosting on my data 244 00:09:35,334 --> 00:09:36,712 side, like, with my 245 00:09:37,089 --> 00:09:39,003 sql server. Like, Sam doing, like, my sequel 246 00:09:39,003 --> 00:09:41,254 or something like that. Well, go ahead and 247 00:09:41,254 --> 00:09:43,414 actually spin up my sequel install it on 248 00:09:43,414 --> 00:09:45,575 the box for me or even deploy that 249 00:09:45,575 --> 00:09:47,095 as a bad service like whatever it happens 250 00:09:47,095 --> 00:09:50,087 to be. And you don't have that same 251 00:09:50,146 --> 00:09:51,904 flexibility within compute. 252 00:09:52,463 --> 00:09:55,273 Compute is literally, like, fire and forget I 253 00:09:55,273 --> 00:09:58,060 want to create just a ton of virtual 254 00:09:58,060 --> 00:10:00,608 machines at the same time. I'm gonna have, 255 00:10:00,688 --> 00:10:02,382 like, min and Max targets 256 00:10:02,838 --> 00:10:03,338 for 257 00:10:03,808 --> 00:10:06,595 how much I want to deploy. And and 258 00:10:06,595 --> 00:10:08,824 of what type I want to deploy. But 259 00:10:08,824 --> 00:10:11,053 then once it's deployed, it's up to you 260 00:10:11,053 --> 00:10:14,264 to go and stand up your applications, 261 00:10:14,665 --> 00:10:17,565 do all that kind of management 262 00:10:17,945 --> 00:10:20,424 on top of it. So it's kinda nice 263 00:10:20,424 --> 00:10:23,064 in that it's got a single Api, fire 264 00:10:23,064 --> 00:10:25,604 and forget for the at scale deployment piece. 265 00:10:26,239 --> 00:10:27,827 It'd be interesting to see where this goes 266 00:10:27,827 --> 00:10:29,335 in the future, like, if they bring in, 267 00:10:29,494 --> 00:10:32,522 like, at scale management as well. Like, I 268 00:10:32,522 --> 00:10:34,188 would love to have a way. And if 269 00:10:34,188 --> 00:10:35,932 it's possible today, maybe the docs just need 270 00:10:35,932 --> 00:10:37,518 to be updated. I would love to have 271 00:10:37,518 --> 00:10:39,442 a weighted to say, like, go in and 272 00:10:39,442 --> 00:10:41,909 create an arm template to do a compute 273 00:10:41,909 --> 00:10:44,456 fleet deployment. And then within that fleet, as 274 00:10:44,615 --> 00:10:46,605 I'm defining my Vm skus, and I'm saying, 275 00:10:46,765 --> 00:10:48,851 okay, you know, I want 10 of this 276 00:10:48,851 --> 00:10:50,367 spot, up to a hundred of this spot. 277 00:10:50,606 --> 00:10:52,999 I want 10 of these, you know, ds 278 00:10:52,999 --> 00:10:54,057 s 96, 279 00:10:54,754 --> 00:10:56,907 up to, you know, 50 of them, whatever 280 00:10:56,907 --> 00:10:59,070 happens to be. Like, in that same arm 281 00:10:59,070 --> 00:11:02,405 template, having, like, further child properties that I 282 00:11:02,405 --> 00:11:04,072 can call out to so that I can 283 00:11:04,072 --> 00:11:07,514 do things, like, execute boot automations, so maybe, 284 00:11:07,595 --> 00:11:09,434 like, cloud in it scripts, things like that 285 00:11:09,434 --> 00:11:10,495 on a Linux box 286 00:11:10,954 --> 00:11:13,649 just to get them up and running. But 287 00:11:13,849 --> 00:11:17,204 that stuff's kind of not there today. 288 00:11:17,844 --> 00:11:19,921 The other thing is it's a little bit 289 00:11:19,921 --> 00:11:22,481 different and I do think of as maybe 290 00:11:22,481 --> 00:11:24,070 a little bit more of an ep thing. 291 00:11:24,705 --> 00:11:27,985 So when you fire off a request to 292 00:11:28,438 --> 00:11:30,185 instant initiate a compute fleet. So you go 293 00:11:30,185 --> 00:11:32,273 in fire off this Api surface. And again 294 00:11:32,273 --> 00:11:34,027 you do that through arm template. You do 295 00:11:34,027 --> 00:11:35,223 it through the portal. You do it through 296 00:11:35,223 --> 00:11:36,897 the Arm Apis. Like, however you do it? 297 00:11:37,216 --> 00:11:38,651 You fire off that request. 298 00:11:39,462 --> 00:11:42,800 That request can take... It's effectively asynchronous compute 299 00:11:42,800 --> 00:11:44,549 deployment at that point, like, it all happens 300 00:11:44,549 --> 00:11:46,536 in the background it just churn and churn 301 00:11:46,536 --> 00:11:47,092 and churn. 302 00:11:47,649 --> 00:11:50,281 These are, like, super long running jobs. 303 00:11:51,311 --> 00:11:53,846 So, like, an initial compute fleet request can 304 00:11:53,846 --> 00:11:55,193 be active for up to a year. 305 00:11:55,845 --> 00:11:57,524 365 306 00:11:57,524 --> 00:11:57,845 days. 307 00:11:58,565 --> 00:12:00,965 If you need to clear a request, like, 308 00:12:01,125 --> 00:12:02,725 hey I I did the fire and forget 309 00:12:02,725 --> 00:12:04,245 saying of that Api, and now there's a 310 00:12:04,245 --> 00:12:06,015 bunch of async stuff happening in the background. 311 00:12:06,493 --> 00:12:08,644 Your only option is, like, you can't really, 312 00:12:08,724 --> 00:12:11,433 like, pause it. You can just delete the 313 00:12:11,433 --> 00:12:13,518 compute fleet request. And if you do that, 314 00:12:13,756 --> 00:12:16,460 all the Vms inside that compute fleet come 315 00:12:16,460 --> 00:12:17,652 down at the same time. 316 00:12:18,368 --> 00:12:20,276 So, yeah. I... It's a little bit weird. 317 00:12:20,769 --> 00:12:22,601 In that it doesn't have parity with things 318 00:12:22,601 --> 00:12:22,761 like, 319 00:12:24,514 --> 00:12:27,005 Flex. It's its own new 320 00:12:27,701 --> 00:12:28,201 weird 321 00:12:28,577 --> 00:12:30,091 thing. Like, whether you wanna think about it 322 00:12:30,091 --> 00:12:30,465 as 323 00:12:30,982 --> 00:12:33,369 potentially, like, a new Api surface, like, as 324 00:12:33,369 --> 00:12:34,721 a new infrastructure service, 325 00:12:35,278 --> 00:12:37,903 built on top of existing constructs like virtual 326 00:12:37,903 --> 00:12:39,097 machines, things like that. 327 00:12:39,750 --> 00:12:43,209 The public docs refer to it as a 328 00:12:43,269 --> 00:12:45,990 building block. So it's just kinda like this 329 00:12:45,990 --> 00:12:48,882 foundational little block or, like Lego brick. That's 330 00:12:48,882 --> 00:12:49,701 going to 331 00:12:50,078 --> 00:12:51,375 accelerate your 332 00:12:51,912 --> 00:12:54,463 access to compute capacity in a region. So 333 00:12:54,463 --> 00:12:55,819 if you think about it that way, like, 334 00:12:55,978 --> 00:12:57,149 hey, I just need to 335 00:12:57,665 --> 00:12:59,965 secure a bunch of compute. Really good for 336 00:12:59,965 --> 00:13:02,344 that. I need to secure a bunch of 337 00:13:02,344 --> 00:13:04,168 compute, and I need to configure it, and 338 00:13:04,247 --> 00:13:05,095 I need all this post 339 00:13:05,693 --> 00:13:07,447 configuration. I need down level management and all 340 00:13:07,447 --> 00:13:09,840 this other stuff. I don't know. It might 341 00:13:09,840 --> 00:13:11,834 not be the best thing for that, but 342 00:13:11,834 --> 00:13:13,987 it's not, like Vms or those other things 343 00:13:13,987 --> 00:13:16,174 are going away. You might have to kinda 344 00:13:16,389 --> 00:13:19,092 mix and match to or it just very 345 00:13:19,092 --> 00:13:21,556 well could not be the right thing for 346 00:13:21,556 --> 00:13:23,643 you along the way. I'm curious, and I 347 00:13:23,643 --> 00:13:24,841 don't know that you have an answer because 348 00:13:24,841 --> 00:13:26,839 we talked about this a little bit, and 349 00:13:26,839 --> 00:13:29,076 this is in the Faq. The 365 350 00:13:29,076 --> 00:13:30,850 day thing you brought up. Is if you 351 00:13:30,850 --> 00:13:33,250 go in and look at the Faqs for 352 00:13:33,250 --> 00:13:35,090 compute fleet. It says how long does my 353 00:13:35,090 --> 00:13:38,062 compute fleet request active, compute fleet requests are 354 00:13:38,062 --> 00:13:39,732 active for 365 355 00:13:39,732 --> 00:13:42,038 days. If you delete it, it deletes all 356 00:13:42,038 --> 00:13:42,697 the Vms. 357 00:13:43,231 --> 00:13:45,616 If I don't delete it, it continues the 358 00:13:45,696 --> 00:13:47,938 Vms continue to run and charge you. Does 359 00:13:47,938 --> 00:13:49,633 this mean that if I request 360 00:13:50,089 --> 00:13:52,001 or maybe I already know what you're gonna 361 00:13:52,001 --> 00:13:54,684 answer. I'm curious how this plays out is 362 00:13:54,964 --> 00:13:57,356 could it actually take 365 363 00:13:57,356 --> 00:14:01,424 days to provision all 10000 vms? Or does 364 00:14:01,424 --> 00:14:03,578 this mean that, like, you put in a 365 00:14:03,578 --> 00:14:04,078 request 366 00:14:04,789 --> 00:14:07,177 And within that request, you're setting, I need 367 00:14:07,177 --> 00:14:08,371 certain amounts of Vms, 368 00:14:08,928 --> 00:14:11,395 and you can go in and update your 369 00:14:11,395 --> 00:14:13,465 fleet, I believe to change that number of 370 00:14:13,544 --> 00:14:14,044 Vms, 371 00:14:14,673 --> 00:14:16,099 Like, do you only have a year to 372 00:14:16,099 --> 00:14:18,239 change it and after a year, a complete 373 00:14:18,239 --> 00:14:20,062 fleet or a compute fleet is like. 374 00:14:20,696 --> 00:14:23,732 Stock or locked, I'm I can't imagine anybody 375 00:14:23,732 --> 00:14:25,882 would wanna spin up 10000 vms and not 376 00:14:25,882 --> 00:14:28,113 know if it's gonna complete in a week 377 00:14:28,113 --> 00:14:29,228 in a year. 378 00:14:29,785 --> 00:14:30,843 Like, the whole 379 00:14:31,473 --> 00:14:33,967 what is our active request 380 00:14:34,504 --> 00:14:34,744 mean? 381 00:14:36,339 --> 00:14:38,811 Don't know. Right? Like, I I... So a 382 00:14:38,811 --> 00:14:40,646 couple of things. So it's in preview. 383 00:14:41,379 --> 00:14:42,899 I I think you've gotta kinda look at 384 00:14:42,899 --> 00:14:45,539 it from that lens of, hey, it's all 385 00:14:45,539 --> 00:14:47,480 not gonna be there, and I think as 386 00:14:47,620 --> 00:14:50,100 questions or answer or, like, as questions or 387 00:14:50,100 --> 00:14:50,394 asked 388 00:14:50,913 --> 00:14:52,986 those will get added and and build some 389 00:14:52,986 --> 00:14:55,937 of that out over time. You know, do 390 00:14:55,937 --> 00:14:58,887 you wanna wait a year to deploy your 391 00:14:58,887 --> 00:15:01,530 10000 Vms? No, Probably not, but that's why 392 00:15:01,530 --> 00:15:03,758 you're gonna have men's and max. Like, so 393 00:15:03,758 --> 00:15:04,873 you had the portal up earlier. 394 00:15:05,509 --> 00:15:07,101 I was gonna say we should walk through 395 00:15:07,101 --> 00:15:09,342 that and just talked through what a deployment 396 00:15:09,342 --> 00:15:10,931 looks like. Yeah. I think that gives you 397 00:15:10,931 --> 00:15:12,600 a little bit of kind of a a 398 00:15:12,600 --> 00:15:13,816 view into 399 00:15:14,667 --> 00:15:18,602 that. World and what some of the dimensions 400 00:15:18,818 --> 00:15:20,727 are that you're looking at. So, like, any 401 00:15:20,727 --> 00:15:21,841 other arm deployment. Right? 402 00:15:22,654 --> 00:15:22,974 Subscription, 403 00:15:23,533 --> 00:15:25,930 resource groups, that's pretty easy. You're gonna have 404 00:15:25,930 --> 00:15:26,889 a resource name, 405 00:15:27,688 --> 00:15:30,586 your fleet name, what region are you deploying 406 00:15:30,645 --> 00:15:33,139 into which this is limited right now in 407 00:15:33,139 --> 00:15:35,379 preview. It's East. East Us 2 west 2 408 00:15:35,379 --> 00:15:37,299 west 2 and West Us. So really East 409 00:15:37,299 --> 00:15:40,114 and West, the original and 2 are the 410 00:15:40,114 --> 00:15:42,351 only 4 options at this point in time. 411 00:15:42,751 --> 00:15:45,866 Effectively some Us hero regions in Azure. Yeah. 412 00:15:46,106 --> 00:15:47,245 So you've got that 413 00:15:47,638 --> 00:15:49,411 availability zones is 414 00:15:49,865 --> 00:15:50,365 your 415 00:15:50,740 --> 00:15:52,274 next 1. So 416 00:15:52,888 --> 00:15:54,653 do you wanna use Az z's for your 417 00:15:54,733 --> 00:15:56,642 Vm as to deploy and then just like 418 00:15:56,642 --> 00:15:59,030 a regular Vm, you know, zone 1, zone 419 00:15:59,030 --> 00:15:59,268 2, 420 00:16:00,144 --> 00:16:01,496 zone 3 kind of thing. 421 00:16:02,309 --> 00:16:03,208 What is 422 00:16:03,587 --> 00:16:04,087 your 423 00:16:04,866 --> 00:16:07,423 security type for those virtual machines? So I 424 00:16:07,423 --> 00:16:09,660 think we discussed this a couple episodes back. 425 00:16:10,394 --> 00:16:13,425 Trusted launch Vms or the default everywhere right 426 00:16:13,425 --> 00:16:16,695 now, but you can revert to standard, 427 00:16:17,173 --> 00:16:19,486 or you can do confidential computer on the 428 00:16:19,486 --> 00:16:19,646 way. 429 00:16:20,299 --> 00:16:21,819 Know, trusted launch are the ones that give 430 00:16:21,819 --> 00:16:23,179 you, like, you've got the screen up now. 431 00:16:23,419 --> 00:16:24,779 Those are the ones that give you secure 432 00:16:24,779 --> 00:16:27,259 boot. They give you virtual T pms. 433 00:16:27,914 --> 00:16:29,372 And then some of the 434 00:16:29,989 --> 00:16:33,182 integrity monitoring around, like, memory things like that 435 00:16:33,182 --> 00:16:35,816 coming in from the hyper visor. 436 00:16:36,549 --> 00:16:39,585 Single image that you're gonna choose. So it... 437 00:16:39,825 --> 00:16:42,381 It's kind of interesting. Like, again, this isn't 438 00:16:42,381 --> 00:16:44,872 like Has flex. Where you would say, hey. 439 00:16:45,112 --> 00:16:46,708 Maybe I have this Vm. That's on a 440 00:16:46,788 --> 00:16:48,624 Ubuntu. I have this 1 that's on windows, 441 00:16:48,863 --> 00:16:51,817 things like that. That doesn't occur over here. 442 00:16:51,976 --> 00:16:53,982 So you just kinda pick a single image, 443 00:16:54,539 --> 00:16:56,687 and then you're lining up the units of 444 00:16:56,687 --> 00:16:59,016 compute that are all gonna use that image 445 00:16:59,550 --> 00:17:01,872 underneath it. Yep. And you can do with 446 00:17:01,872 --> 00:17:03,784 that image, you can do your custom images 447 00:17:03,784 --> 00:17:05,059 to you. So you still get that option 448 00:17:05,059 --> 00:17:06,116 like Go see marketplace 449 00:17:06,572 --> 00:17:09,294 images, see other images, where you can go 450 00:17:09,294 --> 00:17:11,441 select my images, shared images. 451 00:17:11,997 --> 00:17:15,200 You can do ubuntu Red hat, oracle windows, 452 00:17:15,733 --> 00:17:17,761 like you have all of your normal 453 00:17:18,217 --> 00:17:20,151 images that you would expect. So this isn't 454 00:17:20,368 --> 00:17:22,519 limiting in that aspect. It's just limiting and 455 00:17:22,519 --> 00:17:24,511 that you could only pick 1 for your 456 00:17:24,511 --> 00:17:25,945 entire fleet. Correct. Yeah. 457 00:17:26,679 --> 00:17:26,839 Yep. 458 00:17:30,754 --> 00:17:32,832 Do you feel overwhelmed by trying to manage 459 00:17:32,832 --> 00:17:35,664 your Office 3 65 environment are you facing 460 00:17:35,803 --> 00:17:38,381 unexpected issues that disrupt your company's productivity? 461 00:17:38,839 --> 00:17:40,677 Intelligent is here to help much like you 462 00:17:40,677 --> 00:17:42,595 take your car to the mechanic that has 463 00:17:42,595 --> 00:17:44,685 specialized knowledge on how to best keep your 464 00:17:44,685 --> 00:17:47,718 car running, intelligent helps you with your Microsoft 465 00:17:47,718 --> 00:17:51,230 cloud environment because that's their expertise. Intelligent keeps 466 00:17:51,230 --> 00:17:53,314 up with the latest updates in the Microsoft 467 00:17:53,314 --> 00:17:55,622 cloud to help keep your business running smoothly 468 00:17:55,622 --> 00:17:57,293 and ahead of the curve. Whether you are 469 00:17:57,293 --> 00:17:59,759 a small organization with just a few users 470 00:17:59,759 --> 00:18:02,480 up to an as of several thousand employees. 471 00:18:02,877 --> 00:18:04,866 They want to partner with you to implement 472 00:18:04,866 --> 00:18:07,515 and administer your Microsoft cloud technology. 473 00:18:08,302 --> 00:18:11,825 Visit them at intelligent dot com slash podcast 474 00:18:12,121 --> 00:18:16,986 that's INTELLIGINK 475 00:18:16,986 --> 00:18:18,837 dot com slash podcast 476 00:18:19,212 --> 00:18:21,358 for more information or to schedule a 30 477 00:18:21,358 --> 00:18:23,186 minute call to get started with them today. 478 00:18:23,822 --> 00:18:27,111 Remember intelligent focuses on the Microsoft cloud, so 479 00:18:27,111 --> 00:18:28,710 you can focus on your business. 480 00:18:31,267 --> 00:18:34,475 Next up for you is the types virtual 481 00:18:34,475 --> 00:18:36,142 machines. So I think this is an interesting 482 00:18:36,142 --> 00:18:37,730 1 Like I I'm Mentioned in kinda of 483 00:18:37,730 --> 00:18:39,159 the opening that you can do mix and 484 00:18:39,159 --> 00:18:39,318 match. 485 00:18:40,032 --> 00:18:42,674 For cost optimizations. So being able to mix 486 00:18:42,674 --> 00:18:45,634 and match regular Vms and spot Vms. 487 00:18:46,355 --> 00:18:49,075 And then you can select the sizes or 488 00:18:49,075 --> 00:18:50,994 the Vm series that you wanna use. 489 00:18:51,808 --> 00:18:54,696 Along the way for those specific components. So 490 00:18:54,912 --> 00:18:57,380 I think it's a minimum today of 3 491 00:18:57,539 --> 00:18:59,782 Vm series that you have to select and 492 00:18:59,782 --> 00:19:01,689 you can go up to 15. I'm gonna 493 00:19:01,689 --> 00:19:03,675 spin up some big ones, Scott. I'm gonna 494 00:19:03,675 --> 00:19:04,811 go do 10000 495 00:19:05,026 --> 00:19:06,218 d 96 496 00:19:06,218 --> 00:19:08,616 b fives. Yeah. Go for it. That's a 497 00:19:08,616 --> 00:19:10,045 beef you bill. So, yeah, shooting can do 498 00:19:10,045 --> 00:19:12,188 us select a bunch of those. Like you 499 00:19:12,188 --> 00:19:13,537 said, spot regular. 500 00:19:13,934 --> 00:19:15,998 So... And then after that, you start picking 501 00:19:15,998 --> 00:19:18,244 capacity. This is the 1 where it gets 502 00:19:18,244 --> 00:19:20,484 interesting for me. Like, after you select all 503 00:19:20,484 --> 00:19:21,224 your sizes, 504 00:19:21,845 --> 00:19:23,304 now you can go choose these 505 00:19:23,605 --> 00:19:24,744 capacity preferences. 506 00:19:25,299 --> 00:19:26,198 So you can 507 00:19:26,655 --> 00:19:29,446 maintain a capacity, and this is once the 508 00:19:29,446 --> 00:19:30,722 target is matte, 509 00:19:31,519 --> 00:19:34,965 replace evicted vms to maintain target capacity. So 510 00:19:34,965 --> 00:19:36,164 it sounds like once you spin this up, 511 00:19:36,325 --> 00:19:38,805 you can set a capacity. So target capacity 512 00:19:38,805 --> 00:19:41,205 is a number between 1 and 10000, 513 00:19:41,525 --> 00:19:43,285 and it sounds like once you spin these 514 00:19:43,285 --> 00:19:45,053 up, you must be able to kick Vms 515 00:19:45,053 --> 00:19:46,799 out. Like you could essentially go in and 516 00:19:46,799 --> 00:19:49,838 say, I'm missed guessing eviction is essentially 517 00:19:50,370 --> 00:19:52,512 deleting that Vm saying this Vm isn't part 518 00:19:52,512 --> 00:19:56,038 of this this fleet anymore. It's a spot 519 00:19:56,038 --> 00:19:58,114 compute thing. 1 of the things that you 520 00:19:58,114 --> 00:20:01,387 run into with spot compute is it's kinda 521 00:20:01,387 --> 00:20:02,446 based on availability. 522 00:20:03,000 --> 00:20:05,799 And it's based on demand shaping within the 523 00:20:05,799 --> 00:20:08,200 region. So if you're doing spot, 524 00:20:08,919 --> 00:20:11,404 spot can be evicted, at any time. So 525 00:20:11,404 --> 00:20:14,341 it's really good for kinda, like, state workloads. 526 00:20:14,499 --> 00:20:16,166 If you have state full things, you know, 527 00:20:16,325 --> 00:20:18,325 you kinda make sure like, hey, that you're 528 00:20:18,325 --> 00:20:20,950 responding to things like eviction notices, so you're 529 00:20:20,950 --> 00:20:24,210 potentially persisting state and, like, object storage or 530 00:20:24,210 --> 00:20:25,483 off to disc someplace else. 531 00:20:26,292 --> 00:20:28,674 Things like that. So basically, what it's saying 532 00:20:28,674 --> 00:20:30,976 is if you wanna maintain your capacity, like, 533 00:20:31,214 --> 00:20:33,517 let's say you did a thousand spot vms, 534 00:20:34,089 --> 00:20:36,646 and you tell it to maintain. Well, over 535 00:20:36,646 --> 00:20:38,643 time, once you've turned those spot vms off, 536 00:20:38,803 --> 00:20:40,880 they're gonna get evicted just naturally through the 537 00:20:40,880 --> 00:20:42,963 life cycle as other customers come in and 538 00:20:42,963 --> 00:20:44,554 out of the region and the elasticity there. 539 00:20:44,951 --> 00:20:46,383 So what you're telling it to do is 540 00:20:46,383 --> 00:20:49,109 saying, like, hey, I need a thousand vms 541 00:20:49,659 --> 00:20:51,972 all the time. So if any get evicted, 542 00:20:52,291 --> 00:20:54,125 so it avail a hundred Vms and you 543 00:20:54,125 --> 00:20:55,083 go down to 900, 544 00:20:55,561 --> 00:20:58,353 the async engine in the background that's deploying 545 00:20:58,353 --> 00:21:00,523 that compute for you, will come in and 546 00:21:00,523 --> 00:21:02,841 request another hundreds spot Vms to get you 547 00:21:02,841 --> 00:21:04,679 back up to a thousand. And if you 548 00:21:04,679 --> 00:21:06,596 can't get you to a thousand, it'll kinda 549 00:21:06,596 --> 00:21:08,847 keep churning away in the back end. And 550 00:21:08,847 --> 00:21:10,913 keep trying to get you to where you 551 00:21:10,913 --> 00:21:12,900 need to be, or you can say don't 552 00:21:12,900 --> 00:21:14,728 maintain that capacity. Like, hey, I wanna start 553 00:21:14,728 --> 00:21:16,875 at, like, a thousand, and then stuff's just 554 00:21:16,875 --> 00:21:19,597 naturally gonna get it over time. And once 555 00:21:19,597 --> 00:21:20,394 it gets evicted, 556 00:21:20,952 --> 00:21:22,467 I don't really need it back or maybe 557 00:21:22,626 --> 00:21:24,539 I spun up another compute fleet or something 558 00:21:24,539 --> 00:21:26,728 else along the way. So you can kinda 559 00:21:27,026 --> 00:21:27,924 let it go 560 00:21:28,461 --> 00:21:30,854 naturally kinda downhill that way if you want 561 00:21:30,854 --> 00:21:32,689 to. This would get interesting then with the 562 00:21:32,689 --> 00:21:33,725 365 563 00:21:33,725 --> 00:21:36,210 days because as it technically then like, no 564 00:21:36,210 --> 00:21:38,352 longer active after 365 565 00:21:38,352 --> 00:21:40,914 days and if something gets evicted, it isn't 566 00:21:40,970 --> 00:21:44,104 active to maintain capacity. There is my question. 567 00:21:44,477 --> 00:21:47,098 I guess so. I don't know. Preview service, 568 00:21:47,257 --> 00:21:49,481 there's no Sla, anything like that. Figure it 569 00:21:49,481 --> 00:21:51,800 out. I imagine some of this like just 570 00:21:51,800 --> 00:21:53,709 to be brutally honest is kinda like a 571 00:21:53,709 --> 00:21:55,459 shot in the dark from folks going like, 572 00:21:55,857 --> 00:21:57,448 hey, how long do we need to do 573 00:21:57,448 --> 00:21:57,687 this? 574 00:21:58,340 --> 00:22:01,220 Is, like, a year sounds like a long 575 00:22:01,220 --> 00:22:04,500 time for a long running async job just 576 00:22:04,500 --> 00:22:06,340 to kinda keep sitting in the background. It's 577 00:22:06,340 --> 00:22:07,299 like a job scheduler. 578 00:22:08,113 --> 00:22:09,969 Especially when you consider that 579 00:22:10,346 --> 00:22:12,260 at least as of today for compute fleet, 580 00:22:12,659 --> 00:22:14,733 it doesn't have any cost. So it's kinda 581 00:22:14,733 --> 00:22:16,567 like Ak and that, you know, you're getting 582 00:22:16,567 --> 00:22:18,018 the management piece for free, 583 00:22:18,735 --> 00:22:21,364 but you're paying for the underlying compute along 584 00:22:21,364 --> 00:22:23,754 the way and and all the constructs that 585 00:22:23,754 --> 00:22:25,443 that come with that. So you're You're paying 586 00:22:25,443 --> 00:22:27,279 for the virtual machines. You're not paying for 587 00:22:27,279 --> 00:22:30,072 the ability to deploy those virtual machines and 588 00:22:30,072 --> 00:22:31,051 manage them 589 00:22:31,588 --> 00:22:34,870 via compute fleet. I don't know if part 590 00:22:34,870 --> 00:22:36,621 of it is maybe, like, a little bit 591 00:22:36,621 --> 00:22:38,690 of, like, just a cost thing, even like, 592 00:22:39,009 --> 00:22:41,171 internally. Like, hey, how many these jobs do 593 00:22:41,171 --> 00:22:42,599 we need to run? How long do they 594 00:22:42,599 --> 00:22:44,423 need to pull for? What does that look 595 00:22:44,423 --> 00:22:46,643 like and how does it manifest? I imagine 596 00:22:46,643 --> 00:22:48,759 a lot of that stuff gets cleaned up 597 00:22:48,879 --> 00:22:51,608 be before it go was to a 598 00:22:52,223 --> 00:22:54,292 production state. I would assume so because there's 599 00:22:54,292 --> 00:22:56,124 a lot of I have a lot of 600 00:22:56,124 --> 00:22:56,601 questions. 601 00:22:57,173 --> 00:22:58,920 Like, how some of that works that aren't 602 00:22:58,920 --> 00:23:00,746 answered. I think some of the the questions 603 00:23:00,746 --> 00:23:02,652 you have. You know, if folks are kinda 604 00:23:02,652 --> 00:23:04,161 sitting in the background and they're asking these 605 00:23:04,161 --> 00:23:04,717 same questions. 606 00:23:05,289 --> 00:23:07,286 A, lot of it is... This might not 607 00:23:07,286 --> 00:23:09,603 be the service for you. Like, that's true. 608 00:23:10,242 --> 00:23:12,055 There are other things out there. Like, this 609 00:23:12,493 --> 00:23:12,993 definitely, 610 00:23:13,849 --> 00:23:15,466 like, has a 611 00:23:16,082 --> 00:23:19,113 use case and a place. And if you're 612 00:23:19,113 --> 00:23:20,310 looking at it, and you're going, like, yeah, 613 00:23:20,469 --> 00:23:21,506 I don't really see the use case. Right 614 00:23:21,666 --> 00:23:23,835 I don't see place, like, that's okay. That's 615 00:23:23,835 --> 00:23:25,133 why things like Vm 616 00:23:25,511 --> 00:23:28,544 and everything else exists out there. Because like 617 00:23:28,623 --> 00:23:31,271 I said, this isn't Vms, So even though 618 00:23:31,271 --> 00:23:33,584 you can do the capacity deployment through a 619 00:23:33,584 --> 00:23:36,296 single Api call, you've still got the potential, 620 00:23:36,376 --> 00:23:39,008 like, configuration concerns and all the other stuff 621 00:23:39,008 --> 00:23:40,940 that comes along the way with it. So 622 00:23:40,940 --> 00:23:43,100 you have this little trade off there that 623 00:23:43,100 --> 00:23:44,080 you're kinda balancing 624 00:23:44,539 --> 00:23:45,039 between 625 00:23:45,500 --> 00:23:47,500 do I want to deploy a lot of 626 00:23:47,500 --> 00:23:50,152 compute or do I want to deploy a 627 00:23:50,152 --> 00:23:52,469 little less compute and then have all the 628 00:23:52,469 --> 00:23:55,345 manage ability aspects that come with it? Continuing 629 00:23:55,345 --> 00:23:56,500 down? Setting 630 00:23:56,960 --> 00:23:59,840 maintain capacity don't maintain, what is your target 631 00:23:59,840 --> 00:24:01,279 capacity? So what are you gonna set this 632 00:24:01,279 --> 00:24:02,960 at? And then you can set the eviction 633 00:24:02,960 --> 00:24:04,000 policy. So... 634 00:24:04,480 --> 00:24:07,452 That's all spot stuff, spot specific. Delete, 635 00:24:08,171 --> 00:24:10,887 allocation strategies, max hourly, price per spot is 636 00:24:10,887 --> 00:24:12,619 all the spot stuff, and then you get 637 00:24:12,819 --> 00:24:13,876 down to 638 00:24:14,252 --> 00:24:16,880 the Vm capacity so non spot Vms, 639 00:24:17,358 --> 00:24:19,509 and you lose some of those extra settings 640 00:24:19,509 --> 00:24:21,555 because now it's just regular compute where it's 641 00:24:21,754 --> 00:24:23,989 your capacity, and this one's... 642 00:24:24,947 --> 00:24:26,224 I don't know if this is spot. Yeah. 643 00:24:26,384 --> 00:24:27,182 Maybe you can help me out with this. 644 00:24:27,422 --> 00:24:29,098 Like, you can set a capacity for these 645 00:24:29,098 --> 00:24:30,556 normal Vms of 646 00:24:30,869 --> 00:24:32,704 say a thousand. And then you set your 647 00:24:32,704 --> 00:24:34,401 minimum starting capacity 648 00:24:34,778 --> 00:24:39,265 of something like 10, and this minimum starting 649 00:24:39,265 --> 00:24:42,224 capacity is essentially saying that Vm in the 650 00:24:42,224 --> 00:24:45,025 fleet our provision gradually. It starts with your 651 00:24:45,025 --> 00:24:48,311 desired in capacity if you specify it, so 652 00:24:48,311 --> 00:24:50,145 it could start with 10, and then it's 653 00:24:50,145 --> 00:24:51,523 gonna slowly grow 654 00:24:51,900 --> 00:24:54,373 up to 100. It doesn't say how slow, 655 00:24:54,692 --> 00:24:56,297 but this is not something you have with 656 00:24:56,297 --> 00:24:58,836 spot Vms. Like spot vms you just set 657 00:24:58,836 --> 00:25:02,539 the capacity, and I'm guessing it's does it 658 00:25:02,819 --> 00:25:04,276 all out once 659 00:25:04,733 --> 00:25:07,445 versus regular Vms where if you want to 660 00:25:07,445 --> 00:25:09,838 use set a minimum and slowly ramp up 661 00:25:09,838 --> 00:25:12,525 to your capacity. I think it's implied that 662 00:25:12,882 --> 00:25:16,373 spot is also going to ramp because by 663 00:25:16,373 --> 00:25:18,197 nature of spot via. By nature of spot. 664 00:25:18,356 --> 00:25:20,577 Like, you're basically saying with spot compute. 665 00:25:21,229 --> 00:25:23,384 Give me your extra compute in the region, 666 00:25:23,864 --> 00:25:25,540 and I'm gonna pay a little bit less 667 00:25:25,540 --> 00:25:27,696 for that compute, but the reason that I'm 668 00:25:27,696 --> 00:25:30,511 paying less is because you, Microsoft as the 669 00:25:30,983 --> 00:25:33,680 as the host and hyper scaler can rip 670 00:25:33,680 --> 00:25:35,742 that compute away from me. I can be 671 00:25:35,742 --> 00:25:37,725 evicted. And when you've ripped that compute away 672 00:25:37,725 --> 00:25:39,668 from me, you're gonna go give it to 673 00:25:39,802 --> 00:25:41,942 another customer. So let's say in this case, 674 00:25:42,021 --> 00:25:43,764 like, I'm the 1 who's consuming a lot 675 00:25:43,764 --> 00:25:45,587 of spot, and you come in and you 676 00:25:45,587 --> 00:25:47,669 say, hey. I'm here as a as a 677 00:25:47,669 --> 00:25:49,899 customer and I don't need spot compute. I 678 00:25:49,899 --> 00:25:53,244 need real non ep compute, and it's in 679 00:25:53,244 --> 00:25:55,076 the same series that I have in spot. 680 00:25:55,569 --> 00:25:58,124 It's in Microsoft best interest to e me 681 00:25:58,124 --> 00:25:59,721 out of there and just let it go. 682 00:26:00,120 --> 00:26:01,317 So I I think a lot of it 683 00:26:01,317 --> 00:26:03,952 is just kinda, like, sitting and and trying 684 00:26:03,952 --> 00:26:04,692 to balance 685 00:26:05,565 --> 00:26:08,224 that nature of spot versus 686 00:26:08,845 --> 00:26:11,565 everything else that's they're and available for you. 687 00:26:11,724 --> 00:26:14,019 The other interesting thing about this too is 688 00:26:14,218 --> 00:26:16,124 like, you said earlier, you can select up 689 00:26:16,124 --> 00:26:18,428 to 15 different sizes. So you could go 690 00:26:18,428 --> 00:26:20,913 in and select 15 different 691 00:26:21,445 --> 00:26:22,184 d series 692 00:26:22,494 --> 00:26:25,211 Vms, z e series Vm spot Vms, but 693 00:26:25,211 --> 00:26:28,108 you can't set capacity on a per 694 00:26:28,806 --> 00:26:31,451 sku level. I can go in here, and 695 00:26:31,610 --> 00:26:33,439 I can say, I want my target capacity 696 00:26:33,439 --> 00:26:34,711 to be 3000, 697 00:26:35,347 --> 00:26:38,073 my minimum is a hundred, but I've selected 698 00:26:38,289 --> 00:26:39,481 5 different sizes. 699 00:26:39,974 --> 00:26:43,011 It's gonna go... Well, it's technically gonna break 700 00:26:43,011 --> 00:26:44,690 the way I have it now. If I'm 701 00:26:44,690 --> 00:26:47,427 spinning up 5 different sizes with 3000 702 00:26:47,567 --> 00:26:48,067 capacity. 703 00:26:48,606 --> 00:26:52,075 I believe it's spinning up 3000 704 00:26:52,773 --> 00:26:56,365 of each or is it taking? Now I'm 705 00:26:56,365 --> 00:26:59,968 questioning myself. Total capacity. So this is total 706 00:26:59,968 --> 00:27:02,774 capacity. It's taking 3000 dividing it by 5 707 00:27:02,910 --> 00:27:04,841 probably and spinning up 708 00:27:05,216 --> 00:27:06,114 600 709 00:27:06,170 --> 00:27:07,068 of each 710 00:27:07,539 --> 00:27:09,933 Skew that I've selected, doing that math in 711 00:27:09,933 --> 00:27:12,407 the background versus 3000 of each sku that 712 00:27:12,567 --> 00:27:15,600 I've selected. Again, very unclear from the documentation, 713 00:27:16,013 --> 00:27:18,001 even from the sense of, like, hey, self 714 00:27:18,001 --> 00:27:19,671 documenting code. If you go look at, like, 715 00:27:20,069 --> 00:27:22,954 the arm templates for these or, like, the 716 00:27:23,170 --> 00:27:24,147 actual arm 717 00:27:24,840 --> 00:27:27,986 endpoint that sits out there. I don't have, 718 00:27:28,604 --> 00:27:30,221 you know, 10000 course 719 00:27:30,919 --> 00:27:32,436 that I can go play with in my 720 00:27:32,436 --> 00:27:34,272 in my Pe go subscription. So, like, I 721 00:27:34,272 --> 00:27:36,044 wasn't even able to to 1 of these 722 00:27:36,044 --> 00:27:38,761 at scale, like, even, you know, even getting 723 00:27:38,761 --> 00:27:41,318 yourself lifted beyond, like, the default core limits 724 00:27:41,318 --> 00:27:43,815 and, like, a visual studio sub is 725 00:27:44,288 --> 00:27:46,139 pretty rough these days 726 00:27:46,592 --> 00:27:48,261 for how that stuff comes together. But, yeah, 727 00:27:48,896 --> 00:27:50,350 you're basically doing 728 00:27:50,724 --> 00:27:53,283 your allocations that way, and it's gonna split 729 00:27:53,283 --> 00:27:56,787 amongst them. It's unclear how it divides things 730 00:27:56,787 --> 00:27:59,416 up. So the interesting thing is it's not 731 00:27:59,416 --> 00:28:01,407 exposed in the portal really or at least 732 00:28:01,407 --> 00:28:03,577 it is a math back clearly between with 733 00:28:03,577 --> 00:28:05,415 the options in the portal. But in the 734 00:28:05,415 --> 00:28:06,693 arm template, if you go look at the 735 00:28:06,693 --> 00:28:10,617 arm template. So Mh. The spot profile and 736 00:28:10,617 --> 00:28:12,528 the regular priority profile. 737 00:28:13,165 --> 00:28:15,735 They have this property that's called 738 00:28:16,270 --> 00:28:17,226 allocation strategy. 739 00:28:17,880 --> 00:28:18,380 And 740 00:28:18,839 --> 00:28:19,740 allocation strategy 741 00:28:20,279 --> 00:28:22,279 can be capacity optimized, 742 00:28:22,839 --> 00:28:25,080 or it can be lowest priced. 743 00:28:25,574 --> 00:28:27,991 So that's kind of interesting because 744 00:28:28,450 --> 00:28:30,128 then what it's doing, if I'm reading it 745 00:28:30,128 --> 00:28:32,285 the right way based on the Api, is 746 00:28:32,285 --> 00:28:34,640 it using the logic of, hey, you selected 747 00:28:34,779 --> 00:28:36,700 5 d series Vms. 748 00:28:37,580 --> 00:28:39,259 What are you phonetic clicking on over there? 749 00:28:39,753 --> 00:28:40,650 So so you've 750 00:28:41,500 --> 00:28:42,452 nuts. Yes. 751 00:28:43,087 --> 00:28:46,025 You've selected 5 d series Vms, you can 752 00:28:46,025 --> 00:28:47,349 go in and you can make your Alex 753 00:28:47,548 --> 00:28:50,966 vacation strategy to be lowest price. And then 754 00:28:50,966 --> 00:28:52,874 what it'll do based on that is, 755 00:28:53,351 --> 00:28:55,576 I... It would literally choose the lowest price 756 00:28:55,655 --> 00:28:58,059 Vm series. And it would start with deploying 757 00:28:58,059 --> 00:29:00,211 those first and then come behind it, like, 758 00:29:00,291 --> 00:29:02,523 it would just keep kinda incrementally stepping up 759 00:29:02,523 --> 00:29:05,326 the ladder based on the price. Or like 760 00:29:05,405 --> 00:29:07,467 I said, the other dimension is capacity optimized. 761 00:29:07,705 --> 00:29:08,974 So what I was clicking and I was 762 00:29:08,974 --> 00:29:10,878 trying to see what a... I can't find 763 00:29:10,878 --> 00:29:12,782 small Vms. That's another weird thing with this. 764 00:29:13,274 --> 00:29:15,115 Like the smallest Vm I was able to 765 00:29:15,115 --> 00:29:17,514 find to select was 8 cores. I was 766 00:29:17,514 --> 00:29:19,434 curious if I just selected 2 small ones 767 00:29:19,434 --> 00:29:21,115 and set it to 4. If I get 768 00:29:21,115 --> 00:29:22,807 8 Vms or if I get 2 of 769 00:29:22,807 --> 00:29:24,635 each. Okay. Not to service for you if 770 00:29:24,635 --> 00:29:26,781 you're looking for small tabs. If I'm looking 771 00:29:26,781 --> 00:29:28,848 for small Vms, I know. I was trying 772 00:29:28,848 --> 00:29:30,279 to test it out to answer my questions. 773 00:29:30,836 --> 00:29:33,812 This very much does seem geared towards, like 774 00:29:33,947 --> 00:29:35,375 Ai training scenarios, 775 00:29:36,248 --> 00:29:39,104 Hp scenarios, where I'm gonna spin up a 776 00:29:39,104 --> 00:29:40,969 bunch of compute to 777 00:29:41,344 --> 00:29:43,117 run some kind of 778 00:29:43,652 --> 00:29:45,880 some kind of job on top of things. 779 00:29:46,437 --> 00:29:48,427 It's just going above and beyond, like, the 780 00:29:48,427 --> 00:29:49,835 click stops of some of the 781 00:29:50,194 --> 00:29:52,612 scale out capabilities of things like, 782 00:29:52,990 --> 00:29:55,648 you know, the current Hp offerings, current Vms 783 00:29:55,787 --> 00:29:58,437 offerings, but, yeah. It's a little bit of 784 00:29:58,437 --> 00:30:00,666 weird nuance there. So then once you set 785 00:30:00,666 --> 00:30:02,975 your capacities, it's really, after that, it's just 786 00:30:02,975 --> 00:30:05,125 what's my admin username password for all these 787 00:30:05,125 --> 00:30:07,370 vms, again, set it once, get it for 788 00:30:07,370 --> 00:30:07,870 everything. 789 00:30:09,123 --> 00:30:10,955 If you wanna do hybrid benefit, if you're 790 00:30:10,955 --> 00:30:11,694 doing windows, 791 00:30:12,151 --> 00:30:15,358 and then networking is just virtual network subnet, 792 00:30:15,677 --> 00:30:17,435 and then you can go in and tweak 793 00:30:17,435 --> 00:30:18,554 network interfaces. 794 00:30:19,034 --> 00:30:21,751 Really, if you wanna do Ns msg or 795 00:30:21,751 --> 00:30:24,561 accelerated networking. They do have an option 2 796 00:30:24,561 --> 00:30:26,237 to do a new load balance in front 797 00:30:26,237 --> 00:30:29,510 of it with networking. So relatively basic, you're 798 00:30:29,510 --> 00:30:31,267 essentially just saying dump all these vms in 799 00:30:31,267 --> 00:30:31,825 a network. 800 00:30:32,318 --> 00:30:33,906 Use an ns msg if you want to... 801 00:30:34,223 --> 00:30:35,255 And if you're gonna do any type of 802 00:30:35,255 --> 00:30:37,716 load balancing. Yeah. I believe you have to 803 00:30:37,716 --> 00:30:39,755 create a load balance. I don't think it's 804 00:30:40,034 --> 00:30:42,107 optional Do you? I'm gonna try it? Oh, 805 00:30:42,347 --> 00:30:44,740 basics. What did I fail on? Oh, field 806 00:30:44,740 --> 00:30:47,770 name? Benz test fleet. Who it validated without 807 00:30:47,770 --> 00:30:50,579 a load balance or Scott? Create gonna initialize 808 00:30:50,579 --> 00:30:52,177 the deployment. So I tried to spin it 809 00:30:52,177 --> 00:30:54,015 up through an arm template, and I just 810 00:30:54,015 --> 00:30:56,253 pulled their default arm template. So the default 811 00:30:56,253 --> 00:30:58,970 arm template at least as it's documented today. 812 00:30:59,942 --> 00:31:02,490 Includes a V handle load balance in it. 813 00:31:02,729 --> 00:31:04,879 So, yes. I just said V subnet, no 814 00:31:04,879 --> 00:31:07,210 load balance. So it doesn't look like it's 815 00:31:07,347 --> 00:31:10,079 required. We'll see what this actually creates when 816 00:31:10,079 --> 00:31:11,759 it goes and deploy everything. 817 00:31:12,480 --> 00:31:13,759 Well, mean if I have to come back 818 00:31:13,759 --> 00:31:14,400 and check in a year. 819 00:31:15,200 --> 00:31:17,932 Yeah. It's What else? There's that Faq out 820 00:31:17,932 --> 00:31:19,769 here. I'm trying to think if there was 821 00:31:19,769 --> 00:31:21,388 anything else in here 822 00:31:21,847 --> 00:31:23,740 that we wanted to cover, start and stop 823 00:31:23,940 --> 00:31:26,259 time. Yeah. No start and stop time. You 824 00:31:26,259 --> 00:31:28,339 spin it up? It's running. It will be 825 00:31:28,339 --> 00:31:29,859 interesting like you said, do they change some 826 00:31:29,859 --> 00:31:31,059 of the stuff going forward, 827 00:31:31,539 --> 00:31:33,472 but also like you said it's not for 828 00:31:33,472 --> 00:31:35,224 me. This is not a service I would 829 00:31:35,224 --> 00:31:37,773 use, the only use I kinda thought of 830 00:31:37,773 --> 00:31:39,604 it, but even as we've looked at it 831 00:31:39,604 --> 00:31:40,958 is if you wanted to do it for 832 00:31:40,958 --> 00:31:42,565 a lab. If you're spinning up, like a 833 00:31:42,565 --> 00:31:45,507 large lab for a learning environment. But even 834 00:31:45,507 --> 00:31:47,892 that, given you'd have to do an image 835 00:31:47,892 --> 00:31:49,403 and that there's no start and stop time, 836 00:31:49,801 --> 00:31:52,763 you're probably better off going other routes even 837 00:31:52,763 --> 00:31:54,761 for labs. Like you said it does tend 838 00:31:54,761 --> 00:31:57,239 to be... It appears to be more Hp 839 00:31:57,319 --> 00:31:59,397 Ai training based stuff that you were mentioning. 840 00:31:59,636 --> 00:32:00,776 I'd go back to you 841 00:32:01,568 --> 00:32:04,109 there are services to do those kinds of 842 00:32:04,109 --> 00:32:07,206 things. Right? Like, there there's literally lab services. 843 00:32:07,444 --> 00:32:09,747 Lab services. We've talked about that 1 before, 844 00:32:09,985 --> 00:32:12,388 which does sit out there. There's Dev. So 845 00:32:12,388 --> 00:32:13,526 there's kinda all these different 846 00:32:14,301 --> 00:32:15,199 constructs. So 847 00:32:15,895 --> 00:32:17,489 you do have to kinda go through and 848 00:32:17,489 --> 00:32:18,547 pick the right 849 00:32:18,940 --> 00:32:19,440 functionality, 850 00:32:19,819 --> 00:32:23,200 like, underlying deployment model, all all those things 851 00:32:23,579 --> 00:32:24,079 that 852 00:32:24,539 --> 00:32:25,899 that are gonna work for you within there. 853 00:32:26,393 --> 00:32:27,821 The only thing I'd call out is, like, 854 00:32:27,900 --> 00:32:29,249 if folks are watching this, and they're like, 855 00:32:29,329 --> 00:32:30,440 trying to get hands on with it and 856 00:32:30,440 --> 00:32:31,947 if you are more of, like, an arm 857 00:32:31,947 --> 00:32:33,137 template deployment person, 858 00:32:33,788 --> 00:32:34,288 versus 859 00:32:34,824 --> 00:32:36,418 a go and click in the portal to 860 00:32:36,418 --> 00:32:38,968 do your first deployment. You do have to 861 00:32:38,968 --> 00:32:42,487 register the resource provider. For this 1. So 862 00:32:42,487 --> 00:32:43,998 there's a little bit of a flag that 863 00:32:43,998 --> 00:32:46,543 needs to be cleared, register the resource provider 864 00:32:46,543 --> 00:32:47,498 and then you can go ahead and do 865 00:32:47,498 --> 00:32:47,975 your deployments. 866 00:32:48,789 --> 00:32:49,289 You 867 00:32:49,670 --> 00:32:51,589 didn't have to register the resource provider because 868 00:32:51,589 --> 00:32:54,329 you initiated through the portal and then that 869 00:32:54,630 --> 00:32:57,369 registration happens automatically. And then it broke because 870 00:32:57,605 --> 00:32:59,605 My subscription is not registered to use the 871 00:32:59,605 --> 00:33:02,565 name base Microsoft dot compute. You've never deployed 872 00:33:02,565 --> 00:33:05,205 a vm in there. Apparently not. That's a 873 00:33:05,205 --> 00:33:05,525 weird 1. 874 00:33:06,730 --> 00:33:08,869 I thought I had. Now I'm gonna go 875 00:33:08,869 --> 00:33:11,167 look. Oh, this is gonna be annoying. Yeah. 876 00:33:11,404 --> 00:33:13,404 We'll go look later. That wraps that'll be 877 00:33:13,404 --> 00:33:14,123 for another time. 878 00:33:15,242 --> 00:33:18,278 Yes yes. Yeah. So kind of a interesting 879 00:33:18,278 --> 00:33:21,485 service to go look at explore play with. 880 00:33:21,802 --> 00:33:24,103 If you wanna go spin up a whole 881 00:33:24,103 --> 00:33:26,482 lot of vms. Compute fleet. Get it done. 882 00:33:26,799 --> 00:33:28,862 Alright. As always. Thank you, Ben. Thank you. 883 00:33:29,433 --> 00:33:31,736 Enjoyed it. Enjoy your weekend. Try to stay 884 00:33:31,736 --> 00:33:34,778 cool in this. Florida got hot really fast 885 00:33:34,993 --> 00:33:37,138 this year. We went from summer to summer, 886 00:33:37,376 --> 00:33:40,967 like that yes. In an instant. So enjoy, 887 00:33:41,206 --> 00:33:42,398 we will talk to you again soon. Alright. 888 00:33:42,557 --> 00:33:42,955 Thanks, Ben. 889 00:33:45,260 --> 00:33:46,691 If you enjoyed the podcast, 890 00:33:47,024 --> 00:33:48,782 Go leave us a 5 star rating in 891 00:33:48,782 --> 00:33:50,700 itunes. It helps to get the word out 892 00:33:50,700 --> 00:33:52,857 so more It pros can learn about Office 893 00:33:52,857 --> 00:33:54,136 3 65 in Azure. 894 00:33:54,935 --> 00:33:56,786 If you have questions you want us to 895 00:33:56,786 --> 00:33:58,861 address on the show or feedback about the 896 00:33:58,861 --> 00:34:01,494 show, feel free to reach out via our 897 00:34:01,494 --> 00:34:03,090 website, Twitter, or Facebook. 898 00:34:03,656 --> 00:34:05,395 Thanks again for listening and have a great 899 00:34:05,395 --> 00:34:05,554 day.

Digital Dispatch Podcast Podcast Artwork Image

Microsoft Cloud IT Pro Podcast

Ben Stegink, Scott Hoag

On the MS Cloud IT Pro Podcast, Scott and Ben discuss the Microsoft Cloud with a focus on IT Pros. They'll discuss the latest in Microsoft 365 and Office 365 News, Azure news and talk about their experiences with managing the Microsoft Cloud as well as interview industry experts on various cloud technology. They'll cover things such as SharePoint, Exchange, Microsoft Teams, PowerShell, Azure, Azure AD, Security, Networking, Storage, and the many other technologies and products that have made their way into the Microsoft 365 suite and Azure. To stay up-to-date on the latest in Microsoft Cloud news and gain some valuable knowledge as you deploy it within your own organization, make sure to tune in every week! Find out more at msclouditpropodcast.com.

Contact Show