WEBVTT 1 00:00:00.080 --> 00:00:02.359 You know, usually when we talk about building something, there's 2 00:00:02.399 --> 00:00:05.360 this I mean, there's a physical reality that we all 3 00:00:05.400 --> 00:00:08.919 just kind of accept. Right. You pour a concrete foundation, 4 00:00:09.320 --> 00:00:12.400 you frame the walls, and the building just sits there. Right. 5 00:00:12.519 --> 00:00:14.599 Yeah, it takes up space, exactly. 6 00:00:14.640 --> 00:00:16.480 It's a permanent fixture in the environment. 7 00:00:16.679 --> 00:00:19.199 It's completely bound by physics. I mean, you can't just 8 00:00:19.239 --> 00:00:22.760 magically duplicate a physical skyscraper just because you know, the 9 00:00:22.839 --> 00:00:24.679 line at the coffee shop downstairs got. 10 00:00:24.559 --> 00:00:27.679 A little too long, right exactly. But then, and this 11 00:00:27.800 --> 00:00:30.879 is what's so wild. You step into the world of 12 00:00:30.960 --> 00:00:36.240 modern cloud computing and suddenly that whole physical reality gets 13 00:00:36.280 --> 00:00:37.799 turned completely upside down. 14 00:00:37.960 --> 00:00:38.119 Oh. 15 00:00:38.159 --> 00:00:41.439 Absolutely, We're looking at this architectural landscape where a building 16 00:00:41.479 --> 00:00:45.079 can literally duplicate itself when a crowd shows up, or 17 00:00:45.280 --> 00:00:47.640 you know, a room can only exist for the exact 18 00:00:47.679 --> 00:00:51.399 microsecond you step into it and then poof, it vanishes 19 00:00:51.439 --> 00:00:52.000 without a trace. 20 00:00:52.119 --> 00:00:54.799 Yeah. I mean that is the absolute definition of elastic 21 00:00:54.840 --> 00:00:58.960 infrastructure and really shifting your mindset to understand that elasticity 22 00:00:59.200 --> 00:01:02.479 that's the core to modern software development. You aren't just 23 00:01:02.719 --> 00:01:07.280 renting computers anymore. You know, you're manipulating this massive global 24 00:01:07.280 --> 00:01:08.760 fabric of computing power. 25 00:01:08.959 --> 00:01:11.799 So to the learner listening right now today, we are 26 00:01:12.000 --> 00:01:15.719 fully ripping the lid off the Microsoft Azure architecture. We 27 00:01:15.799 --> 00:01:18.159 want to show you exactly how the modern Internet scales 28 00:01:18.239 --> 00:01:20.319 up without just completely crashing. 29 00:01:20.400 --> 00:01:22.079 Yeah, it's a huge topic, it is. 30 00:01:22.319 --> 00:01:24.719 And we're pulling our insights today from a really highly 31 00:01:24.760 --> 00:01:28.599 technical manual. It's the exam ref AZ two four Developing 32 00:01:28.640 --> 00:01:32.879 Solutions for Microsoft Azure by Santiago Fernandez Munos. But and 33 00:01:32.920 --> 00:01:35.239 I want to be really clear right up front here, 34 00:01:36.079 --> 00:01:38.439 while this source is technically a study guide for a 35 00:01:38.480 --> 00:01:42.599 Microsoft certification, our mission for this deep dive is much 36 00:01:42.680 --> 00:01:44.640 much bigger than just rote memorization. 37 00:01:44.760 --> 00:01:46.640 Definitely, we are really looking for. 38 00:01:46.599 --> 00:01:49.400 The underlying philosophy here. Whether you're prepping for a massive 39 00:01:49.439 --> 00:01:52.239 meeting with a dev team or you're just insanely curious 40 00:01:52.239 --> 00:01:54.439 about how this stuff works. We want to give you 41 00:01:54.439 --> 00:01:59.319 a masterclass in cloud mechanics without all the overwhelming jargon. 42 00:01:59.239 --> 00:02:02.439 Right because we're really going to decode the evolution of 43 00:02:02.480 --> 00:02:06.079 hosting itself. We want to understand the actual mechanisms behind 44 00:02:06.079 --> 00:02:10.080 the cloud because well, once you grasp the underlying logic, 45 00:02:10.199 --> 00:02:12.400 the why, and the how, you don't just know how 46 00:02:12.400 --> 00:02:15.240 to use a platform like Azure, Yeah, you actually know 47 00:02:15.240 --> 00:02:17.080 how to architect for it exactly. 48 00:02:17.560 --> 00:02:19.960 So let's get our hands dirty here. Let's start at 49 00:02:20.000 --> 00:02:23.400 the very bottom of the cloud pyramid, which is infrastructure 50 00:02:23.400 --> 00:02:27.199 as a service or I and the classic virtual. 51 00:02:26.919 --> 00:02:27.919 Machine the foundation. 52 00:02:28.280 --> 00:02:31.599 Right. This is where Azure essentially gives you the raw 53 00:02:31.639 --> 00:02:35.240 compute hardware, but you are the one bringing the operating system, 54 00:02:35.400 --> 00:02:38.599 like whether that's Windows server or a Linux distribution. You're 55 00:02:38.639 --> 00:02:41.960 responsible for the patching, the maintenance, all the security stuff. 56 00:02:42.199 --> 00:02:44.439 It's really like building a house from scratch. 57 00:02:44.240 --> 00:02:46.639 It really is. It's the most direct translation of a 58 00:02:46.680 --> 00:02:51.120 traditional you know, on premises data center straight into the cloud. Okay, 59 00:02:51.159 --> 00:02:53.000 And because it is so close to the bear metal, 60 00:02:53.159 --> 00:02:56.560 you run into some very rigid physical rules, like, for instance, 61 00:02:56.639 --> 00:03:01.680 naming constraints. Windows VM names are strictly limited to fifteen characters. 62 00:03:01.759 --> 00:03:03.639 We really just fifteen, yep. 63 00:03:03.639 --> 00:03:08.080 Fifteen characters. And then there are subscription limits too. By default, 64 00:03:08.360 --> 00:03:11.599 Azure puts a quota of twenty vms per region on 65 00:03:11.639 --> 00:03:15.199 your account. Oh wow, yeah, I mean you can request more, 66 00:03:15.240 --> 00:03:17.199 but out of the gate, that's your limit. But the 67 00:03:17.240 --> 00:03:20.039 bigger thing is if you're deploying an enterprise application, you 68 00:03:20.080 --> 00:03:23.560 obviously want high availability, right right? Of course, if Microsoft 69 00:03:23.599 --> 00:03:26.840 has to reboot a server for say a hypervisor update, 70 00:03:27.280 --> 00:03:30.919 or if a physical rack literally loses power, your app 71 00:03:30.960 --> 00:03:33.759 cannot go down. So to achieve that in Azure you 72 00:03:33.800 --> 00:03:35.280 have to use an availability set. 73 00:03:35.439 --> 00:03:37.879 Okay, let's unpack this for a second. Yeah, because there 74 00:03:37.960 --> 00:03:41.240 is this incredibly unforgiving quark in Azure when it comes 75 00:03:41.280 --> 00:03:43.680 to availability sets. If I spin up a VM and 76 00:03:43.719 --> 00:03:45.520 I just, you know, forget to put it in an 77 00:03:45.560 --> 00:03:48.680 availability set on day one, I am entirely out of luck. 78 00:03:48.840 --> 00:03:50.719 Oh yeah, come like I have to literally tear the 79 00:03:50.759 --> 00:03:53.039 whole house down, delete it, and rebuild it from scratch. 80 00:03:53.240 --> 00:03:59.400 That seems completely unforgiving for a supposedly flexible modern cloud platform. 81 00:03:59.520 --> 00:04:01.479 I mean, why can't I just drag and drop a 82 00:04:01.560 --> 00:04:03.719 running VM into an availability set later. 83 00:04:04.000 --> 00:04:07.840 Well, what's fascinating here is that this limitation forces you 84 00:04:07.919 --> 00:04:11.520 to remember that the cloud isn't actually magic night. It's 85 00:04:11.520 --> 00:04:15.479 still made of physical servers, cables, and power supplies sitting 86 00:04:15.520 --> 00:04:19.360 in a massive warehouse somewhere. An availability set is basically 87 00:04:19.439 --> 00:04:23.040 a hard guarantee from Azure that your virtual machines will 88 00:04:23.040 --> 00:04:26.439 be distributed across different fault domains and update. 89 00:04:26.120 --> 00:04:28.319 Domains, meaning they're isolated from each other. 90 00:04:28.240 --> 00:04:32.800 Exactly, meaning they're physically wired to completely different power racks 91 00:04:32.800 --> 00:04:34.079 and different network switches. 92 00:04:34.160 --> 00:04:37.000 Oh I see, So when I hit create, Azure is 93 00:04:37.040 --> 00:04:39.639 literally out there looking at the physical floor plan of 94 00:04:39.680 --> 00:04:43.800 the data center to find two completely isolated hardware racks. 95 00:04:43.959 --> 00:04:48.360 Yes, Azure has to physically allocate space on specific servers 96 00:04:48.360 --> 00:04:51.319 at the exact moment of creation. If you decide a 97 00:04:51.319 --> 00:04:54.680 month later that, oh, actually I want high availability, Azure 98 00:04:54.680 --> 00:04:58.040 can't just magically teleport your running operating system with all 99 00:04:58.079 --> 00:05:00.759 its active memory and active network connections to a different 100 00:05:00.800 --> 00:05:04.000 physical rack across the building without a severe disruption. 101 00:05:04.120 --> 00:05:07.199 It makes told sense when you actually visualize the physical server. 102 00:05:07.040 --> 00:05:10.680 Room, right, the physical hardware dictates the software limitation. 103 00:05:10.920 --> 00:05:13.680 Got it? In speaking of that physical server room, Securing 104 00:05:13.720 --> 00:05:17.079 access to these machines relies really heavily on a zero 105 00:05:17.120 --> 00:05:21.000 trust architecture. We aren't just leaving remote access ports wide 106 00:05:21.040 --> 00:05:22.120 open to the public Internet. 107 00:05:22.240 --> 00:05:24.800 No, never. I mean leaving RDP on port three three 108 00:05:24.879 --> 00:05:27.920 eighty nine for Windows or SSH on port twenty two 109 00:05:27.959 --> 00:05:30.720 for Linux. Just exposed. That is a disaster waiting to happen. 110 00:05:30.879 --> 00:05:32.560 Just asking be hacked exactly. 111 00:05:32.839 --> 00:05:36.279 The standard practice outline is to utilize network security groups 112 00:05:36.360 --> 00:05:40.279 or nsgs to act as a highly granular firewall. You 113 00:05:40.360 --> 00:05:43.319 drop the vms into a virtual private network, you assign 114 00:05:43.360 --> 00:05:47.439 them private internal IPS, and you only expose the absolutely 115 00:05:47.519 --> 00:05:50.560 necessary traffic, like your web traffic to the outside world. 116 00:05:50.920 --> 00:05:55.279 Remote administrative access should always be routed through secure, private tunnels. 117 00:05:55.480 --> 00:05:57.800 Best practice is never use a public IP for a 118 00:05:57.839 --> 00:05:58.600 production VM. 119 00:05:58.920 --> 00:06:02.519 Okay, so we have our highly available, highly secure virtual machines, 120 00:06:02.839 --> 00:06:06.600 but we immediately hit a scalability bottleneck here clicking through 121 00:06:06.600 --> 00:06:11.920 Azure Portal menus. You manually configuring virtual networks, assigning private ipes, 122 00:06:11.920 --> 00:06:14.879 attaching nsgs for one server. That's fine, But what if 123 00:06:14.879 --> 00:06:18.120 I need to deploy this complex architecture of five hundred 124 00:06:18.160 --> 00:06:22.199 servers across three global regions. We obviously can't do that 125 00:06:22.480 --> 00:06:25.720 by hand. If building one VM is like building a house, 126 00:06:26.160 --> 00:06:29.480 how do we build an entire subdivision instantly without clicking 127 00:06:29.480 --> 00:06:30.399 through menus all day? 128 00:06:30.560 --> 00:06:34.199 Right? And this is where automation and infrastructure as code 129 00:06:34.199 --> 00:06:38.800 come in, specifically Azure Resource Manager or ARMED templates. They 130 00:06:38.839 --> 00:06:42.040 completely change the game. Okay, Instead of manual provisioning, you're 131 00:06:42.120 --> 00:06:45.839 rating a declarative blueprint in Jason a blueprint, right. You 132 00:06:45.920 --> 00:06:49.000 literally tell Azure here is the exact state I want 133 00:06:49.000 --> 00:06:51.759 my environment to be in, and Azure's orchestration engine just 134 00:06:51.800 --> 00:06:54.240 figures out how to build it. But it has a 135 00:06:54.399 --> 00:06:57.560 very strict mandatory structure. You have to include the dollar 136 00:06:57.600 --> 00:07:01.480 signed schema element, the content version, and the resources element. 137 00:07:01.639 --> 00:07:04.480 But looking at the mechanics of those JSON files, there's 138 00:07:04.519 --> 00:07:07.079 a massive trap in there, isn't there because as you're 139 00:07:07.160 --> 00:07:10.160 wants to be fast, so it naturally tries to deploy 140 00:07:10.199 --> 00:07:13.680 everything in your blueprint simultaneously, like in parallel. 141 00:07:13.240 --> 00:07:16.959 Yes, and that parallel execution will crash your deployment instantly 142 00:07:17.000 --> 00:07:21.000 if you aren't careful think about it. You cannot attach 143 00:07:21.079 --> 00:07:24.399 a virtual machine to a network interface if the virtual 144 00:07:24.439 --> 00:07:28.480 network itself hasn't been fully provisioned yet. The orchestration engine 145 00:07:28.639 --> 00:07:32.879 needs to know the exact mathematical dependency graph of your 146 00:07:32.959 --> 00:07:34.759 whole architecture. 147 00:07:34.120 --> 00:07:36.519 Which is why that depends on element in the ARM 148 00:07:36.600 --> 00:07:39.839 template is the absolute lynchpin of the whole operation. 149 00:07:40.160 --> 00:07:40.600 Exactly. 150 00:07:40.639 --> 00:07:43.720 You have to explicitly code that hierarchy. You have to 151 00:07:43.720 --> 00:07:46.920 tell the engine, hey, do not start building this network 152 00:07:46.920 --> 00:07:50.399 interface until the virtual network actually reports a successful build. 153 00:07:50.560 --> 00:07:55.040 It creates this perfectly orchestrated domino effect. ARM templates essentially 154 00:07:55.120 --> 00:07:59.040 let you stamp out identical environments in seconds. But even 155 00:07:59.079 --> 00:08:02.360 with those automated blueprints, we still have a really fundamental 156 00:08:02.360 --> 00:08:06.519 computing bottleneck because booting up a full virtual machine, loading 157 00:08:06.519 --> 00:08:10.079 the entire Windows kernel, initializing all the drivers, starting the 158 00:08:10.120 --> 00:08:12.000 background services, it takes minutes. 159 00:08:12.519 --> 00:08:14.839 Yeah, and in the cloud, waiting three minutes for a 160 00:08:14.879 --> 00:08:17.279 server to boot up during a huge traffic spike is 161 00:08:17.319 --> 00:08:18.439 just an absolute eternity. 162 00:08:18.480 --> 00:08:21.480 You lose customer exactly. So how do we shave that 163 00:08:21.519 --> 00:08:24.360 boot time down from minutes to mirror milliseconds. 164 00:08:24.680 --> 00:08:26.879 We stop booting the operating system. 165 00:08:26.680 --> 00:08:30.040 Entirely, precisely enter containerization, specifically Docker. 166 00:08:30.319 --> 00:08:34.720 Okay, So, if ARM templates are the architects blueprint and 167 00:08:34.799 --> 00:08:37.879 a virtual machine is like giving every single application its 168 00:08:37.919 --> 00:08:41.679 own private office building with its own dedicated plumbing, electricity, 169 00:08:41.679 --> 00:08:44.919 and a security desk, a container is like moving them 170 00:08:44.919 --> 00:08:48.440 all into a massive, prefab pop up co working space. Right. 171 00:08:48.720 --> 00:08:51.720 That is the perfect analogy for the mechanism at play here. 172 00:08:52.039 --> 00:08:55.200 Containers package up your application code and all its dependencies, 173 00:08:55.320 --> 00:08:57.840 but they do not contain a full operating system. They 174 00:08:57.879 --> 00:09:00.639 share it, right, They use a read only of the 175 00:09:00.679 --> 00:09:04.639 shared host machine's OS kernel, so they get their own secure, 176 00:09:04.759 --> 00:09:08.279 isolated workspace, but they use the underlying plumbing of the 177 00:09:08.320 --> 00:09:10.879 host because they don't have to boot a kernel. They 178 00:09:10.879 --> 00:09:12.440 start almost instantaneously. 179 00:09:12.600 --> 00:09:15.440 And you define that recipe using a docer file, You 180 00:09:15.480 --> 00:09:17.679 bake the image and then you store it in the 181 00:09:17.720 --> 00:09:19.159 Azure Container Registry or. 182 00:09:19.200 --> 00:09:21.000 ACR right private storage hub. 183 00:09:21.080 --> 00:09:24.720 And the text details this really specific tag structure for 184 00:09:24.799 --> 00:09:28.240 ACR right. It's the ACR name dot, azureka dot iro 185 00:09:28.480 --> 00:09:31.879 forward slash, the repository name colon the version. 186 00:09:32.159 --> 00:09:35.960 Yeah, that strict naming convention is how Azure knows exactly 187 00:09:36.039 --> 00:09:39.039 which container image to pull. Any server can pull that 188 00:09:39.120 --> 00:09:41.519 image and spin up the app in milliseconds. 189 00:09:42.000 --> 00:09:45.080 But and here's where it gets really interesting. Because containers 190 00:09:45.080 --> 00:09:48.159 are designed to be lightweight and ephemeral, they sort of 191 00:09:48.159 --> 00:09:52.080 have amnesia, right, Like, if a container crashes and restarts, 192 00:09:52.559 --> 00:09:55.799 any data written to its internal file system just vanishes. 193 00:09:56.480 --> 00:09:59.799 Doesn't that create a massive friction between developers who want 194 00:09:59.840 --> 00:10:04.399 the these fast, disposable pop up rooms and database admins 195 00:10:04.399 --> 00:10:07.399 who need to guarantee that data actually persists. 196 00:10:07.759 --> 00:10:10.799 This raises an important question about the philosophy of stateless 197 00:10:10.799 --> 00:10:16.240 applications versus stateful data persistence. Okay, containers practically force your 198 00:10:16.279 --> 00:10:18.840 dev team to decouple the data from the compute power. 199 00:10:19.200 --> 00:10:21.519 If you run a database inside a container and you 200 00:10:21.600 --> 00:10:24.799 just rely on its internal storage, you are fully flirting 201 00:10:24.799 --> 00:10:26.399 with disaster, right because. 202 00:10:26.200 --> 00:10:28.559 It wipes its memory clean on reboot exactly. 203 00:10:28.679 --> 00:10:31.120 The solution is to use external mount points, which are 204 00:10:31.120 --> 00:10:34.879 called volumes. You link those volumes to Azure files or 205 00:10:34.919 --> 00:10:39.039 Blob storage. So the container handles the compute logic, but 206 00:10:39.120 --> 00:10:42.320 it reads and writes to an external, permanent hard drive. 207 00:10:42.440 --> 00:10:45.200 Got it. So if the container dies, who cares? A 208 00:10:45.240 --> 00:10:47.480 new one just spins up in a millisecond, reconnects to 209 00:10:47.519 --> 00:10:49.799 that volume, and picks up right where the old one 210 00:10:49.879 --> 00:10:50.279 left off. 211 00:10:50.320 --> 00:10:54.200 The compute becomes completely disposable, while the data remains permanent 212 00:10:54.279 --> 00:10:54.960 and protected. 213 00:10:55.200 --> 00:10:57.600 That is brilliant, But let's be honest for a second. 214 00:10:57.840 --> 00:11:02.679 Managing container registries, writing all these complex arm templates, configuring 215 00:11:02.720 --> 00:11:06.200 the volumes, I mean we are still spending a massive 216 00:11:06.200 --> 00:11:09.840 amount of time managing the infrastructure instead of just writing code. 217 00:11:09.919 --> 00:11:10.919 It's a lot of overhead. 218 00:11:11.000 --> 00:11:12.720 Yeah, what if a company just wants to rent a 219 00:11:12.720 --> 00:11:16.159 fully managed luxury apartment where the building maintenance, the plumbing, 220 00:11:16.279 --> 00:11:19.799 the security, it's all entirely handled for you by Microsoft. 221 00:11:19.879 --> 00:11:23.159 That is the big transition from infrastructure as a service 222 00:11:23.440 --> 00:11:27.519 to platform as a service or pios. And in Azure, 223 00:11:27.679 --> 00:11:30.720 the flagship offering here is the Azure App service with 224 00:11:30.919 --> 00:11:34.919 pass the virtual machines, the load balancers, the OS passion. 225 00:11:35.000 --> 00:11:38.279 It's all completely abstracted away from you. You literally just 226 00:11:38.519 --> 00:11:40.600 upload your code and Azure runs it. 227 00:11:41.080 --> 00:11:43.320 But behind the scenes there is still an app service 228 00:11:43.360 --> 00:11:47.440 plan running right acting as this hidden server form powering 229 00:11:47.440 --> 00:11:50.480 the application. Yes, and depending on your pricing tier you 230 00:11:50.480 --> 00:11:52.759 get different hardware like the F one and D one 231 00:11:52.799 --> 00:11:55.399 tiers are just shared compute. Well S one and P 232 00:11:55.480 --> 00:11:58.600 one give you standard and premium dedicated resources exactly. 233 00:11:58.639 --> 00:12:01.480 And when you move to those and premium tiers you 234 00:12:01.600 --> 00:12:04.279 unlock some really incredible enterprise features. 235 00:12:04.320 --> 00:12:07.399 Deployment slots for example, oh Man deploy and slots are amazing. 236 00:12:07.679 --> 00:12:10.720 For anyone who has ever experienced the pure cold sweat 237 00:12:10.720 --> 00:12:13.759 of a deployment Friday, you know, prating the new code 238 00:12:13.759 --> 00:12:17.600 doesn't just completely break the live production site. Deployment slots 239 00:12:17.639 --> 00:12:20.360 are an absolute miracle. You really are you deploy your 240 00:12:20.360 --> 00:12:23.240 new code to a hidden staging slot. You test it 241 00:12:23.279 --> 00:12:26.279 thoroughly against the live production database, and when you are 242 00:12:26.279 --> 00:12:29.080 fully confident, you just click a button to swap the 243 00:12:29.120 --> 00:12:34.559 staging and production environments. Zero downtime. It cures deployment anxiety. 244 00:12:34.639 --> 00:12:38.519 It instantly reroutes the network traffic. It completely neutralizes the 245 00:12:38.559 --> 00:12:41.799 risk of a bad deployment. But you know, while PASSA 246 00:12:41.919 --> 00:12:46.480 hides all that complexity, it doesn't rewrite the laws of computing. True, 247 00:12:46.559 --> 00:12:49.879 there are still strict architectural boundaries you have to respect. 248 00:12:50.320 --> 00:12:54.120 For example, a really crucial limitation. Azure will not allow 249 00:12:54.120 --> 00:12:56.559 you to mix Linux and Windows web ats and the 250 00:12:56.639 --> 00:12:59.279 exact same resource group in the same region. 251 00:12:59.480 --> 00:13:02.759 Wait, hold on one. Microsoft calls this platform as a 252 00:13:02.799 --> 00:13:05.600 service and tells me not to worry about the infrastructure. 253 00:13:05.879 --> 00:13:07.639 But then they say, I can't put a Linux app 254 00:13:07.639 --> 00:13:09.559 and a Windows app in the same logical folder. 255 00:13:09.679 --> 00:13:12.039 I know it sounds counterintuitive, It feels. 256 00:13:11.720 --> 00:13:13.840 Like a marketing gimmick. If I'm still hitting these hard 257 00:13:13.960 --> 00:13:18.159 infrastructure walls, If Azure's doing all the heavy lifting, why 258 00:13:18.159 --> 00:13:20.960 do I care what underlying OS is running? Why can't 259 00:13:20.960 --> 00:13:21.600 I mix them? 260 00:13:21.720 --> 00:13:24.240 Well, if we connect this to the bigger picture. It 261 00:13:24.279 --> 00:13:28.279 all comes down to how Azure orchestrates its underlying management 262 00:13:28.320 --> 00:13:32.360 fabric resource groups. They aren't just decorative folders, They actually 263 00:13:32.440 --> 00:13:35.559 define the boundaries for the underlying infrastructure clusters. 264 00:13:35.679 --> 00:13:36.480 Oh, I see. 265 00:13:36.559 --> 00:13:42.320 Windows environments and Linux environments require fundamentally different hypervisor configurations, 266 00:13:42.519 --> 00:13:45.919 different orchestration layers, and different filesystem management. 267 00:13:46.159 --> 00:13:48.759 So even though I can't see the underlying virtual machines, 268 00:13:49.159 --> 00:13:53.039 Azure is still dedicating a specific cluster of Windows optimized 269 00:13:53.080 --> 00:13:56.559 infrastructure to my resource group. Okay, and mixing in a 270 00:13:56.600 --> 00:13:59.799 Linux app would just break the efficiency of that dedicated. 271 00:13:59.399 --> 00:14:03.799 Hardware cluster exactly. The abstraction is incredibly powerful, but it 272 00:14:03.879 --> 00:14:07.840 still relies on highly optimized homogeneous clusters at the hardware level. 273 00:14:07.919 --> 00:14:08.440 That makes sense. 274 00:14:08.480 --> 00:14:12.080 And speaking of optimization, there's a really fascinating mechanism in 275 00:14:12.120 --> 00:14:15.240 app services regarding configuration and memory management. 276 00:14:15.360 --> 00:14:16.559 Oh right, the app settings. 277 00:14:16.720 --> 00:14:19.799 Yeah, in Azure, the app settings you can figure in 278 00:14:19.840 --> 00:14:23.679 the portal actually override your hard coded web dot config 279 00:14:23.799 --> 00:14:25.600 or appsettings dot json. 280 00:14:25.279 --> 00:14:27.519 Files, which is so handy it is. 281 00:14:28.200 --> 00:14:32.320 And there's a specific naming convention for environment variables. For instance, 282 00:14:32.320 --> 00:14:35.279 if you're connecting a database in PHP r node Azure 283 00:14:35.279 --> 00:14:38.840 propens the variable with squasiria constr. 284 00:14:38.440 --> 00:14:40.960 Underscore squasyakin your underscore. 285 00:14:40.600 --> 00:14:43.960 Okay, And beyond just variables, there's how it manages memory. 286 00:14:44.679 --> 00:14:48.080 By default. If your web app sits idle like without 287 00:14:48.080 --> 00:14:51.200 any incoming web requests for about twenty or thirty minutes, 288 00:14:51.799 --> 00:14:56.159 Azure's management fabric will literally unload your application's worker process 289 00:14:56.240 --> 00:14:57.240 from the server's RAM. 290 00:14:57.399 --> 00:15:00.519 It just kicks it out because it's reclaiming the memory 291 00:15:00.559 --> 00:15:03.399 to save resources exactly. But wait, that means the next 292 00:15:03.399 --> 00:15:05.480 poor user who happens to click on your website has 293 00:15:05.519 --> 00:15:08.200 to wait for the entire application framework to boot back 294 00:15:08.279 --> 00:15:10.559 up into memory. It's a brutal cold. 295 00:15:10.279 --> 00:15:13.639 Start, yes, which is why enterprise deployments rely heavily on 296 00:15:13.679 --> 00:15:17.240 the always on setting. Always on it essentially pings your 297 00:15:17.279 --> 00:15:21.320 application continuously in the background. That forces the management fabric 298 00:15:21.360 --> 00:15:24.440 to keep the worker process active in RAM, which ensures 299 00:15:24.480 --> 00:15:26.879 instantaneous response times for real users. 300 00:15:27.200 --> 00:15:29.240 So we have our code running and passes. It's kept 301 00:15:29.240 --> 00:15:32.480 alive in memory with always on. It's highly optimized. But 302 00:15:32.600 --> 00:15:37.279 what happens when your company launches, say, a massive marketing campaign, 303 00:15:37.360 --> 00:15:39.960 right and suddenly your app is hit with a total 304 00:15:40.000 --> 00:15:43.600 tsunami of traffic, the CPU on your hidden app service 305 00:15:43.639 --> 00:15:46.440 plan spikes to ninety five percent. How do we survive 306 00:15:46.519 --> 00:15:47.080 that wave? 307 00:15:47.480 --> 00:15:50.879 We rely on the art of elasticity through autoscaling. Right 308 00:15:50.919 --> 00:15:55.080 and Architecturally, you have two distinct paths here, vertical scaling 309 00:15:55.200 --> 00:15:59.399 and horizontal scaling. Vertical scaling is essentially upgrading the hardware 310 00:15:59.559 --> 00:16:02.200 of your sisting server. You're scaling up and down by 311 00:16:02.200 --> 00:16:05.840 adding more RAM or faster CPU cores to that specific VM. 312 00:16:05.919 --> 00:16:09.360 I always picture vertical scaling like trying to add a 313 00:16:09.399 --> 00:16:11.799 second story to your house while you're currently eating dinner 314 00:16:11.840 --> 00:16:14.159 inside it. Exactly, you have to stop what you're doing, 315 00:16:14.440 --> 00:16:17.279 vacate the premises, wait for the construction crew to finish, 316 00:16:17.559 --> 00:16:22.279 and then move back in. In cloud terms, vertical scaling requires downtime. 317 00:16:23.039 --> 00:16:25.679 The application actually has to restart to recognize the new 318 00:16:25.679 --> 00:16:27.159 hardware configuration. 319 00:16:26.679 --> 00:16:30.039 Which makes it pretty useless for handling sudden, real time 320 00:16:30.159 --> 00:16:33.879 traffic spikes. You can't just go offline when everyone is 321 00:16:33.919 --> 00:16:36.480 trying to buy your product, right. That is why modern 322 00:16:36.519 --> 00:16:41.559 cloud architecture relies almost entirely on horizontal scaling. Instead of 323 00:16:41.559 --> 00:16:45.240 making the server bigger, you scale out, you clone it. 324 00:16:45.360 --> 00:16:47.679 You just instantly instantiate the house next door. 325 00:16:47.840 --> 00:16:52.039 Right, you dynamically add more identical instances of your application 326 00:16:52.120 --> 00:16:54.960 into a scale set, and a load balancer sits in 327 00:16:54.960 --> 00:16:58.799 front of them, seamlessly distributing the incoming web traffic across 328 00:16:58.840 --> 00:17:01.360 the new clones. Zero downtime. 329 00:17:01.480 --> 00:17:04.799 That's amazing. And you can configure these auto scaling rules 330 00:17:04.839 --> 00:17:07.920 in Azure right, like time based or metric based rules, 331 00:17:08.000 --> 00:17:10.599 or even custom ones. So you're basically telling it to 332 00:17:10.720 --> 00:17:13.960 monitor the CPU. The text used as a specific example, 333 00:17:14.359 --> 00:17:17.480 if the CPU crosses eighty percent for a sustained ten minutes, 334 00:17:17.960 --> 00:17:20.839 Azure automatically spins up another instance. Yep. But if you 335 00:17:20.920 --> 00:17:23.400 just configure that rule, aren't you walking into a massive 336 00:17:23.720 --> 00:17:24.680 financial trap? Oh? 337 00:17:24.720 --> 00:17:27.480 Absolutely. That brings us to the golden rule of autoscaling. 338 00:17:27.759 --> 00:17:30.519 If you can figure a scale out rule to dynamically 339 00:17:30.559 --> 00:17:35.640 add infrastructure during a spike, you absolutely must explicitly create 340 00:17:35.680 --> 00:17:37.559 a corresponding scale in rule. 341 00:17:38.200 --> 00:17:42.559 Because otherwise Azure will happily scale you up to fifty 342 00:17:42.599 --> 00:17:45.160 servers to handle the Super Bowl traffic. But when the 343 00:17:45.200 --> 00:17:48.319 game ends and the traffic drops to zero, if you 344 00:17:48.359 --> 00:17:50.720 don't have a scale in rule telling Azure to delete 345 00:17:50.759 --> 00:17:53.359 those extra forty nine servers. They will just sit there 346 00:17:53.440 --> 00:17:54.279 running forever. 347 00:17:54.240 --> 00:17:58.759 Just burning through your department's IT budget. It is a 348 00:17:58.799 --> 00:18:02.559 really painful lesson that many architects unfortunately learn the hard way. 349 00:18:02.880 --> 00:18:05.279 I can imagine, but wait, let's go back to the 350 00:18:05.319 --> 00:18:08.599 application itself for a second. I can't just horizontally clone 351 00:18:08.680 --> 00:18:11.920 a and Y legacy application and expect a load balancer 352 00:18:11.960 --> 00:18:14.720 to magically make it work. Like doesn't the app itself 353 00:18:14.759 --> 00:18:16.720 have to be built to handle that. If an app 354 00:18:16.799 --> 00:18:20.559 wasn't designed for elasticity, horizontal scaling could completely break it. 355 00:18:20.759 --> 00:18:23.680 That is a phenomenal observation, and it circles right back 356 00:18:23.720 --> 00:18:27.440 to our earlier discussion about stateful versus stateless design. I 357 00:18:27.759 --> 00:18:30.920 imagine an old school e commerce application that stores a 358 00:18:31.039 --> 00:18:34.960 user's shopping cart data directly in the server's RAM, what 359 00:18:35.000 --> 00:18:36.680 we call in memory session state. 360 00:18:36.799 --> 00:18:38.759 Right, So a user logs in, they put a laptop 361 00:18:38.799 --> 00:18:41.359 in their cart. The load balancer originally sent them to 362 00:18:41.359 --> 00:18:43.799 server A, so Server A remembers them exactly. 363 00:18:43.960 --> 00:18:46.799 But then they click check out the load balancer doing 364 00:18:46.839 --> 00:18:50.279 its job trying to distribute the traffic routes that second 365 00:18:50.319 --> 00:18:54.039 click to server B. Oh No, Server B has absolutely 366 00:18:54.039 --> 00:18:57.119 no idea who this user is, their shopping cart is empty, 367 00:18:57.160 --> 00:18:58.599 they're forced to log in again. 368 00:18:58.759 --> 00:19:02.000 Horizontal scaling just completely broke the user experience exactly. 369 00:19:02.119 --> 00:19:05.519 So to survive in an elastic cloud, applications must be 370 00:19:05.559 --> 00:19:09.400 completely stateless. They cannot hold session data in local memory. 371 00:19:09.480 --> 00:19:13.400 They have to externalize that state to a distributed high 372 00:19:13.480 --> 00:19:15.319 speed casting layer like reddis. 373 00:19:15.640 --> 00:19:18.440 Okay, so if the cart isn't reddus, it doesn't matter 374 00:19:18.440 --> 00:19:20.720 if the low balancer sends the user to server A, 375 00:19:21.039 --> 00:19:24.440 server B or server Z. Any cloned instance can just 376 00:19:24.880 --> 00:19:28.559 query the reddest cache, retrieve the shopping cart, and seamlessly 377 00:19:28.599 --> 00:19:30.799 process the transaction precisely. 378 00:19:31.039 --> 00:19:34.960 It's amazing how these architectural concepts all interlock, isn't it? 379 00:19:35.039 --> 00:19:39.880 The hardware availability, the container persistence, the horizontal elasticity. It 380 00:19:39.960 --> 00:19:43.240 all demands decoupling the data from the compute layer. 381 00:19:43.000 --> 00:19:46.319 Which naturally brings us to the ultimate evolution. In this journey, 382 00:19:46.720 --> 00:19:49.799 we went from building houses with IA to renting apartments 383 00:19:49.799 --> 00:19:52.920 of pie is to dynamically scaling those apartments. But in 384 00:19:53.039 --> 00:19:56.359 all those scenarios, you are still paying a baseline costs 385 00:19:56.440 --> 00:19:58.720 for a server to just sit there waiting for traffic. 386 00:19:59.000 --> 00:20:01.359 Right even with a pie us app service plan scaled 387 00:20:01.400 --> 00:20:03.559 all the way down to one instance at three am, 388 00:20:03.880 --> 00:20:06.240 you are still paying an hourly rate for that instance 389 00:20:06.279 --> 00:20:09.039 to exist. What if you just want a room that 390 00:20:09.119 --> 00:20:11.960 only exists the exact microsecond you step into it and 391 00:20:12.039 --> 00:20:14.279 vanishes when you leave. What if you only want to 392 00:20:14.279 --> 00:20:17.759 pay for the exact milliseconds your code is actively doing work. 393 00:20:18.119 --> 00:20:21.480 Welcome to serverlest computing. Yes, in Azure, this is the 394 00:20:21.519 --> 00:20:24.759 Azure functions ecosystem, and this is really the purest abstraction 395 00:20:24.799 --> 00:20:27.480 of computing. With an Azure function running on what they 396 00:20:27.480 --> 00:20:30.799 call a consumption plan, the entire concept of a dedicated 397 00:20:30.839 --> 00:20:35.160 server just disappears. The underlying management fabric only allocates compute 398 00:20:35.160 --> 00:20:38.079 power to your code when a specific event occurs. You 399 00:20:38.160 --> 00:20:41.519 are charged per second only when the code executes. If 400 00:20:41.519 --> 00:20:44.960 your code runs for two hundred milliseconds, you literally pay 401 00:20:45.079 --> 00:20:46.279