WEBVTT 1 00:00:00.160 --> 00:00:03.520 Imagine just for a second that you're running a massive 2 00:00:03.879 --> 00:00:05.559 global website. 3 00:00:05.200 --> 00:00:07.759 Right like a huge news platform or something. 4 00:00:07.480 --> 00:00:13.400 Exactly, and suddenly some totally unpredictable news event breaks. In 5 00:00:13.439 --> 00:00:16.559 the span of like two minutes, your traffic spikes by 6 00:00:16.600 --> 00:00:17.600 one thousand percent. 7 00:00:17.760 --> 00:00:19.920 Oh wow, Yeah, panic time right in. 8 00:00:19.879 --> 00:00:20.640 The Old Danes. 9 00:00:20.760 --> 00:00:23.120 And honestly, for a vast majority of the systems we 10 00:00:23.199 --> 00:00:26.160 still rely on today, you know exactly what happens next. 11 00:00:26.359 --> 00:00:29.920 The servers get overwhelmed, the request que fills up, the 12 00:00:30.039 --> 00:00:32.640 load balancer completely panics, and. 13 00:00:32.679 --> 00:00:34.960 Everyone trying to access your site just gets a blank 14 00:00:35.000 --> 00:00:35.600 white screen. 15 00:00:35.799 --> 00:00:38.679 Yeah, that generic error message And I mean every second 16 00:00:38.799 --> 00:00:41.719 that site is down is costing you money, your reputation, 17 00:00:41.960 --> 00:00:45.039 user trust, all of it. But and here's the hook. 18 00:00:45.880 --> 00:00:47.799 What if your software could sense that it was about 19 00:00:47.840 --> 00:00:51.560 to crash, diagnose the exact bottleneck in its own hardware, 20 00:00:51.799 --> 00:00:55.119 and completely rewrite its internal architecture to survive. 21 00:00:54.880 --> 00:00:56.479 That spike, just fix itself on the fly. 22 00:00:56.759 --> 00:00:57.320 Exactly. 23 00:00:57.600 --> 00:00:58.920 What if it could do all of that in a 24 00:00:58.920 --> 00:01:02.000 matter of milliseconds without a single human being ever even 25 00:01:02.039 --> 00:01:02.920 touching a keyboard. 26 00:01:03.520 --> 00:01:05.680 I mean, it sounds like we're talking about a living organism, right, 27 00:01:05.799 --> 00:01:09.640 Like something with a biological immune system that just heals 28 00:01:09.680 --> 00:01:10.719 itself when it gets a cut. 29 00:01:10.840 --> 00:01:11.519 It really does. 30 00:01:11.599 --> 00:01:14.000 But the reality is this isn't science fiction at all. 31 00:01:14.239 --> 00:01:18.680 We are already engineering digital systems that can do exactly this. 32 00:01:19.319 --> 00:01:23.000 Well, Welcome to today's deep dive. Today we are looking 33 00:01:23.040 --> 00:01:26.920 at a concept that fundamentally changes how we interact with technology. 34 00:01:27.079 --> 00:01:31.280 It's called autonomic computing. It's a fascinating space, it really is, 35 00:01:31.359 --> 00:01:33.959 and we've pulled insights from some of the leading frameworks 36 00:01:33.959 --> 00:01:37.599 in the field, including some incredibly detailed work from researchers 37 00:01:37.599 --> 00:01:41.280 like rodu Kalanescu and David Garland's team. We really want 38 00:01:41.319 --> 00:01:44.159 to figure out exactly how computer systems and networks are 39 00:01:44.159 --> 00:01:47.359 being built to manage, optimize, and heal themselves. 40 00:01:47.519 --> 00:01:49.760 Cut through the noise and really see how these systems 41 00:01:49.799 --> 00:01:50.439 actually think. 42 00:01:50.680 --> 00:01:53.599 Right, Okay, let's unpack this before we get into the 43 00:01:53.640 --> 00:01:57.680 incredibly complex frameworks these engineers are deploying today. I feel 44 00:01:57.719 --> 00:02:00.599 like we need to understand the basic mechanism. How does 45 00:02:00.599 --> 00:02:05.359 a machine actually watch itself? Why is this self watching 46 00:02:05.400 --> 00:02:07.000 even necessary in the first place. 47 00:02:07.400 --> 00:02:11.000 So to understand the core why, we really have to 48 00:02:11.039 --> 00:02:15.199 look at how traditional software has been built for decades. Historically, 49 00:02:15.319 --> 00:02:18.759 software systems are what we call open loop. They're designed 50 00:02:18.759 --> 00:02:22.159 to execute a specific function and they just blindly run 51 00:02:22.159 --> 00:02:26.120 that function until, well, until something. 52 00:02:25.879 --> 00:02:28.199 Breaks right or they run out of resources. 53 00:02:27.759 --> 00:02:30.919 Exactly, or a server literally catches fire when they hit 54 00:02:30.919 --> 00:02:34.680 a wall. They stop period, and then a human administrator 55 00:02:34.719 --> 00:02:37.240 has to step in, look at the air logs, figure 56 00:02:37.240 --> 00:02:40.840 out what went wrong, deploy a fix, and restart the system. 57 00:02:40.879 --> 00:02:43.680 And that takes a lot of time, tons of time. 58 00:02:44.199 --> 00:02:49.120 That human intervention is the bottleneck. It causes massive costly downtime. 59 00:02:49.599 --> 00:02:53.479 So the entire goal of autonomic computing is to eliminate 60 00:02:53.520 --> 00:02:57.840 that human vulnerability by creating a closed loop feedback system. 61 00:02:57.919 --> 00:02:58.560 A closed loop. 62 00:02:58.560 --> 00:03:01.080 Okay, so just briefly, is this kind of like a 63 00:03:01.120 --> 00:03:01.960 home thermostat. 64 00:03:02.120 --> 00:03:03.319 Ooh, that's a good comparison. 65 00:03:03.400 --> 00:03:05.599 Like you set the room temperature you want. The thermostat 66 00:03:05.639 --> 00:03:07.919 measures the actual temperature in the room, compares it to 67 00:03:07.960 --> 00:03:09.719 your goal, and if it's too cold, it turns on 68 00:03:09.759 --> 00:03:12.560 the heat, and once it hits the right temperature, it 69 00:03:12.599 --> 00:03:16.120 turns the heat off. It's basically managing itself based on 70 00:03:16.159 --> 00:03:16.840 its environment. 71 00:03:17.080 --> 00:03:20.479 The thermostat is like the perfect baseline analogy for a 72 00:03:20.560 --> 00:03:24.919 closed loop. But a modern distributed software system is infinitely 73 00:03:24.960 --> 00:03:27.960 more complex than a heating element. Yeah, I'd imagine a 74 00:03:28.000 --> 00:03:32.400 software system requires a much more explicit, highly detailed model 75 00:03:32.439 --> 00:03:36.000 of itself to function. You can't just measure temperature. You're 76 00:03:36.039 --> 00:03:39.800 measuring thousands of different metrics simultaneously, right, right, Which brings 77 00:03:39.879 --> 00:03:43.240 us to the foundational blueprint for these systems, the IBM 78 00:03:43.479 --> 00:03:45.879 m APE reference Model. 79 00:03:45.759 --> 00:03:47.919 M APE MAPE right exactly. 80 00:03:47.919 --> 00:03:52.560 It's an acronym that stands for monitor, analyze, plan and execute. 81 00:03:52.879 --> 00:03:55.919 These are the four distinct phases of the closed loop system. 82 00:03:55.960 --> 00:04:00.360 Okay, let's break those down. Monitor, analyze, plan, execute. If 83 00:04:00.400 --> 00:04:02.919 I'm a system administrator, what is my system actually doing 84 00:04:02.919 --> 00:04:04.039 in that very first phase? 85 00:04:04.080 --> 00:04:06.479 So, in the monitor phase, the system is extracting raw 86 00:04:06.560 --> 00:04:10.520 information from the managed resources. It's constantly pulling data on 87 00:04:11.080 --> 00:04:14.919 CPU load, memory usage, network traffic, discread write speeds. 88 00:04:14.759 --> 00:04:16.399 Just vacuuming up all this raw data. 89 00:04:16.759 --> 00:04:20.759 Yep. Then it moves to analyze. The system takes that 90 00:04:20.959 --> 00:04:24.040 raw data and determines if something has actually gone orwry. 91 00:04:24.720 --> 00:04:27.839 And crucially, it's not just looking for a crash, it 92 00:04:27.920 --> 00:04:29.879 is looking for a degrading trend. 93 00:04:30.120 --> 00:04:31.879 Oh interesting, Give me an example. 94 00:04:31.560 --> 00:04:33.920 Of that well, for example, it might notice that memory 95 00:04:34.000 --> 00:04:37.240 usage has been creeping up by say one percent every hour, 96 00:04:37.519 --> 00:04:40.639 so it's predicting a memory leak before the system actually 97 00:04:40.759 --> 00:04:41.519 runs out of RAM. 98 00:04:41.680 --> 00:04:44.040 Wow, which is way more advanced than just waiting for 99 00:04:44.040 --> 00:04:46.959 the system to completely break, much more proactive and reading 100 00:04:47.000 --> 00:04:49.160 through the sources. What really jumped out at me is 101 00:04:49.160 --> 00:04:52.279 that these four phases, they don't just happen in a vacuum. 102 00:04:52.319 --> 00:04:53.040 No, not at all. 103 00:04:53.040 --> 00:04:57.199 They're all orbiting around the central component called knowledge The models, 104 00:04:57.319 --> 00:05:01.560 the historical data, the behavioral scripts. That knowledge base seems 105 00:05:01.600 --> 00:05:04.920 to be the actual brain that the mate loop uses 106 00:05:05.000 --> 00:05:06.279 to make sense of the world. 107 00:05:06.439 --> 00:05:09.519 Yeah. The knowledge component is what separates a simple automated 108 00:05:09.560 --> 00:05:13.920 reflex from an intelligent adaptation. The knowledge base holds the 109 00:05:13.920 --> 00:05:17.439 topology of the network and all the historical performance logs. 110 00:05:17.199 --> 00:05:19.759 So it remembers what happened before exactly. 111 00:05:20.199 --> 00:05:23.079 If we connect this to the bigger picture, this closed 112 00:05:23.079 --> 00:05:27.839 loop architecture allows engineers to completely separate a system's primary 113 00:05:27.879 --> 00:05:31.839 functionality from its adaptation behaviors. What do you mean by that, Well, 114 00:05:31.879 --> 00:05:35.920 the software doing the main job, say processing credit card transactions, 115 00:05:36.399 --> 00:05:38.480 doesn't have to be bogged down with the logic of 116 00:05:38.480 --> 00:05:40.680 how to fix its own server memory. Oh I see, 117 00:05:40.720 --> 00:05:45.639 the autonomic manager sits outside of that primary software, watching, analyzing, 118 00:05:45.720 --> 00:05:48.040 and tweaking based on its knowledge base. 119 00:05:48.120 --> 00:05:51.160 Okay, so conceptually that makes total sense. But taking that 120 00:05:51.199 --> 00:05:55.040 theory and building it into complex modern software without having 121 00:05:55.040 --> 00:05:57.199 to rewrite millions of lines of code. 122 00:05:56.959 --> 00:05:58.759 From scratch, Yeah, that's the hard part. 123 00:05:58.879 --> 00:06:00.360 That seems like a monumental task. 124 00:06:00.519 --> 00:06:03.639 You can't just slap a self healing sticker on a 125 00:06:03.680 --> 00:06:07.399 massive corporate network. How do engineers actually bridge that gap? 126 00:06:07.600 --> 00:06:11.040 They use frameworks designed specifically for this, and one of 127 00:06:11.040 --> 00:06:14.040 the most prominent ones discussed in our source material is 128 00:06:14.079 --> 00:06:15.160 the Rainbow framework. 129 00:06:15.480 --> 00:06:15.920 Rainbow. 130 00:06:16.079 --> 00:06:19.240 Yeah, Rainbow is fascinating because it relies on what the 131 00:06:19.279 --> 00:06:22.920 researchers call architecture based self adaptation. 132 00:06:23.000 --> 00:06:24.079 Okay, unpack that a bit. 133 00:06:24.240 --> 00:06:27.879 Instead of the autonomic manager trying to read and rewrite 134 00:06:28.480 --> 00:06:31.879 raw lines of code, which would be incredibly slow and 135 00:06:31.959 --> 00:06:36.160 highly dangerous, Rainbow uses an abstract blueprint of the system 136 00:06:36.240 --> 00:06:38.879 a blueprint, right. It looks at the system from a 137 00:06:38.920 --> 00:06:42.279 bird's eye view, as a collection of high level components 138 00:06:42.680 --> 00:06:46.360 like clients and servers and connectors like HTTP pipelines. 139 00:06:46.839 --> 00:06:48.920 Okay, I really want to bring this to life because 140 00:06:48.920 --> 00:06:53.120 the text provides this brilliant concrete example a system they 141 00:06:53.160 --> 00:06:55.600 call ZNN dot com. 142 00:06:55.639 --> 00:06:57.600 Oh yes, the news site, right. 143 00:06:57.439 --> 00:07:00.399 It's a multimedia news site modeled in an ND tier style. 144 00:07:00.759 --> 00:07:03.279 So for anyone listening trying to visualize this, You've got 145 00:07:03.279 --> 00:07:05.800 a load balancer at the front door. That load balancer 146 00:07:05.920 --> 00:07:09.920 passes incoming user requests to a pool of replicated web servers, 147 00:07:10.319 --> 00:07:12.879 and then those servers pull articles and videos from a 148 00:07:12.920 --> 00:07:13.879 back end database. 149 00:07:13.959 --> 00:07:16.639 It's a very standard, highly common architecture for the web today. 150 00:07:16.879 --> 00:07:18.839 Right, So let's set the scenario. 151 00:07:19.360 --> 00:07:22.519 A massive global news event happens, ZNN dot com suddenly 152 00:07:22.519 --> 00:07:24.639 experiences astronomical traffic spikes. 153 00:07:25.000 --> 00:07:26.000 As we discussed. 154 00:07:25.680 --> 00:07:28.839 Earlier, Normally, the web servers get overloaded, the load balancer panics, 155 00:07:28.839 --> 00:07:29.920 and the website. 156 00:07:29.480 --> 00:07:30.720 Crashes total filling. 157 00:07:30.759 --> 00:07:33.959 So how does the Rainbow framework actually prevent this catastrophic 158 00:07:34.000 --> 00:07:35.920 failure using that bird's eye view you. 159 00:07:35.920 --> 00:07:39.839 Mentioned, It all comes down to Rainbow's translation infrastructure. You 160 00:07:39.879 --> 00:07:43.000 have to bridge the gap between the raw, messy reality 161 00:07:43.160 --> 00:07:47.959 of the physical hardware and the clean, abstract architectural blueprint 162 00:07:47.959 --> 00:07:50.560 that Rainbow was looking at. Okay, and Rainbow does this 163 00:07:50.839 --> 00:07:55.639 using two critical tools, probes and gages. Probes are deployed 164 00:07:55.680 --> 00:07:58.639 deep inside the target system to measure raw data. So 165 00:07:58.759 --> 00:08:01.519 a probe might just be a script that constantly reports 166 00:08:01.800 --> 00:08:04.560 CPU load on server three is at ninety five percent. 167 00:08:05.120 --> 00:08:07.120 So the probe is just a dumb thermometer. Essentially, it 168 00:08:07.160 --> 00:08:09.480 doesn't know what the temperature means. It just reports the number. 169 00:08:09.639 --> 00:08:11.480 That is the perfect way to look at it. But 170 00:08:11.519 --> 00:08:14.360 then you have the gauges. Okay, gauges are the doctors 171 00:08:14.399 --> 00:08:17.680 reading that thermometer. A gauge takes that raw probe data 172 00:08:17.959 --> 00:08:20.040 and interprets it into an architectural property. 173 00:08:20.160 --> 00:08:21.199 Interesting, So a. 174 00:08:21.120 --> 00:08:24.560 Gauge takes that ninety five percent CPU load, correlates it 175 00:08:24.560 --> 00:08:27.680 with the current incoming network traffic, looks at the database 176 00:08:27.720 --> 00:08:31.160 response times, and reports to the system the average response 177 00:08:31.199 --> 00:08:34.440 latency for a client is currently four thousand milliseconds. 178 00:08:34.480 --> 00:08:35.039 Oh wow. 179 00:08:35.159 --> 00:08:38.919 Yeah. Once that gauge updates the architectural model, the architecture 180 00:08:38.919 --> 00:08:43.360 evaluator kicks in. It constantly checks these architectural properties against 181 00:08:43.399 --> 00:08:47.679 predefined rules. For ZNN dot com, there is a hard 182 00:08:47.759 --> 00:08:52.080 rule written into the system. If a property called client 183 00:08:52.120 --> 00:08:57.159 t recristplatency exceeds a specific maximum threshold, it triggers a 184 00:08:57.200 --> 00:08:58.120 system wide alarm. 185 00:08:58.279 --> 00:09:01.639 Okay, so the alarm is ringing. The system knows latency 186 00:09:01.720 --> 00:09:03.919 is way too high. People are waiting four seconds for 187 00:09:03.960 --> 00:09:06.080 a page to load, and users are getting frustrated. 188 00:09:06.440 --> 00:09:08.440 But how does it choose how to fix it? 189 00:09:08.679 --> 00:09:09.919 That's the million dollar question. 190 00:09:10.080 --> 00:09:12.960 This is the part that completely fascinates me, because it 191 00:09:12.960 --> 00:09:16.360 can't just blindly start flipping switches in the server room, right. 192 00:09:16.519 --> 00:09:19.639 It has to weigh actual business trade offs exactly. 193 00:09:20.000 --> 00:09:22.120 This is where we enter the plan phase of the 194 00:09:22.240 --> 00:09:26.519 MAPE loop, which is handled by Rainbow's adaptation manager, and 195 00:09:26.559 --> 00:09:29.360 it uses something called utility theory to make its decisions. 196 00:09:29.559 --> 00:09:30.720 Utility theory, right, The. 197 00:09:30.720 --> 00:09:33.080 System doesn't just want to fix the problem. It wants 198 00:09:33.120 --> 00:09:35.720 to fix the problem in a way that maximizes overall 199 00:09:35.759 --> 00:09:36.679 business value. 200 00:09:36.720 --> 00:09:40.080 The math behind this decision engine is just incredible. The 201 00:09:40.120 --> 00:09:45.399 system literally relies on four weighted quality dimensions for ZNN. 202 00:09:45.039 --> 00:09:46.799 Dot com YEP. The four dimensions. 203 00:09:46.919 --> 00:09:49.720 First, there is response time, which is the most important metrics. 204 00:09:49.759 --> 00:09:52.559 The business weighted at point four out of one second 205 00:09:52.639 --> 00:09:54.360 is budget weighted at point three. 206 00:09:54.639 --> 00:09:55.120 Makes sense. 207 00:09:55.240 --> 00:09:58.519 Third is content quality, meaning you know whether you're serving 208 00:09:58.600 --> 00:10:01.879 rich multimedia videos or just plain text that's weighted at 209 00:10:01.919 --> 00:10:06.159 point two. And finally, disruption how jarring the fixes to 210 00:10:06.240 --> 00:10:09.159 the current users, which is the least important, weighted at 211 00:10:09.200 --> 00:10:10.159 point one, and. 212 00:10:10.120 --> 00:10:13.799 Those weights dictate the entire personality of the system because 213 00:10:13.799 --> 00:10:16.440 when the adaptation manager looks at the high latency problem, 214 00:10:16.559 --> 00:10:20.039 it uses an adaptation language called Stitch to evaluate its 215 00:10:20.080 --> 00:10:21.039 possible strategies. 216 00:10:21.120 --> 00:10:22.360 Okay, Stitch Yeah. 217 00:10:22.440 --> 00:10:25.519 In this scenario, Stitch sees two primary options to lower 218 00:10:25.559 --> 00:10:28.360 the latency. Option A is in large serverble. It can 219 00:10:28.399 --> 00:10:30.919 spin up more virtual servers to handle the traffic. 220 00:10:30.639 --> 00:10:31.480 Which sounds good. 221 00:10:31.679 --> 00:10:34.840 It is good. This maintains the high quality multimedia content, 222 00:10:34.879 --> 00:10:37.480 which is great for the content quality score, but spinning 223 00:10:37.559 --> 00:10:40.919 up cloud servers costs actual money, which actively hurts the 224 00:10:40.919 --> 00:10:41.600 budget score. 225 00:10:41.879 --> 00:10:43.600 Ah right, So what's the other option? 226 00:10:43.720 --> 00:10:46.679 Option B is switch to textual mode. You can strip 227 00:10:46.720 --> 00:10:49.639 out all the hiras, videos and images and just serve 228 00:10:49.759 --> 00:10:50.840 plaintext articles. 229 00:10:50.840 --> 00:10:51.639 Oh wow. 230 00:10:51.720 --> 00:10:55.720 This tanks the content quality score obviously, but it drastically 231 00:10:55.759 --> 00:10:59.759 improves response time without spending a single dime, which preserves 232 00:10:59.759 --> 00:11:00.600 the budget score. 233 00:11:00.679 --> 00:11:02.480 Wait, I need to push back on this for a second. 234 00:11:02.559 --> 00:11:05.840 Sure, disruption is only weighted at point one if the 235 00:11:05.879 --> 00:11:08.200 system suddenly strips all the video off the site and 236 00:11:08.279 --> 00:11:11.399 switches to text while a user is mid scroll. People 237 00:11:11.399 --> 00:11:15.080 are going to be incredibly jarred by that. Why is 238 00:11:15.120 --> 00:11:18.879 the math telling the machine that user disruption barely matters 239 00:11:18.960 --> 00:11:19.919 compared to the budget. 240 00:11:20.399 --> 00:11:23.639 It's a harsh reality of business survival over user comfort. 241 00:11:24.039 --> 00:11:26.519 Really yeah, think about it. If the site goes down 242 00:11:26.559 --> 00:11:29.360 completely because they ran out of server budget, the disruption 243 00:11:29.519 --> 00:11:32.639 is absolute. Nobody gets anything right. So the engineers who 244 00:11:32.720 --> 00:11:35.919 set those utility weights decided that a momentary flicker where 245 00:11:35.919 --> 00:11:39.320 a video turns into text is a totally acceptable trade 246 00:11:39.360 --> 00:11:41.919 off if it guarantees the site stays online and the 247 00:11:41.919 --> 00:11:45.399 company doesn't go bankrupt paying for emergency cloud servers. 248 00:11:45.679 --> 00:11:48.240 You know, It's exactly like an er trioge nurse. 249 00:11:48.279 --> 00:11:48.759 Oh yeah, hou. 250 00:11:48.799 --> 00:11:51.360 So if you walk into a busy emergency room, the 251 00:11:51.440 --> 00:11:54.279 trioge nurse has to instantly weigh the severity of your 252 00:11:54.320 --> 00:11:58.480 symptoms against the hospital's available beds, the number of doctors 253 00:11:58.480 --> 00:12:01.279 on shift, and the inc humming ambulance traffic. 254 00:12:01.480 --> 00:12:02.679 Exactly, they are. 255 00:12:02.559 --> 00:12:08.679 Making real time, highly complex operational choices based on conflicting resources. 256 00:12:09.080 --> 00:12:11.240 They might put you in a hallway bed, which is 257 00:12:11.440 --> 00:12:14.799 you know, highly disruptive and uncomfortable, because saving the budget 258 00:12:14.799 --> 00:12:18.279 of a private room for a critical patient maximizes the 259 00:12:18.320 --> 00:12:19.879 overall utility of the hospital. 260 00:12:20.120 --> 00:12:23.759 That is a brilliant analogy. And what is truly remarkable 261 00:12:23.799 --> 00:12:26.679 here is how the system handles uncertainty within. 262 00:12:26.480 --> 00:12:28.200 That trioshe process uncertainty. 263 00:12:28.279 --> 00:12:31.159 Yeah, the adaptation manager knows that enacting a strategy doesn't 264 00:12:31.159 --> 00:12:34.159 guarantee success. If it chooses option A and tries to 265 00:12:34.159 --> 00:12:36.720 spin up a new server, maybe the cloud provider has 266 00:12:36.720 --> 00:12:39.159 a glitch and the server fails to start. Oh right, 267 00:12:39.320 --> 00:12:42.120 Or if it chooses action B and switches to textual mode, 268 00:12:42.559 --> 00:12:45.480 maybe the traffic spike is so massive that text only 269 00:12:45.519 --> 00:12:48.840 still overloads the system. So the system computes the expected 270 00:12:48.919 --> 00:12:50.799 utility using stochastic models. 271 00:12:51.039 --> 00:12:55.480 Wait, hold on, stochastic models sounds incredibly intimidating. It does 272 00:12:55.639 --> 00:12:58.759 if I'm understanding this. Stochastic just means it is factoring 273 00:12:58.759 --> 00:13:02.960 in randomness, right. How does a machine calculate randomness when 274 00:13:03.000 --> 00:13:04.279 making a business decision? 275 00:13:04.519 --> 00:13:08.320 It calculates randomness by relying on probability data from its 276 00:13:08.320 --> 00:13:12.639 knowledge base. Expected utility isn't just a flat score, It's 277 00:13:12.679 --> 00:13:16.480 a weighted prediction. Okay, Let's say Option A spinning up 278 00:13:16.519 --> 00:13:19.480 a server has a high utility score of eighty if 279 00:13:19.519 --> 00:13:23.639 it works, but historical data tells the stochastic model there's 280 00:13:23.679 --> 00:13:26.200 only a fifty percent chance the server actually spins up 281 00:13:26.200 --> 00:13:27.279 in time to prevent the. 282 00:13:27.240 --> 00:13:29.240 Crash, so the score gets cut in half. 283 00:13:29.519 --> 00:13:34.240 Essentially, yes, the expected utility is heavily downgraded. Meanwhile, Option 284 00:13:34.320 --> 00:13:36.639 B switching to text might only have a utility score 285 00:13:36.679 --> 00:13:38.919 of sixty, but it has a ninety nine percent chance 286 00:13:38.919 --> 00:13:39.799 of working instantly. 287 00:13:39.879 --> 00:13:40.039 Oh. 288 00:13:40.120 --> 00:13:42.559 I see, the system multiplies the value of the outcome 289 00:13:42.600 --> 00:13:45.519 by the probability of its success. It is playing out 290 00:13:45.559 --> 00:13:48.919 alternate futures, calculating the math of that randomness, and picking 291 00:13:48.919 --> 00:13:52.000 the path with the highest guaranteed yield. Wow. Only then 292 00:13:52.080 --> 00:13:55.679 does it dispatch the strategy executor to make the actual change. 293 00:13:55.799 --> 00:13:56.759 That is mind blowing. 294 00:13:56.799 --> 00:13:58.759 It's doing all of that math, playing out all those 295 00:13:58.799 --> 00:14:04.519 alternate futures in millisecondsp But you know, thinking about this logically, 296 00:14:04.759 --> 00:14:07.600 Rainbow is brilliant if you are building a modern, clean 297 00:14:07.840 --> 00:14:12.120 web architecture like ZNN dot com. But the real world 298 00:14:12.200 --> 00:14:15.919 is messy, very messy. Custom building a bespoke Rainbow framework 299 00:14:15.960 --> 00:14:19.360 with its own stitch language rules and highly specific gauges 300 00:14:19.679 --> 00:14:22.759 for every single app or corporate network in the world. 301 00:14:23.320 --> 00:14:27.320 That would be impossibly expensive and time consuming. 302 00:14:27.440 --> 00:14:27.879 It would be. 303 00:14:28.159 --> 00:14:31.039 So how does the industry move from these custom, bespoke 304 00:14:31.120 --> 00:14:34.639 fixes to something universal, like something plug and play? 305 00:14:34.879 --> 00:14:37.639 That is the holy grail of this field general purpose 306 00:14:37.639 --> 00:14:40.720 autonomic computing. Okay, the goal is to make self management 307 00:14:40.799 --> 00:14:43.679 as standardized as plugging in a USB cable. You don't 308 00:14:43.679 --> 00:14:45.559 want to build a new autootic manager every time you 309 00:14:45.600 --> 00:14:47.879 build a new app. The solution is to use a 310 00:14:48.000 --> 00:14:52.840 universal reconfigurable policy engine universal instead of hardcoding the manager 311 00:14:52.879 --> 00:14:56.759 to understand one specific system engineers feed this generic engine 312 00:14:56.879 --> 00:14:58.879 and XML schema. 313 00:14:58.399 --> 00:15:01.080 XML, meaning basically a standard document format. 314 00:15:01.360 --> 00:15:06.600 Yes, this XML document acts as a universal translator. It 315 00:15:06.679 --> 00:15:09.919 defines the system model, the resources, the components, and the 316 00:15:09.960 --> 00:15:14.399 properties in a standardized, structured format that the generic policy 317 00:15:14.399 --> 00:15:15.919 engine can instantly understand. 318 00:15:16.000 --> 00:15:19.200 So it's like handing the engine a standardized map exactly. 319 00:15:19.519 --> 00:15:22.080 But here's where it gets really interesting to me. What 320 00:15:22.320 --> 00:15:26.440 happens if the system is old? I mean, corporate infrastructure 321 00:15:26.480 --> 00:15:29.960 is full of twenty year old legacy databases and dinosaur 322 00:15:30.039 --> 00:15:33.480 servers that were built long before anyone coined the term 323 00:15:33.519 --> 00:15:37.759 autonomic computing. You can't just slap a universal policy engine 324 00:15:37.799 --> 00:15:40.000 over a legacy database and expect them to talk. 325 00:15:40.120 --> 00:15:41.039 You definitely cannot. 326 00:15:41.159 --> 00:15:44.559 So how does this generic engine actually control resources that 327 00:15:44.600 --> 00:15:46.679 were never designed to be self managing. 328 00:15:46.879 --> 00:15:49.639 It controls them through something called manageability adapters. 329 00:15:49.799 --> 00:15:51.000 Manageability adapters. 330 00:15:51.039 --> 00:15:54.039 Think of these adapters as diplomatic envoice or like real 331 00:15:54.080 --> 00:15:57.720 time translators. They wrap around the legacy IT resources and 332 00:15:57.759 --> 00:15:59.960 provide uniform sensor and effector interface. 333 00:16:00.240 --> 00:16:01.240 Okay, so a wrapper. 334 00:16:01.399 --> 00:16:05.279 Yeah, the legacy system has no idea. It is part 335 00:16:05.320 --> 00:16:08.320 of an autonomic loop. It's just doing its job. When 336 00:16:08.320 --> 00:16:11.480 the legacy system spits out a weird, outdated air log, 337 00:16:12.000 --> 00:16:15.559 the manageability adapter intercepts. It translates that data into the 338 00:16:15.600 --> 00:16:19.279 standard XML format and hands it to the generic policy engine. 339 00:16:19.360 --> 00:16:20.080 Oh that's close. 340 00:16:20.120 --> 00:16:22.120 And when the policy engine sends a command to change 341 00:16:22.120 --> 00:16:26.720 a configuration, the adapter translates that standardized command back into 342 00:16:26.799 --> 00:16:29.840 the legacy system's native twenty year old language. 343 00:16:30.159 --> 00:16:32.600 To really show the power of this universal engine, we 344 00:16:32.679 --> 00:16:35.320 have to talk about the Fujitsu disk drive example from 345 00:16:35.360 --> 00:16:37.639 the text. Yes, that's a great one, because this isn't 346 00:16:37.679 --> 00:16:40.120 a massive global news site. This is a piece of 347 00:16:40.159 --> 00:16:44.759 physical hardware, and it perfectly illustrates how versatile this universal 348 00:16:44.919 --> 00:16:46.720 XML approaches it really does. 349 00:16:47.120 --> 00:16:50.600 In this case, study researchers took that exact same generic 350 00:16:50.639 --> 00:16:54.159 policy engine and used it to manage a physical Fujitsu dis. 351 00:16:54.159 --> 00:16:56.679 Drive, the exact same engine, the exact same one. 352 00:16:56.919 --> 00:16:59.720 They fed the engine a highly complex mathematical model of 353 00:16:59.720 --> 00:17:03.759 the using a free, open source probabilistic model. 354 00:17:03.519 --> 00:17:05.359 Checker called prism prism right. 355 00:17:05.599 --> 00:17:08.599 Specifically, they used a continuous time markoff chain model. 356 00:17:08.759 --> 00:17:09.400 Okay, I have to. 357 00:17:09.319 --> 00:17:13.599 Stop you there, a continuous time markof chain. Explain that 358 00:17:13.640 --> 00:17:15.519 to me, because it sounds like we just jumped into 359 00:17:15.640 --> 00:17:18.200 a graduate level statistics class. 360 00:17:18.279 --> 00:17:21.039 It sounds worse than it is. A markoff chain is 361 00:17:21.079 --> 00:17:24.880 simply a mathematical system that transitions from one state to 362 00:17:24.920 --> 00:17:28.240 another where the probability of the next state depends only 363 00:17:28.279 --> 00:17:30.559 on the current state, not on the sequence of events 364 00:17:30.559 --> 00:17:31.160 that preceded it. 365 00:17:31.279 --> 00:17:31.599 Okay. 366 00:17:32.279 --> 00:17:35.359 In the case of the Fujitsu disk drive, the drive 367 00:17:35.440 --> 00:17:38.960 has different states. It can be busy reading data, it 368 00:17:39.000 --> 00:17:41.559 can be idle, or it can drop into a slate 369 00:17:41.599 --> 00:17:42.680 mode to save power. 370 00:17:42.920 --> 00:17:44.839 Okay, let me try an analogy go for it is 371 00:17:44.880 --> 00:17:47.519 a Markoff chain model of this disk drive, kind of 372 00:17:47.519 --> 00:17:48.880 like deciding what to do with your. 373 00:17:48.720 --> 00:17:50.079 Car at a long red light. 374 00:17:50.240 --> 00:17:50.880 Oh I like this. 375 00:17:51.119 --> 00:17:54.799 So you're currently in the idle state. Your engine is running, 376 00:17:54.799 --> 00:17:58.000 which is wasting gas. But if the light turns green, 377 00:17:58.279 --> 00:18:01.119 you can hit the gas and go inside. Now you 378 00:18:01.160 --> 00:18:04.000 could choose to turn the engine completely off, transitioning to 379 00:18:04.039 --> 00:18:04.799 the sleep state. 380 00:18:05.240 --> 00:18:06.599 That saves a ton of gas. 381 00:18:06.880 --> 00:18:09.039 But when the light turns green, it takes you like 382 00:18:09.160 --> 00:18:12.160 three seconds to restart the engine, which delays you and 383 00:18:12.240 --> 00:18:14.119 frustrates all the cars waiting behind you. 384 00:18:14.359 --> 00:18:17.319 That's a brilliant way to frame it. The disc drive 385 00:18:17.599 --> 00:18:20.960 faces that exact same dilemma. If it drops into sleep mode, 386 00:18:21.079 --> 00:18:24.839 it saves a massive amount of power, but waking up 387 00:18:24.839 --> 00:18:29.200 from sleep takes time, which delays incoming data requests and 388 00:18:29.279 --> 00:18:32.640 builds up a queue of frustrated users the cars behind you. 389 00:18:32.920 --> 00:18:33.880 Oh I see. 390 00:18:33.960 --> 00:18:37.319 So the universal policy engine uses that Markov chain model 391 00:18:37.680 --> 00:18:42.839 to dynamically calculate the exact, mathematically optimal probability for the 392 00:18:42.920 --> 00:18:45.720 drive to switch from idle to sleep at any given 393 00:18:45.720 --> 00:18:46.319 mill a second. 394 00:18:46.440 --> 00:18:48.839 So it's constantly monitoring how many cars are piling up 395 00:18:48.880 --> 00:18:49.319 behind it. 396 00:18:49.440 --> 00:18:52.200 Yes, it is constantly adjusting the probability of going to 397 00:18:52.240 --> 00:18:54.839 sleep based on the length of the request queue. It 398 00:18:54.880 --> 00:18:57.680 perfectly balances the utility of power savings against the utility 399 00:18:57.680 --> 00:19:00.960 of fast response times. It calculates the optimal moment to 400 00:19:01.000 --> 00:19:02.799 turn off the engine, so to speak. 401 00:19:03.000 --> 00:19:04.720