WEBVTT - Living on the Edge (Computing) 0:00:04.400 --> 0:00:07.800 Welcome to Tech Stuff, a production from I Heart Radio. 0:00:12.200 --> 0:00:15.000 Hey there, and welcome to tech Stuff. I'm your host, 0:00:15.160 --> 0:00:18.080 Jonathan Strickland. I'm an executive producer with I Heart Radio, 0:00:18.120 --> 0:00:20.919 and I love all things tech. And over the history 0:00:21.079 --> 0:00:24.200 of this podcast, I have covered a lot of topics 0:00:24.239 --> 0:00:27.040 that were, at least at one time a little more 0:00:27.200 --> 0:00:32.280 than buzzwords to me, cloud computing, machine learning, Internet of things. 0:00:32.720 --> 0:00:35.879 A lot of these topics were either just not widely 0:00:36.040 --> 0:00:40.519 spoken about in mainstream society or they were even just 0:00:40.800 --> 0:00:44.239 emerging within the tech world itself. This is where I 0:00:44.280 --> 0:00:46.440 have to remind all of you that I came into 0:00:46.520 --> 0:00:50.640 tech Stuff as someone who loved technology, but who is not, 0:00:51.320 --> 0:00:55.560 in actuality technologist or an engineer or anything like that. 0:00:56.000 --> 0:00:59.080 And one of the terms that I started running into 0:00:59.160 --> 0:01:03.440 around fourteen or so, so it was after I had 0:01:03.440 --> 0:01:07.360 started this podcast. One of those terms was edge computing, 0:01:07.560 --> 0:01:11.319 or sometimes computing at the edge. And if you listen 0:01:11.400 --> 0:01:15.640 to yesterday's Smart Talks episode with Malcolm Gladwell, you heard 0:01:15.680 --> 0:01:18.720 a little bit about that in there, and now we're 0:01:18.720 --> 0:01:22.280 gonna dive in whole hog. So today I thought we'd 0:01:22.280 --> 0:01:26.319 talked a bit about what edge computing actually means and 0:01:26.480 --> 0:01:29.640 contrast it with other types of computing models, and we'll 0:01:29.680 --> 0:01:32.119 talk about how all of this is meant to work 0:01:32.160 --> 0:01:35.480 together in different ways, and why it's even a thing 0:01:35.480 --> 0:01:38.600 in the first place, and where edge computing is today 0:01:38.640 --> 0:01:41.280 and what we might think of it in the future. 0:01:41.880 --> 0:01:44.920 I thought that a good way to approach edge computing 0:01:45.040 --> 0:01:47.840 is really to start with some basic facts. There are 0:01:47.840 --> 0:01:51.880 certain things that we, as smarty pants human types, can 0:01:51.960 --> 0:01:56.360 do to speed up computer systems, To speed up the 0:01:56.360 --> 0:01:59.360 the moment from where we put input into a system 0:01:59.600 --> 0:02:03.160 to an we get output from that system. We can 0:02:03.200 --> 0:02:07.280 create more efficient and powerful processors. For example, you know, 0:02:07.320 --> 0:02:10.760 we can lean on parallel processing for some types of 0:02:10.800 --> 0:02:15.640 computer problems. Doesn't work for everything. Quantum computing, similarly, will 0:02:15.680 --> 0:02:21.359 speed up certain types of computer problems exponentially. We can 0:02:21.440 --> 0:02:25.320 design better software, and we can try to avoid Worth's law. 0:02:25.639 --> 0:02:28.079 That's what the law that states that software tends to 0:02:28.120 --> 0:02:32.600 get slower at a rate that's faster than improvements in hardware. 0:02:33.400 --> 0:02:36.519 If we do combinations of all these sort of strategies, 0:02:36.520 --> 0:02:39.959 then the machines of tomorrow will in theory run software 0:02:40.000 --> 0:02:43.360 better than the machines of today. Again, assuming we don't 0:02:43.400 --> 0:02:47.120 just make even more bloated software that ends up canceling 0:02:47.120 --> 0:02:51.280 out our sick hardware gains. But there's one thing that 0:02:51.360 --> 0:02:55.040 we just cannot get around, and that is the top 0:02:55.120 --> 0:02:59.000 speed at which information can travel from one point to another. 0:02:59.680 --> 0:03:04.360 Even using a fiber optic cable and a clever optical 0:03:04.440 --> 0:03:08.160 system to deliver information, we are limited by the speed 0:03:08.160 --> 0:03:12.080 of light itself. Now that speed is um let me 0:03:12.120 --> 0:03:17.000 check my notes here says wicked fast. When traveling through 0:03:17.000 --> 0:03:22.360 a vacuum, light zips along at two hundred million, seven 0:03:22.400 --> 0:03:28.760 hundred thousand, four hundred fifty eight meters per second. Nothing 0:03:29.400 --> 0:03:33.760 goes faster, thanks a lot, Einstein. What this means for 0:03:33.880 --> 0:03:38.320 us is that distance matters. Of course, until fairly recently, 0:03:38.360 --> 0:03:40.920 this wasn't the biggest concern for us because the way 0:03:40.960 --> 0:03:43.520 we did computing was pretty much always right up close 0:03:43.560 --> 0:03:47.240 and personal. So let's talk about that for a second, alright. So, 0:03:47.360 --> 0:03:51.400 to begin with, we have computers that we physically access 0:03:51.600 --> 0:03:54.720 in some way in order to carry out a program. 0:03:54.760 --> 0:03:58.680 So in the very early days, people program computers by 0:03:58.680 --> 0:04:03.560 physically plugging in different cables into different sockets and throwing 0:04:03.640 --> 0:04:07.080 switches and I don't know, waiting for lightning to strike 0:04:07.160 --> 0:04:12.119 or something. Okay, ignore that last bit. The process was tedious, 0:04:12.320 --> 0:04:15.760 it was complicated, it was easy to come up. The 0:04:15.840 --> 0:04:18.919 speed of the computer was limited both by its own 0:04:19.040 --> 0:04:22.760 method of processing information as well as the speed at 0:04:22.760 --> 0:04:27.719 which human operators could operate it. But once the computer 0:04:27.839 --> 0:04:32.520 actually finished the calculations, delivering them was pretty fast. I mean, 0:04:32.600 --> 0:04:35.600 sometimes delivering meant printing out a sheet of paper or 0:04:35.680 --> 0:04:38.840 making little lights on a panel light up a specific way, 0:04:38.920 --> 0:04:40.599 and then the humans would have to consult a guide 0:04:40.600 --> 0:04:43.039 to figure out what that all meant. But if the 0:04:43.080 --> 0:04:46.440 computer had had a display, it would be able to 0:04:46.480 --> 0:04:49.400 throw up the answer as soon as it got there 0:04:49.440 --> 0:04:53.479 with zero delay. Flash forward a few decades, and we 0:04:53.600 --> 0:04:57.000 then had computers that had simplified input and output devices. 0:04:57.240 --> 0:05:01.120 You had your keyboards, you had your monitors and what not. Now, 0:05:01.200 --> 0:05:05.800 programming a computer was far less convoluted, though as programming 0:05:05.880 --> 0:05:08.599 language is evolved, it can still be fairly easy for 0:05:08.640 --> 0:05:11.480 a human to gum things up with a careless error 0:05:11.600 --> 0:05:15.080 or a miscalculation or typo. Again, most of the time 0:05:15.279 --> 0:05:18.240 we were talking about people being all right up on 0:05:18.520 --> 0:05:22.040 the computer, and so there was really no delay between 0:05:22.040 --> 0:05:26.480 the machine arriving at the endpoint of a computational process 0:05:26.560 --> 0:05:28.640 and then delivering the result to the person who was 0:05:28.720 --> 0:05:33.120 using the computer. The information wasn't really traveling anywhere, it 0:05:33.200 --> 0:05:37.880 was just there. Then we get ARPA, the Advanced Research 0:05:37.960 --> 0:05:42.520 Projects Agency. It's the predecessor to DARPA. One of the 0:05:42.600 --> 0:05:45.279 projects ARPA tackled was to find a way to network 0:05:45.440 --> 0:05:48.799 different types of computers together. This was a big challenge 0:05:48.960 --> 0:05:51.920 for several reasons, but one of them was that different 0:05:51.960 --> 0:05:57.040 computers ran on very different processes and what we'll call 0:05:57.160 --> 0:06:00.320 them operating systems, but that's really being a bit general us. 0:06:00.320 --> 0:06:03.800 But the point is that the computers from different manufacturers, 0:06:03.920 --> 0:06:07.760 effectively they spoke different languages and they could not directly 0:06:07.839 --> 0:06:11.760 communicate with one another. And in the easy way boiled down, 0:06:12.200 --> 0:06:14.600 the computers spoke math, but it was kind of like 0:06:15.200 --> 0:06:18.600 wildly different dialects of math. So there needed to be 0:06:18.800 --> 0:06:21.920 some sort of common language that all computers would be 0:06:21.960 --> 0:06:25.680 able to convert their native speech into and then translate 0:06:25.839 --> 0:06:30.039 incoming speech back into their native language. Now that's a 0:06:30.120 --> 0:06:34.479 super oversimplified way to say that very smart people built 0:06:34.520 --> 0:06:37.560 out the protocols that would allow for the transfer of 0:06:37.600 --> 0:06:41.600 information across networks we would eventually get stuff like T 0:06:41.760 --> 0:06:46.360 C P I P that would facilitate these connections. Now 0:06:46.600 --> 0:06:49.240 computers could connect into their network and they would be 0:06:49.279 --> 0:06:52.840 able to send information to and receive information from other 0:06:52.880 --> 0:06:56.640 computers on that same network. And as other networks took shape, 0:06:56.960 --> 0:07:00.800 they could interconnect with that first network, and then we 0:07:00.880 --> 0:07:04.360 got the network of networks, or the Internet. So I'm 0:07:04.400 --> 0:07:07.520 giving a really fast rundown of the history of the 0:07:07.560 --> 0:07:11.560 Internet here. This is like from space levels of high 0:07:11.680 --> 0:07:14.800 level view of the history of the Internet. All right, 0:07:14.840 --> 0:07:17.520 now we're gonna skip way ahead. Let's get up to 0:07:17.560 --> 0:07:21.720 the ninety nineties, where the general public became aware that 0:07:21.760 --> 0:07:25.560 there was this thing called the Internet, and the development 0:07:25.560 --> 0:07:29.640 and deployment of the Worldwide Web really helped that along considerably. 0:07:30.400 --> 0:07:35.040 Now we had this information super highway, or if you prefer, 0:07:35.200 --> 0:07:38.120 we had a series of pipes that let information flow 0:07:38.200 --> 0:07:43.400 from one source to another. Using this vast network of machines, 0:07:43.760 --> 0:07:45.920 we could send messages to friends on the other side 0:07:45.960 --> 0:07:48.680 of the planet, or check in on a particular coffee 0:07:48.680 --> 0:07:51.640 pot at the computer lab in the University of Cambridge 0:07:51.640 --> 0:07:54.600 in England, even if we happened to be in Athens, Georgia, 0:07:54.640 --> 0:07:57.520 at the time. This, by the way, was actually a 0:07:57.600 --> 0:08:00.960 thing that once existed. And yes I did use a 0:08:01.000 --> 0:08:04.600 computer in the University of Georgia Computer Lab to check 0:08:04.720 --> 0:08:06.920 and see whether or not there was coffee in a 0:08:07.000 --> 0:08:11.200 coffee pot across the pond. Normally there wasn't because I 0:08:11.240 --> 0:08:13.480 was often in there in the afternoon and it was 0:08:13.560 --> 0:08:16.800 several hours later over in the UK. But you get 0:08:16.800 --> 0:08:20.360 the point now. The way the information actually travels across 0:08:20.400 --> 0:08:24.920 the Internet is pretty fascinating. First, information travels in bunches 0:08:24.960 --> 0:08:28.640 of data called packets, and this was a brilliant move 0:08:28.840 --> 0:08:33.520 early on in the development of networking technology. When computers 0:08:33.640 --> 0:08:37.240 send data across the Internet, they chopped that data up 0:08:37.320 --> 0:08:40.880 into packets, and a packet has two different kinds of 0:08:40.960 --> 0:08:45.040 data in it. There's data that's all about control information. 0:08:45.120 --> 0:08:47.239 So in other words, this is the data that explains 0:08:47.679 --> 0:08:50.800 where the packet came from, where it's going to, how 0:08:50.800 --> 0:08:54.240 many other packets the receiving computers should get in order 0:08:54.320 --> 0:08:57.439 to make up the entire file, and where within that 0:08:57.520 --> 0:09:00.240 sequence this particular packet should go. So you can think 0:09:00.240 --> 0:09:02.480 of that information is sort of like being the information 0:09:02.520 --> 0:09:04.600 on the outside of an envelope that you would send 0:09:04.679 --> 0:09:08.400 through the mail. Then you've got the payload or the 0:09:08.520 --> 0:09:11.600 data that relates to the file itself, the thing you 0:09:11.640 --> 0:09:15.079 are sending. The packets are kind of like puzzle pieces 0:09:15.080 --> 0:09:17.680 that get reassembled on the other side. Actually, think of 0:09:17.720 --> 0:09:21.360 it a lot like the sequence of Mike TV and 0:09:21.480 --> 0:09:25.480 Willie Wonka and the Chocolate Factory. The gene Wilder version 0:09:25.720 --> 0:09:28.720 that is the description they give for how Mike gets 0:09:28.720 --> 0:09:31.880 broken up into millions of tiny pieces and then flies 0:09:31.920 --> 0:09:34.480 through the air and gets reassembled on the other side. 0:09:35.080 --> 0:09:39.240 Is sort of like what happens with data packets sort of. Well, 0:09:39.240 --> 0:09:43.360 those packets, which tend to be pretty small like bytes, 0:09:43.600 --> 0:09:47.480 is common. They can all travel different pathways in order 0:09:47.520 --> 0:09:50.360 to get to their intended destination. If you think of 0:09:50.360 --> 0:09:55.040 the Internet as just a huge, interconnected series of roads 0:09:55.080 --> 0:09:57.000 that allow you to get from point A to point B, 0:09:57.120 --> 0:10:01.160 but you can choose literally thousand of different routes in 0:10:01.240 --> 0:10:03.720 order to do so. That's why, I mean, these packets 0:10:03.720 --> 0:10:08.679 can all travel different routes. This actually helps make information 0:10:08.800 --> 0:10:11.920 transfers more robust. I mean that makes sense, right, because 0:10:11.920 --> 0:10:14.840 if you were to send a really big file that 0:10:15.000 --> 0:10:17.040 could not be broken up, well, first of all, you'd 0:10:17.040 --> 0:10:19.120 have to have a connection that could handle that much 0:10:19.200 --> 0:10:22.160 data being sent all at once, and that connection would 0:10:22.160 --> 0:10:25.040 need the same throughput all the way to the destination, 0:10:25.640 --> 0:10:28.120 or you would have to divide up the information in 0:10:28.160 --> 0:10:30.560 some way. And if you did do that, if you 0:10:30.760 --> 0:10:33.160 broke it up into packets, but all those packets had 0:10:33.200 --> 0:10:36.760 to zip down the exact same pathway, and then something 0:10:36.840 --> 0:10:41.520 happened halfway through the transfer, uh, like maybe a connection broke, 0:10:41.720 --> 0:10:45.040 maybe a server went offline, whatever it might be, the 0:10:45.120 --> 0:10:48.360 incoming file would be incomplete on the receiving end. So 0:10:48.440 --> 0:10:54.000 packet switching helps ensure that communication between two computers across 0:10:54.080 --> 0:10:58.360 different networks can actually happen. But as you can imagine, 0:10:58.679 --> 0:11:01.440 if the users can computer is in one part of 0:11:01.440 --> 0:11:06.040 the world and the destination computer is on the other 0:11:06.160 --> 0:11:09.559 end of a communication channel on the other side of 0:11:09.600 --> 0:11:11.720 the world, then there might be a bit of a 0:11:11.760 --> 0:11:15.360 delay between sending something and getting something back because that's 0:11:15.360 --> 0:11:18.600 a lot of distance to travel, a lot of hops 0:11:18.640 --> 0:11:20.480 to make on the way. We'll talk about hops a 0:11:20.480 --> 0:11:24.400 bit later, and so you can encounter some latency. Now 0:11:24.480 --> 0:11:27.120 let's move ahead a little bit more and we get 0:11:27.160 --> 0:11:30.240 to the early days of cloud computing. The most basic 0:11:30.280 --> 0:11:33.840 definition I've ever heard about cloud computing is that it's computing, 0:11:34.240 --> 0:11:37.960 but it's happening on someone else's computer, which is pretty accurate, 0:11:38.240 --> 0:11:40.400 and there are a lot of subcategories we can talk about, 0:11:40.559 --> 0:11:44.720 like cloud storage that doesn't necessarily require any computing on 0:11:44.760 --> 0:11:47.920 the server side, but it does mean you're saving stuff 0:11:48.000 --> 0:11:51.640 to someone else's machine, or more likely saving stuff to 0:11:51.679 --> 0:11:56.480 someone else's several other machines for the sake of redundancy. 0:11:56.760 --> 0:11:59.960 Cloud computing is really useful because you're no longer worried 0:12:00.080 --> 0:12:03.200 about the device that the end user is relying upon 0:12:03.679 --> 0:12:07.160 to do heavy lifting. One of the really big frustrations 0:12:07.200 --> 0:12:11.160 of owning a computing devices that well, Moore's Law is 0:12:11.200 --> 0:12:14.920 a thing. Basically, we interpret Moore's law to mean that 0:12:15.360 --> 0:12:18.800 every two years or so, the new computer processors that 0:12:18.840 --> 0:12:21.520 are rolling out of clean rooms are about twice as 0:12:21.520 --> 0:12:24.280 powerful as the ones that came out two years earlier, 0:12:24.640 --> 0:12:29.680 so we see processor capabilities effectively doubling every two years. 0:12:30.200 --> 0:12:33.240 It's actually a little bit more nuanced than that interpretation, 0:12:33.280 --> 0:12:35.680 but I've done full episodes about Moore's law in the past, 0:12:36.040 --> 0:12:39.440 so we'll just go with the overly simplified but widely 0:12:39.600 --> 0:12:45.040 accepted definition. This tendency means that computer capabilities are on 0:12:45.080 --> 0:12:48.360 a pretty incredible trajectory. But the flip side of that 0:12:48.480 --> 0:12:51.720 coin is that any computer you buy today has a 0:12:51.800 --> 0:12:54.280 limited shelf life, at least as far as running the 0:12:54.320 --> 0:12:57.760 most current software goes. Even in the early days of 0:12:57.800 --> 0:13:00.600 personal computers, the joke was that by the time you 0:13:00.679 --> 0:13:04.679 got your computer home from the store, it was already obsolete. 0:13:05.040 --> 0:13:08.560 And that joke wasn't that funny because it felt all 0:13:08.679 --> 0:13:15.040 too true. Well, cloud computing offloads the computational lift off 0:13:15.080 --> 0:13:17.920 of the end user device and puts it on a 0:13:17.960 --> 0:13:22.440 server farm somewhere in the world. If the company providing 0:13:22.480 --> 0:13:25.679 the service is a really big one, or it's piggybacking 0:13:25.840 --> 0:13:29.439 off of a really big company like Amazon, then it 0:13:29.559 --> 0:13:33.480 might distribute those servers in different geographic regions. Otherwise it 0:13:33.480 --> 0:13:36.959 could be in a centralized data center somewhere. The server 0:13:37.120 --> 0:13:40.240 farm provides the number crunching, and it means that the 0:13:40.360 --> 0:13:43.560 end users machine doesn't have to be that advanced in 0:13:43.640 --> 0:13:46.760 order to take advantage of some heavy duty computing power. 0:13:47.360 --> 0:13:50.920 This is what enables devices like Chrome books from Google. 0:13:51.480 --> 0:13:55.480 These are very lightweight computers, both in terms of physical weight, 0:13:55.840 --> 0:13:59.920 and their native processing power. That's because Chrome books rely 0:14:00.160 --> 0:14:03.320 heavily on cloud based services, so a lot of the 0:14:03.360 --> 0:14:07.559 actual processing is happening on machines that could be hundreds 0:14:07.600 --> 0:14:11.600 of miles away. The Chrome book itself is kind of 0:14:11.640 --> 0:14:16.480 a conduit for computational services. It's doing some work, but 0:14:16.760 --> 0:14:19.760 not most of it. This is the same strategy that 0:14:19.800 --> 0:14:24.320 powers things like streaming game services like Google Stadia or 0:14:24.440 --> 0:14:29.200 Microsoft's Xbox Game Pass. The game's run on specialized hardware 0:14:29.480 --> 0:14:32.400 that can crank up the settings on demanding games and 0:14:32.440 --> 0:14:35.840 then deliver all of that over a streaming internet connection. 0:14:36.240 --> 0:14:38.200 So as long as you have a good connection to 0:14:38.240 --> 0:14:41.480 the Internet, you can enjoy a gaming experience that would 0:14:41.520 --> 0:14:44.200 otherwise require you to have a souped up gaming rig 0:14:44.320 --> 0:14:48.080 or console. But while this removes some of the burden 0:14:48.280 --> 0:14:51.000 from the end user, who might no longer need to 0:14:51.040 --> 0:14:53.520 go out and buy the best computer to run the 0:14:53.600 --> 0:14:57.880 latest software, because that gets pretty darn expensive, particularly if 0:14:57.920 --> 0:15:02.080 you're interested in gaming. A aiming rig can run thousands 0:15:02.200 --> 0:15:04.520 of dollars if you want something that's state of the art, 0:15:05.360 --> 0:15:08.840 but it does bump up against that fundamental speed limit 0:15:08.880 --> 0:15:11.560 that we mentioned at the beginning of this podcast. When 0:15:11.560 --> 0:15:14.520 we come back, we'll talk about how edge computing fits 0:15:14.600 --> 0:15:18.560 into this strategy. But first let's take a quick break. 0:15:26.000 --> 0:15:27.720 I've got a couple of other things that i need 0:15:27.760 --> 0:15:30.120 to say about network computing, and then I promised we're 0:15:30.160 --> 0:15:33.040 going to get to edge computing. One thing is that 0:15:33.120 --> 0:15:36.440 the Internet has made it possible to have the actual 0:15:36.560 --> 0:15:40.240 Internet of things. Now, back when I first heard this term, 0:15:40.320 --> 0:15:43.400 it didn't seem to be much more than just a buzzword. 0:15:43.800 --> 0:15:48.280 It was a concept that sounded intriguing but hadn't really 0:15:48.320 --> 0:15:51.520 begun to manifest in a way that was visible to 0:15:52.000 --> 0:15:55.920 the general public. But starting around the early twenty tens, 0:15:55.960 --> 0:15:59.280 that began to change. And today there are more than 0:15:59.400 --> 0:16:04.320 thirty billion IoT devices connecting to the Internet, with experts 0:16:04.400 --> 0:16:06.800 estimating that the total number will be somewhere in the 0:16:06.800 --> 0:16:09.720 neighborhood of thirty five billion by the end of this year, 0:16:10.040 --> 0:16:12.760 and it's just going to get bigger from there. And 0:16:12.840 --> 0:16:16.120 these devices are all across the spectrum when it comes 0:16:16.160 --> 0:16:20.760 to purpose and intended user base and what the outcome 0:16:20.960 --> 0:16:24.120 would be. You've got the consumer facing stuff that a 0:16:24.160 --> 0:16:27.240 lot of us have encountered, you know, everything from smart 0:16:27.320 --> 0:16:31.560 thermostats to home security systems to personal medical devices, to 0:16:32.280 --> 0:16:35.600 athletic trackers, all that kind of stuff. Then you've got 0:16:35.600 --> 0:16:41.120 more specialized variations like lab technology for hospitals and research facilities. 0:16:41.520 --> 0:16:46.160 You've got municipal infrastructure components that are turning traffic lights 0:16:46.160 --> 0:16:49.840 into smart intersections and that kind of thing. The variety 0:16:49.920 --> 0:16:54.920 and scope of the Internet of Things is unbelievable, and many, 0:16:54.960 --> 0:16:59.119 if not most, of these devices are pretty light lifters 0:16:59.160 --> 0:17:02.720 when it comes to processing information. For most of them, 0:17:02.760 --> 0:17:05.560 their main job is to gather data in some way, 0:17:05.840 --> 0:17:09.720 whether that's through optics or other sensors, and then they 0:17:09.760 --> 0:17:13.160 send that data up through the Internet, where some other 0:17:13.240 --> 0:17:17.399 system somewhere connected to the network will process the information 0:17:17.520 --> 0:17:21.600 and then presumably will do something with that info. So 0:17:21.680 --> 0:17:25.080 the output might be a readout that's useful to an 0:17:25.200 --> 0:17:28.119 end user, like it might be that you look at 0:17:28.160 --> 0:17:30.560 your phone and you're able to see input based upon 0:17:30.600 --> 0:17:32.800 the Internet of Things that are around you, or it 0:17:32.880 --> 0:17:36.600 might send that information off to some other related system 0:17:36.640 --> 0:17:39.359 so that a result will show up somewhere else, maybe 0:17:39.400 --> 0:17:43.320 in a way that isn't even obvious to us. The 0:17:43.359 --> 0:17:46.920 traffic light example could be a version of that, right, 0:17:47.000 --> 0:17:50.720 You could have a citywide system of connected smart traffic 0:17:50.800 --> 0:17:55.000 lights that could detect changes in traffic patterns and perhaps 0:17:55.160 --> 0:17:59.840 respond proactively in an effort to minimize congestion. For example. 0:18:00.440 --> 0:18:04.439 This is actually a really really complicated problem. It's not 0:18:04.560 --> 0:18:07.600 something that's simple to solve, but it would be impossible 0:18:07.640 --> 0:18:10.639 to solve unless you had a sort of Internet of 0:18:10.680 --> 0:18:14.399 things infrastructure to collect and process all that data. But 0:18:14.600 --> 0:18:18.159 the era of lightweight devices connected to the Internet really 0:18:18.200 --> 0:18:21.600 brings into focus the limitations we face if we rely 0:18:21.880 --> 0:18:26.080 on centralized data centers. The further out you are from 0:18:26.119 --> 0:18:29.119 that data center, the more delay there's going to be 0:18:29.520 --> 0:18:32.639 as the devices in your area are trying to communicate 0:18:32.760 --> 0:18:36.760 back with that distant center. There's just no getting around that, 0:18:36.880 --> 0:18:40.440 because even if we made a perfect conduit between the 0:18:40.520 --> 0:18:43.800 data center and the end device, we'd still be limited 0:18:43.800 --> 0:18:46.880 by the fact that light has a speed limit. And 0:18:46.960 --> 0:18:50.080 here's where edge computing finally really comes into play. Now. 0:18:50.119 --> 0:18:52.199 I should also mention that edge computing is one of 0:18:52.200 --> 0:18:55.960 those things that has a few different interpretations and definitions. 0:18:56.440 --> 0:18:59.560 What it is largely depends upon whom you are talking 0:18:59.640 --> 0:19:04.280 to about it, so you might get slightly different definitions, 0:19:04.320 --> 0:19:07.160 but there are some general features that I think are 0:19:07.160 --> 0:19:11.840 common across all definitions. So if we visualize a typical 0:19:11.920 --> 0:19:15.720 cloud computer network, we might think of a centralized data 0:19:15.800 --> 0:19:19.960 center that connects out to various end points. Edge computing 0:19:20.280 --> 0:19:23.080 is a practice in which a company locates servers at 0:19:23.160 --> 0:19:27.280 the edge of networks. In other words, you are creating 0:19:27.320 --> 0:19:30.600 servers that can do data processing, and you are putting 0:19:30.640 --> 0:19:33.520 them close to where the data is actually being gathered 0:19:33.640 --> 0:19:37.960 or generated as and you're putting it physically close to them. So, 0:19:38.119 --> 0:19:41.800 for example, I live in the city of Atlanta, Georgia. 0:19:42.040 --> 0:19:46.520 Now let's say that Amazon's Web Services, which provides hosting 0:19:46.600 --> 0:19:50.640 services to thousands of different apps and processes. Let's say 0:19:50.640 --> 0:19:54.119 that they were all located in the state of Washington, 0:19:54.240 --> 0:19:57.879 that's where Amazon has its prime headquarters. Well, that's about 0:19:57.960 --> 0:20:02.000 two thousand, sixty five miles away from me, around four 0:20:02.040 --> 0:20:06.960 thousand two kilometers. So if I'm running an application that 0:20:07.119 --> 0:20:11.000 needs super fast response times in other words, I need 0:20:11.119 --> 0:20:14.679 really low latency, then I'm probably going to have a 0:20:14.680 --> 0:20:18.280 bad experience because the data has to travel pretty far, 0:20:18.680 --> 0:20:21.960 and it's not necessarily going in anything like a straight line, 0:20:22.040 --> 0:20:25.960 because that's not how data traveling on the Internet works. 0:20:26.560 --> 0:20:30.159 It's likely having to go through multiple hops, so I 0:20:30.200 --> 0:20:33.480 mentioned hops earlier. A hop is when a data packet 0:20:33.560 --> 0:20:37.360 moves from one network segment to the next network segment, 0:20:37.760 --> 0:20:39.800 So you can think of it as like hopping from 0:20:39.840 --> 0:20:41.639 one router to the next in order to get to 0:20:41.680 --> 0:20:45.200 its final destination. And the more hops that there are 0:20:45.280 --> 0:20:48.640 between me and the server that's running the app I'm 0:20:48.680 --> 0:20:52.600 actually using, the more latency I'm going to experience because 0:20:52.640 --> 0:20:55.119 the data has to travel more hops in order to 0:20:55.160 --> 0:20:57.680 get to the server that's doing all the number crunching 0:20:58.080 --> 0:21:00.000 then has to do the same thing in order to 0:21:00.119 --> 0:21:03.240 return results to me. So I'm going to experience this 0:21:03.520 --> 0:21:08.840 as lag or latency. But if Amazon instead set up 0:21:09.000 --> 0:21:13.520 different regional server farms around the world and located edge 0:21:13.520 --> 0:21:17.040 servers at those spots, the edge servers could take over 0:21:17.080 --> 0:21:21.680 the immediate processing requirements. So let's say Amazon set up 0:21:21.760 --> 0:21:25.959 that kind of data center in Atlanta where I live now. 0:21:26.400 --> 0:21:29.400 Instead of my device whatever it might be connecting back 0:21:29.440 --> 0:21:34.200 to Amazon's home headquarters in Seattle, Washington, it's instead connecting 0:21:34.240 --> 0:21:38.760 to this much closer edge server in Atlanta. The edge 0:21:38.760 --> 0:21:42.040 server can carry out whatever the immediate function is that 0:21:42.080 --> 0:21:45.680 I'm trying to do so. Maybe now the data traveling 0:21:45.720 --> 0:21:48.120 between me and the edge server is only going through 0:21:48.359 --> 0:21:51.320 one or two hops. Not only is it traveling a 0:21:51.359 --> 0:21:55.440 shorter physical distance, it is having to make fewer transitions 0:21:55.600 --> 0:21:59.280 from one machine like a router on the Internet, to 0:21:59.480 --> 0:22:01.119 the next than it would if it were to go 0:22:01.200 --> 0:22:03.560 all the way back to Seattle. And the reduction in 0:22:03.640 --> 0:22:07.480 hops is critical for reducing latency. Now, this doesn't mean 0:22:07.520 --> 0:22:13.320 that edge servers totally replace centralized data centers. Instead, they 0:22:13.359 --> 0:22:18.840 work in concert with those centralized data centers. Edge servers 0:22:19.040 --> 0:22:22.080 kind of act as a point of processing for quick response, 0:22:22.720 --> 0:22:26.399 but you might want to have deeper analytical work being 0:22:26.440 --> 0:22:30.920 done by your centralized server. This work isn't necessarily as 0:22:30.960 --> 0:22:33.879 time sensitive, and in fact, the results of that work 0:22:33.960 --> 0:22:37.440 might not return to the end user like me at all. 0:22:37.720 --> 0:22:41.600 It might be things like trend analysis, where you're looking 0:22:41.760 --> 0:22:46.960 at millions of different transactions over a course of months 0:22:46.960 --> 0:22:50.000 and months and then drawing conclusions from that data. Well, 0:22:50.040 --> 0:22:53.880 that's not as time sensitive. That's literally looking at changes 0:22:54.000 --> 0:22:57.240 over time. So that can be done in a big 0:22:57.320 --> 0:23:00.840 centralized data center. It doesn't need to be offloaded to 0:23:01.760 --> 0:23:05.639 the servers that are geographically close to me. Let's take 0:23:05.760 --> 0:23:08.880 an actual example. Let's say I'm using an augmented reality 0:23:08.920 --> 0:23:13.520 headset that connects wirelessly to hot spots and cellular networks. 0:23:13.600 --> 0:23:17.280 So this is an actual headset that I'm wearing. I've 0:23:17.320 --> 0:23:20.399 got a battery pack for it, and it's communicating with 0:23:20.520 --> 0:23:23.720 the network. I'm walking through Atlanta and I'm looking at 0:23:23.800 --> 0:23:28.679 various features, and the augmented headset is displaying information about 0:23:28.760 --> 0:23:31.159 the stuff I'm looking at, and I can see the 0:23:31.240 --> 0:23:34.040 information within my view. It's overlaid on top of my 0:23:34.160 --> 0:23:37.320 view of the world around me. The headset would likely 0:23:37.359 --> 0:23:42.560 be fitted with stuff like a GPS chip, accelerometers, magnetometer 0:23:42.760 --> 0:23:46.600 for compass directions, camera to identify what it is I'm 0:23:46.680 --> 0:23:50.680 looking at, a processor, and so on. The headset needs 0:23:50.680 --> 0:23:54.159 to relay data to servers to process this information, to 0:23:54.320 --> 0:23:58.879 interpret it, and then to return relevant information to my view. 0:23:59.320 --> 0:24:01.800 The reason you why do this is because by offloading 0:24:02.040 --> 0:24:06.639 those computational requirements to another machine, you don't have to 0:24:06.680 --> 0:24:10.159 make the a R goggles way like fifty pounds and 0:24:10.760 --> 0:24:14.800 have big cooling systems attached and everything, because they don't 0:24:14.840 --> 0:24:18.080 have to do as heavy a lift in the computational department. 0:24:18.760 --> 0:24:23.359 But this has to happen really fast, otherwise I'm going 0:24:23.400 --> 0:24:26.399 to see information about what I had been looking at 0:24:26.840 --> 0:24:30.640 a few moments before while I'm now looking at something else, 0:24:30.640 --> 0:24:33.600 which would be really disorienting. I might look at a 0:24:33.640 --> 0:24:36.520 historic building and I might wonder, oh, I wonder what 0:24:36.720 --> 0:24:40.159 this building used to be, and then I happen to 0:24:40.200 --> 0:24:42.280 look away and I'm looking at a tree or something, 0:24:42.320 --> 0:24:45.320