1 00:00:00,000 --> 00:00:03,560 Most people hear the word cloud and think of one simple idea. 2 00:00:03,560 --> 00:00:07,280 Your apps, files, and data can run from anywhere. 3 00:00:07,280 --> 00:00:09,600 For many workloads, that works really well. 4 00:00:09,600 --> 00:00:11,440 You can add capacity when demand grows, 5 00:00:11,440 --> 00:00:13,160 use services without buying more servers, 6 00:00:13,160 --> 00:00:14,840 and manage everything from one place. 7 00:00:14,840 --> 00:00:17,640 But here's the thing, some work can't leave the building. 8 00:00:17,640 --> 00:00:19,520 A factory needs fast machine decisions, 9 00:00:19,520 --> 00:00:22,040 or hospital may need patient data kept on site, 10 00:00:22,040 --> 00:00:24,240 and a remote location might lose its internet connection 11 00:00:24,240 --> 00:00:28,400 for hours or days, for years, that created two separate worlds. 12 00:00:28,400 --> 00:00:31,120 Cloud teams used Azure tools on one side, 13 00:00:31,120 --> 00:00:33,240 while local server teams used different tools, 14 00:00:33,240 --> 00:00:35,200 different update plans, and different ways 15 00:00:35,200 --> 00:00:36,960 to keep things secure on the other. 16 00:00:36,960 --> 00:00:38,760 Azure local aims to close that gap. 17 00:00:38,760 --> 00:00:41,000 It lets you run workloads at your own side, 18 00:00:41,000 --> 00:00:43,520 while using Azure for much of the management around them. 19 00:00:43,520 --> 00:00:45,680 But one question often causes confusion. 20 00:00:45,680 --> 00:00:48,480 If Azure Arc can connect local servers to Azure, 21 00:00:48,480 --> 00:00:50,480 why would you also need Azure local? 22 00:00:50,480 --> 00:00:52,280 That difference becomes clear when you look at why 23 00:00:52,280 --> 00:00:54,880 some workloads need to stay close to home. 24 00:00:54,880 --> 00:00:57,200 Why some workloads must stay local? 25 00:00:57,200 --> 00:00:59,600 Imagine a factory line making parts every second. 26 00:00:59,600 --> 00:01:01,760 A camera watches each part as it moves past, 27 00:01:01,760 --> 00:01:03,440 a sensor notices a small crack, 28 00:01:03,440 --> 00:01:06,080 and the system needs to decide whether to remove that part 29 00:01:06,080 --> 00:01:07,800 before it reaches the next machine. 30 00:01:07,800 --> 00:01:10,400 That decision may need to happen almost immediately. 31 00:01:10,400 --> 00:01:13,600 If every camera image travels to a distant Azure region, 32 00:01:13,600 --> 00:01:16,240 waits for processing, and then sends an answer back, 33 00:01:16,240 --> 00:01:17,520 the delay can be too long. 34 00:01:17,520 --> 00:01:19,040 Even a short network delay can mean 35 00:01:19,040 --> 00:01:20,720 the damaged part has already moved on, 36 00:01:20,720 --> 00:01:22,520 or the machine has already taken the wrong action. 37 00:01:22,520 --> 00:01:24,000 That's where edge computing comes in. 38 00:01:24,000 --> 00:01:27,160 Edge computing means processing data close to where it begins, 39 00:01:27,160 --> 00:01:29,320 so the camera, sensor, and local compute 40 00:01:29,320 --> 00:01:31,480 sit near the factory floor instead of depending 41 00:01:31,480 --> 00:01:33,960 on a distant cloud data center for every decision. 42 00:01:33,960 --> 00:01:35,120 The cloud still has a role. 43 00:01:35,120 --> 00:01:37,400 The factory can send selected data to Azure later, 44 00:01:37,400 --> 00:01:40,160 storing production history, comparing results across sites, 45 00:01:40,160 --> 00:01:43,040 training larger AI models, or creating reports for leaders. 46 00:01:43,040 --> 00:01:44,760 But the immediate decision stays local 47 00:01:44,760 --> 00:01:46,240 because the machine can't wait. 48 00:01:46,240 --> 00:01:48,800 You've probably seen the same idea outside of factory. 49 00:01:48,800 --> 00:01:49,880 Think about a ship at sea, 50 00:01:49,880 --> 00:01:52,040 where the connection may switch between satellite links, 51 00:01:52,040 --> 00:01:53,960 slow links, and no connection at all, 52 00:01:53,960 --> 00:01:55,680 yet navigation, engine systems, 53 00:01:55,680 --> 00:01:58,600 safety tools, and crew systems still need to run. 54 00:01:58,600 --> 00:02:00,800 Or picture a retail store where the internet connection 55 00:02:00,800 --> 00:02:02,360 drops during a busy weekend. 56 00:02:02,360 --> 00:02:04,760 If every checkout, stock check, and local system 57 00:02:04,760 --> 00:02:06,800 depends entirely on a cloud connection, 58 00:02:06,800 --> 00:02:09,120 the store has a problem at exactly the wrong time. 59 00:02:09,120 --> 00:02:11,600 Some places must stay disconnected by design. 60 00:02:11,600 --> 00:02:13,560 A secure government site, a defense environment, 61 00:02:13,560 --> 00:02:16,320 or a research facility, may never connect directly 62 00:02:16,320 --> 00:02:17,440 to the public internet. 63 00:02:17,440 --> 00:02:19,160 This is called disconnected operations, 64 00:02:19,160 --> 00:02:20,880 where local systems need to keep working 65 00:02:20,880 --> 00:02:23,200 with the site controls exactly how software updates 66 00:02:23,200 --> 00:02:24,680 and data move in and out. 67 00:02:24,680 --> 00:02:26,000 Then there's data sovereignty. 68 00:02:26,000 --> 00:02:27,640 That phrase sounds bigger than it is. 69 00:02:27,640 --> 00:02:30,280 In plain English, it means rules about where data can live 70 00:02:30,280 --> 00:02:31,520 and who can control it. 71 00:02:31,520 --> 00:02:34,720 So a company may need research data, patient records, 72 00:02:34,720 --> 00:02:38,120 video feeds, or operational data to remain within a country, 73 00:02:38,120 --> 00:02:40,240 a region, or even a specific building. 74 00:02:40,240 --> 00:02:43,400 Keeping data local isn't always about distrust of the cloud. 75 00:02:43,400 --> 00:02:45,560 Sometimes it's about law, sometimes about speed, 76 00:02:45,560 --> 00:02:47,560 and sometimes about keeping the business running 77 00:02:47,560 --> 00:02:48,920 when the network fails. 78 00:02:48,920 --> 00:02:50,880 A common mistake is treating on-premises 79 00:02:50,880 --> 00:02:53,360 computing as old technology that should disappear. 80 00:02:53,360 --> 00:02:54,640 That's not the right question. 81 00:02:54,640 --> 00:02:57,240 The better question is, where should this workload run? 82 00:02:57,240 --> 00:03:00,320 Azure works well for workloads that need flexible capacity, 83 00:03:00,320 --> 00:03:02,360 broad access, large-scale reporting, 84 00:03:02,360 --> 00:03:05,440 and services that don't depend on instant local responses. 85 00:03:05,440 --> 00:03:08,360 Local infrastructure works well when the data starts at a site. 86 00:03:08,360 --> 00:03:09,840 The decision must happen fast, 87 00:03:09,840 --> 00:03:11,960 or the site needs to keep operating on its own. 88 00:03:11,960 --> 00:03:14,080 Most organizations don't need to choose only one. 89 00:03:14,080 --> 00:03:15,240 They need the cloud for some work 90 00:03:15,240 --> 00:03:17,040 and local processing for other work. 91 00:03:17,040 --> 00:03:20,200 But local workloads need more than a server sitting in a closet. 92 00:03:20,200 --> 00:03:24,200 They need reliable compute, storage, networking, updates, security, 93 00:03:24,200 --> 00:03:27,960 and a way for the people who run Azure to see what's happening at the site. 94 00:03:27,960 --> 00:03:29,960 What Azure local actually is? 95 00:03:29,960 --> 00:03:32,160 So what exactly is Azure local? 96 00:03:32,160 --> 00:03:33,520 Here's the simplest definition. 97 00:03:33,520 --> 00:03:35,520 It's Microsoft infrastructure software 98 00:03:35,520 --> 00:03:37,880 that runs on a proved hardware in your own location. 99 00:03:37,880 --> 00:03:39,480 That location could be a data center, 100 00:03:39,480 --> 00:03:41,280 a branch office, a factory, a hospital, 101 00:03:41,280 --> 00:03:44,160 or any other site where your workloads need to stay nearby. 102 00:03:44,160 --> 00:03:46,040 You buy and keep the physical service. 103 00:03:46,040 --> 00:03:48,040 They sit in your building, use your network, 104 00:03:48,040 --> 00:03:49,640 and store data locally. 105 00:03:49,640 --> 00:03:51,480 Azure local runs on those servers 106 00:03:51,480 --> 00:03:55,200 and gives them a more Azure-like way to run and manage local workloads. 107 00:03:55,200 --> 00:03:57,400 Think of an Azure region as a large main office. 108 00:03:57,400 --> 00:03:59,160 It has huge amounts of compute, storage, 109 00:03:59,160 --> 00:04:01,520 and services available to customers across an area. 110 00:04:01,520 --> 00:04:04,360 Azure local is more like a smaller office building on your own site. 111 00:04:04,360 --> 00:04:07,160 Your team owns the building and the equipment inside it. 112 00:04:07,160 --> 00:04:09,680 But many of the rules, signs, security checks, 113 00:04:09,680 --> 00:04:12,800 and maintenance plans come from the same central organization. 114 00:04:12,800 --> 00:04:14,800 The work still happens in your smaller building. 115 00:04:14,800 --> 00:04:16,280 That distinction matters. 116 00:04:16,280 --> 00:04:19,760 Azure local doesn't copy all of public Azure into a rack of servers. 117 00:04:19,760 --> 00:04:22,320 You don't suddenly get every Azure service running locally 118 00:04:22,320 --> 00:04:24,200 just because you installed Azure local. 119 00:04:24,200 --> 00:04:27,120 Public Azure remains the place for the full range of cloud services 120 00:04:27,120 --> 00:04:28,600 and large-scale capacity. 121 00:04:28,600 --> 00:04:32,080 Azure local gives you a local platform for the workloads that need to run there. 122 00:04:32,080 --> 00:04:34,000 You may also hear a familiar older name. 123 00:04:34,000 --> 00:04:37,640 Azure Stack HCI, that's now part of the Azure local story. 124 00:04:37,640 --> 00:04:40,920 If you've seen that name in older articles, training, or diagrams, 125 00:04:40,920 --> 00:04:42,600 you're looking at much of the same foundation. 126 00:04:42,600 --> 00:04:45,240 Microsoft now uses Azure local as the broader name 127 00:04:45,240 --> 00:04:48,320 for this Azure connected infrastructure running at your site. 128 00:04:48,320 --> 00:04:50,200 So what stays at your site? 129 00:04:50,200 --> 00:04:51,840 The physical servers stay there. 130 00:04:51,840 --> 00:04:53,640 The compute power stays there too. 131 00:04:53,640 --> 00:04:57,280 The processor and memory that run your applications are in your own building, 132 00:04:57,280 --> 00:04:58,760 not in an Azure region. 133 00:04:58,760 --> 00:05:00,400 Storage stays local as well. 134 00:05:00,400 --> 00:05:04,000 The disks inside those servers hold the data for local virtual machines and workloads. 135 00:05:04,000 --> 00:05:08,840 Networking stays at the site, connecting your local systems, users, machines, and devices. 136 00:05:08,840 --> 00:05:11,520 On top of that local foundation, you can run virtual machines. 137 00:05:11,520 --> 00:05:14,120 A virtual machine is simply a software-based computer. 138 00:05:14,120 --> 00:05:17,920 You can run Windows or Linux inside it, much like a normal server 139 00:05:17,920 --> 00:05:21,120 without needing one separate physical box for every application. 140 00:05:21,120 --> 00:05:23,880 You can also run containers, containers package and application, 141 00:05:23,880 --> 00:05:26,640 and the parts it needs so it can run in a consistent way. 142 00:05:26,640 --> 00:05:30,040 They're useful when teams build and release modern applications more often. 143 00:05:30,040 --> 00:05:32,800 The processing stays close to the local systems that need it, 144 00:05:32,800 --> 00:05:35,080 but Azure local doesn't work alone in a corner. 145 00:05:35,080 --> 00:05:36,760 It connects back to Azure for management. 146 00:05:36,760 --> 00:05:40,280 That connection gives your team a familiar place to see the local environment, 147 00:05:40,280 --> 00:05:44,800 track its health, apply supported updates, and use Azure-based monitoring and security tools. 148 00:05:44,800 --> 00:05:49,320 You can apply policies from Azure so the same rules can check local systems and cloud systems. 149 00:05:49,320 --> 00:05:52,880 You can control access through the Azure tools your team already knows. 150 00:05:52,880 --> 00:05:56,400 You can also see billing for the Azure local service through your Azure subscription. 151 00:05:56,400 --> 00:05:58,520 Notice the split, the workload runs locally. 152 00:05:58,520 --> 00:06:00,800 The physical hardware remains your responsibility. 153 00:06:00,800 --> 00:06:03,840 Azure provides the management experience around that local platform, 154 00:06:03,840 --> 00:06:08,680 along with services that help you monitor, secure, update, and govern it. 155 00:06:08,680 --> 00:06:12,080 That's why calling Azure local Azure in a box creates the wrong picture. 156 00:06:12,080 --> 00:06:14,640 It isn't a miniature public cloud delivered to your site. 157 00:06:14,640 --> 00:06:18,360 It's a way to run local infrastructure with a closer connection to Azure. 158 00:06:18,360 --> 00:06:20,920 To see how that works, we need to look at three building blocks 159 00:06:20,920 --> 00:06:26,040 behind the local office building, the approved hardware, the local cluster, and Azure Arc. 160 00:06:26,040 --> 00:06:27,840 The building blocks behind the scenes. 161 00:06:27,840 --> 00:06:29,640 The first building block is the hardware. 162 00:06:29,640 --> 00:06:33,040 Azure local runs on service systems that have been tested and approved for it. 163 00:06:33,040 --> 00:06:35,520 You'll often hear these called validated hardware, 164 00:06:35,520 --> 00:06:38,840 validated nodes, integrated systems, or partner solutions. 165 00:06:38,840 --> 00:06:41,320 That testing is more useful than it may sound. 166 00:06:41,320 --> 00:06:46,680 A server platform includes processes, memory disks, network cards, storage controllers, drivers, and firmware. 167 00:06:46,680 --> 00:06:50,840 Each part needs to work correctly with the others, especially when several servers share storage 168 00:06:50,840 --> 00:06:52,680 and run business workloads together. 169 00:06:52,680 --> 00:06:56,440 Without testing, an update to one network driver or storage component 170 00:06:56,440 --> 00:06:58,000 can create a difficult problem. 171 00:06:58,000 --> 00:07:01,840 The server may still turn on, but the cluster may not behave the way you expect. 172 00:07:01,840 --> 00:07:04,080 Validated hardware reduces that guesswork. 173 00:07:04,080 --> 00:07:07,480 Microsoft and the hardware partner test supported combinations. 174 00:07:07,480 --> 00:07:12,280 So there's a known path for the server software, firmware, storage, and network parts. 175 00:07:12,280 --> 00:07:15,840 You still need to plan the size, location, network, and support model, 176 00:07:15,840 --> 00:07:19,560 but you're not starting with a pile of parts and hoping they work well together. 177 00:07:19,560 --> 00:07:21,560 Then comes the local infrastructure design. 178 00:07:21,560 --> 00:07:25,680 Azure local uses something called HCI, short for hyper-converge infrastructure. 179 00:07:25,680 --> 00:07:27,920 That name sounds technical, so let's put it in plain English. 180 00:07:27,920 --> 00:07:31,520 All the data centers often kept compute and storage in separate places. 181 00:07:31,520 --> 00:07:35,520 You might have one group of servers that ran applications, then a separate large storage 182 00:07:35,520 --> 00:07:38,480 system where all the files and virtual machine disks lived. 183 00:07:38,480 --> 00:07:43,280 The two systems connected over a storage network and each needed its own setup, updates, and care. 184 00:07:43,280 --> 00:07:45,320 HCI combines those jobs. 185 00:07:45,320 --> 00:07:48,440 The same group of servers provides compute power and storage. 186 00:07:48,440 --> 00:07:52,080 Each server contributes processor power, memory, and local disks. 187 00:07:52,080 --> 00:07:54,840 Together they become a shared platform for running workloads. 188 00:07:54,840 --> 00:07:57,000 Think of a small team doing one shared job. 189 00:07:57,000 --> 00:08:01,480 Each person brings different tools, but they work from the same plan and share the load. 190 00:08:01,480 --> 00:08:04,920 If one person needs to step away, the others can keep the job moving. 191 00:08:04,920 --> 00:08:06,400 A cluster works in a similar way. 192 00:08:06,400 --> 00:08:09,680 A cluster is a group of servers connected so they can act as one platform. 193 00:08:09,680 --> 00:08:14,200 When the design includes more than one server, workloads can move or restart on another server 194 00:08:14,200 --> 00:08:15,720 if one server has a problem. 195 00:08:15,720 --> 00:08:19,880 The cluster also spreads stored data across the servers based on the setup you choose. 196 00:08:19,880 --> 00:08:22,040 That doesn't mean every failure disappears. 197 00:08:22,040 --> 00:08:26,760 You still need enough servers, enough storage space, and a design that fits the level of downtime 198 00:08:26,760 --> 00:08:28,120 your business can accept. 199 00:08:28,120 --> 00:08:32,280 But clustering gives local workloads a better chance to stay available when one physical server 200 00:08:32,280 --> 00:08:34,040 needs maintenance or fails. 201 00:08:34,040 --> 00:08:37,040 Under the covers, Hyper-V helps run the virtual machines. 202 00:08:37,040 --> 00:08:41,720 Hyper-V is Microsoft's technology for creating and running those software-based computers. 203 00:08:41,720 --> 00:08:44,640 A local application might run inside a Windows Virtual Machine. 204 00:08:44,640 --> 00:08:45,920 Another may run inside Linux. 205 00:08:45,920 --> 00:08:50,280 Each gets the CPU, memory, disk, and network access it needs from the cluster. 206 00:08:50,280 --> 00:08:54,160 The local disks across the servers can also work together as shared storage. 207 00:08:54,160 --> 00:08:58,160 Instead of treating every disk as a separate island, Azure local pulls the local disks into 208 00:08:58,160 --> 00:09:00,160 storage that the cluster can use. 209 00:09:00,160 --> 00:09:04,480 That lets virtual machines run from storage spread across the servers rather than tying a workload 210 00:09:04,480 --> 00:09:06,280 to just one machine and one disk. 211 00:09:06,280 --> 00:09:09,080 So far, we have the physical foundation and the local platform. 212 00:09:09,080 --> 00:09:11,200 The next part explains how it appears in Azure. 213 00:09:11,200 --> 00:09:12,440 That part is Azure Arc. 214 00:09:12,440 --> 00:09:16,880 Azure Arc connects resources outside public Azure to the Azure portal and Azure management 215 00:09:16,880 --> 00:09:17,880 tools. 216 00:09:17,880 --> 00:09:21,440 It can connect servers, Kubernetes clusters, and other supported resources whether they 217 00:09:21,440 --> 00:09:24,120 run in your building or in another cloud. 218 00:09:24,120 --> 00:09:26,720 Arc doesn't move those resources into an Azure region. 219 00:09:26,720 --> 00:09:31,440 A server can remain in your server room, but show up in the Azure portal as a managed resource. 220 00:09:31,440 --> 00:09:35,720 Your team can use Azure access controls, tags, policies, monitoring, and security services 221 00:09:35,720 --> 00:09:37,840 against it depending on what you set up. 222 00:09:37,840 --> 00:09:40,440 This is where people often mix up Arc and Azure local. 223 00:09:40,440 --> 00:09:41,760 Azure Arc is the management layer. 224 00:09:41,760 --> 00:09:46,560 It can connect many kinds of existing infrastructure to Azure, including systems that aren't Azure 225 00:09:46,560 --> 00:09:47,560 local at all. 226 00:09:47,560 --> 00:09:50,720 Arc helps you see and manage those systems in a more consistent way. 227 00:09:50,720 --> 00:09:52,560 Azure local is the infrastructure platform. 228 00:09:52,560 --> 00:09:56,400 It provides the tested local hardware and clustered software foundation where your virtual 229 00:09:56,400 --> 00:10:00,320 machines, containers, and selected Azure services can actually run. 230 00:10:00,320 --> 00:10:03,960 Arc connects that foundation to the Azure control plane, think of the Azure control plane 231 00:10:03,960 --> 00:10:05,760 as the shared operations desk. 232 00:10:05,760 --> 00:10:09,560 It gives your team one place to control who can manage resources through enter ID, check 233 00:10:09,560 --> 00:10:14,440 rules with Azure policy, watch health through Azure monitor, and use Defender to look for security 234 00:10:14,440 --> 00:10:15,440 concerns. 235 00:10:15,440 --> 00:10:20,080 It also supports updates and automation across resources in Azure and at local sites. 236 00:10:20,080 --> 00:10:23,280 On top of Azure local you can run Windows and Linux virtual machines. 237 00:10:23,280 --> 00:10:26,320 You can run Azure Kubernetes service for container-based applications. 238 00:10:26,320 --> 00:10:30,520 You can run Azure virtual desktop workloads locally when users or data need that nearby 239 00:10:30,520 --> 00:10:31,560 performance. 240 00:10:31,560 --> 00:10:35,000 Some services that work with Azure Arc can also run close to the workload. 241 00:10:35,000 --> 00:10:39,400 The same Azure experience becomes far more useful when you have many locations. 242 00:10:39,400 --> 00:10:42,240 Managing one small site with local tools may be manageable. 243 00:10:42,240 --> 00:10:46,320 Managing 50 factories, 200 stores, or a fleet of remote sites quickly becomes a different 244 00:10:46,320 --> 00:10:47,320 problem. 245 00:10:47,320 --> 00:10:50,440 It changes the daily work for the people responsible for all of it. 246 00:10:50,440 --> 00:10:52,440 One control plane, local workloads. 247 00:10:52,440 --> 00:10:55,560 The real benefit shows up when teams stop working in separate worlds. 248 00:10:55,560 --> 00:11:01,120 In many companies, the cloud team uses Azure tools, Azure access rules, and Azure monitoring, 249 00:11:01,120 --> 00:11:04,720 while the local infrastructure team works through a separate set of consoles, spreadsheets, 250 00:11:04,720 --> 00:11:06,680 and server-by-server processes. 251 00:11:06,680 --> 00:11:07,880 That split creates gaps. 252 00:11:07,880 --> 00:11:13,160 A cloud admin might see an application in Azure, but not the local server supporting a site. 253 00:11:13,160 --> 00:11:17,640 Meanwhile, a local admin knows a server needs attention, but has no easy way to apply the 254 00:11:17,640 --> 00:11:19,920 same security rules used elsewhere. 255 00:11:19,920 --> 00:11:23,600 With Azure local, the cluster appears in the Azure portal as an Azure resource. 256 00:11:23,600 --> 00:11:28,520 You can see its name, location, health status, and alerts alongside other resources. 257 00:11:28,520 --> 00:11:34,000 And apply tags like factory, store 42, production, or a cost center so people can find and sort 258 00:11:34,000 --> 00:11:35,960 systems consistently. 259 00:11:35,960 --> 00:11:37,280 Access follows the same pattern. 260 00:11:37,280 --> 00:11:40,320 Instead of sharing a local administrator password with everyone who needs access, you 261 00:11:40,320 --> 00:11:44,880 use Microsoft Enter ID to decide who can manage the Azure local environment. 262 00:11:44,880 --> 00:11:48,520 One person might only view health details, another might manage virtual machines, and a smaller 263 00:11:48,520 --> 00:11:50,240 group controls the platform itself. 264 00:11:50,240 --> 00:11:53,800 That creates clearer ownership, picture a team that needs a new virtual machine for an 265 00:11:53,800 --> 00:11:55,720 application at a factory. 266 00:11:55,720 --> 00:11:59,680 Rather than treating the factory as a completely separate world, they use familiar Azure tools 267 00:11:59,680 --> 00:12:03,920 to create the virtual machine, choose its local network and storage, then run it on the 268 00:12:03,920 --> 00:12:06,120 Azure local cluster at that factory. 269 00:12:06,120 --> 00:12:09,120 The request begins in Azure, but the workload runs at the site. 270 00:12:09,120 --> 00:12:10,640 The same idea applies to containers. 271 00:12:10,640 --> 00:12:14,680 A developer can deploy a container-based application through familiar Azure connected tools while 272 00:12:14,680 --> 00:12:18,080 the container does its work close to the local devices and data. 273 00:12:18,080 --> 00:12:22,560 This helps teams keep one way of working even when workloads run in different places. 274 00:12:22,560 --> 00:12:24,760 Security and governance follow that same path. 275 00:12:24,760 --> 00:12:26,720 Enter ID controls who gets access. 276 00:12:26,720 --> 00:12:30,320 Azure policy checks whether systems follow the rules your company has set. 277 00:12:30,320 --> 00:12:34,800 For example, whether certain settings are in place or resources follow naming and tagging 278 00:12:34,800 --> 00:12:35,960 rules. 279 00:12:35,960 --> 00:12:40,160 Microsoft Defender watches for security concerns while Azure Monitor collects health signals 280 00:12:40,160 --> 00:12:42,320 and raises alerts when something needs attention. 281 00:12:42,320 --> 00:12:44,520 None of that removes the need for people to respond. 282 00:12:44,520 --> 00:12:48,720 It gives them a more consistent view, so they don't need to jump between unrelated tools 283 00:12:48,720 --> 00:12:51,960 just to understand what is happening at one site. 284 00:12:51,960 --> 00:12:53,320 Updates are another practical example. 285 00:12:53,320 --> 00:12:56,360 A local cluster includes more than one piece of software. 286 00:12:56,360 --> 00:13:00,320 The Azure local software itself plus the hardware drivers and firmware that need to work 287 00:13:00,320 --> 00:13:01,480 with it. 288 00:13:01,480 --> 00:13:05,920 On supported hardware, Azure local helps coordinate platform updates across those parts. 289 00:13:05,920 --> 00:13:10,480 Where the cluster design allows it, workloads can move from one server to another while a server 290 00:13:10,480 --> 00:13:14,680 receives an update reducing disruption, but that doesn't mean updates are magic or risk-free. 291 00:13:14,680 --> 00:13:18,040 Teams still need a maintenance plan testing and a clear understanding of which workloads 292 00:13:18,040 --> 00:13:19,040 can move. 293 00:13:19,040 --> 00:13:21,920 Azure local doesn't remove the real work of owning local equipment. 294 00:13:21,920 --> 00:13:25,800 Someone still needs to plan capacity before storage fills up, design the network, arrange 295 00:13:25,800 --> 00:13:31,360 backup and recovery, replace failed hardware, and decide who responds when a site has a problem. 296 00:13:31,360 --> 00:13:34,120 Azure local brings cloud style management closer to the site. 297 00:13:34,120 --> 00:13:35,520 It doesn't remove the site. 298 00:13:35,520 --> 00:13:38,960 The next question is where that local control changes the answer. 299 00:13:38,960 --> 00:13:43,200 From a factory floor to a retail store, a lab, or a place that cannot connect to the public 300 00:13:43,200 --> 00:13:44,880 cloud at all. 301 00:13:44,880 --> 00:13:47,080 Where Azure local fits and where it doesn't. 302 00:13:47,080 --> 00:13:49,240 A factory is one of the clearest examples. 303 00:13:49,240 --> 00:13:53,880 Cameras inspect products as they move down a line, sensors measure heat, vibration, pressure, 304 00:13:53,880 --> 00:13:58,680 or speed, and a local application can spot a defect, want a worker, or stop a machine 305 00:13:58,680 --> 00:14:03,080 before a small problem turns into wasted material or damaged equipment. 306 00:14:03,080 --> 00:14:06,560 Network happens at the site, close to the machines, and the data they create. 307 00:14:06,560 --> 00:14:09,160 Retail has a similar need even though it looks very different. 308 00:14:09,160 --> 00:14:13,640 A store may run checkout systems, inventory tools, cameras, and local AI that helps staff 309 00:14:13,640 --> 00:14:16,680 notice an empty shelf or a problem at a self checkout lane. 310 00:14:16,680 --> 00:14:21,440 If the wide area connection becomes slow or drops out, the store still needs to serve customers. 311 00:14:21,440 --> 00:14:25,520 Azure local gives that site a place to run those workloads locally while keeping a familiar 312 00:14:25,520 --> 00:14:28,080 Azure connection for the people who manage many stores. 313 00:14:28,080 --> 00:14:31,520 Healthcare and research labs add another reason, sensitive data. 314 00:14:31,520 --> 00:14:35,600 A hospital may process medical images close to the department that creates them and a lab 315 00:14:35,600 --> 00:14:39,560 may work with large research files that are difficult, expensive, or restricted to move 316 00:14:39,560 --> 00:14:40,720 elsewhere. 317 00:14:40,720 --> 00:14:44,720 The data can remain at the site while local systems process it and teams can decide later 318 00:14:44,720 --> 00:14:48,520 what information is safe and useful to share outside that location. 319 00:14:48,520 --> 00:14:51,320 Government energy and defense environments can take this even further. 320 00:14:51,320 --> 00:14:55,880 A power site may need local systems to watch equipment and react during a network outage, 321 00:14:55,880 --> 00:15:00,840 a government department may need data to remain within a tightly controlled location, 322 00:15:00,840 --> 00:15:05,160 and a defense environment may operate on a network that never connects to public Azure 323 00:15:05,160 --> 00:15:06,160 at all. 324 00:15:06,160 --> 00:15:07,800 That last case needs a different approach. 325 00:15:07,800 --> 00:15:11,200 Azure local can support disconnected operations for environments that are built to state 326 00:15:11,200 --> 00:15:12,200 disconnected. 327 00:15:12,200 --> 00:15:16,400 Instead of relying on a live connection to the public Azure control plane, the site uses 328 00:15:16,400 --> 00:15:20,040 a local control plane for a limited set of tasks and services. 329 00:15:20,040 --> 00:15:21,040 There is a trade-off. 330 00:15:21,040 --> 00:15:25,160 You don't get the full set of Azure services at the site and updates don't simply arrive 331 00:15:25,160 --> 00:15:26,480 across the internet. 332 00:15:26,480 --> 00:15:30,320 Teams prepare updates and licensing material outside the secure environment, then bring 333 00:15:30,320 --> 00:15:32,440 them into the site through an approved process. 334 00:15:32,440 --> 00:15:36,920 That takes planning, but it gives the organization control over exactly what enters the environment. 335 00:15:36,920 --> 00:15:40,280 So when should you consider as your local look for five signals? 336 00:15:40,280 --> 00:15:42,120 Does the workload need a very fast response? 337 00:15:42,120 --> 00:15:44,240 Does the data need to stay in a specific place? 338 00:15:44,240 --> 00:15:46,960 Do legal or company rules limit where the data can go? 339 00:15:46,960 --> 00:15:49,600 Must the site keep working when connectivity fails? 340 00:15:49,600 --> 00:15:53,760 Or does the organization need direct control over the local systems that run the workload? 341 00:15:53,760 --> 00:15:57,800 If the answer is yes to one or more of those questions, Azure local may fit, but it 342 00:15:57,800 --> 00:16:00,040 isn't the right answer for every application. 343 00:16:00,040 --> 00:16:04,120 A simple web app that already runs well in public Azure may not need local servers at all, 344 00:16:04,120 --> 00:16:08,800 a very small workload may not justify buying, maintaining and replacing physical equipment, 345 00:16:08,800 --> 00:16:12,880 and if a team doesn't want responsibility for hardware, local networking power, cooling 346 00:16:12,880 --> 00:16:16,640 and site support, then as your local creates work, they may not want. 347 00:16:16,640 --> 00:16:18,120 The goal isn't to put everything local. 348 00:16:18,120 --> 00:16:22,400 The goal is to put each workload in the place where it can do its job properly. 349 00:16:22,400 --> 00:16:25,760 That brings us to the most useful way to start the conversation. 350 00:16:25,760 --> 00:16:27,880 Start with the workload, not the hardware. 351 00:16:27,880 --> 00:16:31,560 Because your local is designed to keep your workloads running right where they are, while 352 00:16:31,560 --> 00:16:34,800 bringing Azure's management tools closer to that location. 353 00:16:34,800 --> 00:16:39,200 Before you start looking at server models or cluster sizes, ask yourself three questions. 354 00:16:39,200 --> 00:16:40,200 Where does the data begin? 355 00:16:40,200 --> 00:16:42,680 How fast does the system need to make a decision? 356 00:16:42,680 --> 00:16:46,480 And can that site rely on a working connection when that decision needs to happen? 357 00:16:46,480 --> 00:16:50,200 Then make a list of workloads that can't leave the site and write down the reason beside 358 00:16:50,200 --> 00:16:54,400 each one, whether it's speed, data rules, reliability or direct local control. 359 00:16:54,400 --> 00:16:58,640 If your first need is just managing servers you already have, start with Azure Arc. 360 00:16:58,640 --> 00:17:02,600 If you also need a local platform to run those workloads on tested hardware, then as your 361 00:17:02,600 --> 00:17:03,920 local is the next step. 362 00:17:03,920 --> 00:17:07,840 Here's the thing, if a factory stops working when the internet drops, a cloud-only design 363 00:17:07,840 --> 00:17:09,920 has already put that workload in the wrong place.