Speaker 1: Welcome to Tech Stuff, a production from I Heart Radio.
Speaker 1: Hey there, and welcome to tech Stuff. I'm your host,
Speaker 1: Jonathan Strickland. I'm an executive producer with I Heart Radio,
Speaker 1: and I love all things tech. And over the history
Speaker 1: of this podcast, I have covered a lot of topics
Speaker 1: that were, at least at one time a little more
Speaker 1: than buzzwords to me, cloud computing, machine learning, Internet of things.
Speaker 1: A lot of these topics were either just not widely
Speaker 1: spoken about in mainstream society or they were even just
Speaker 1: emerging within the tech world itself. This is where I
Speaker 1: have to remind all of you that I came into
Speaker 1: tech Stuff as someone who loved technology, but who is not,
Speaker 1: in actuality technologist or an engineer or anything like that.
Speaker 1: And one of the terms that I started running into
Speaker 1: around fourteen or so, so it was after I had
Speaker 1: started this podcast. One of those terms was edge computing,
Speaker 1: or sometimes computing at the edge. And if you listen
Speaker 1: to yesterday's Smart Talks episode with Malcolm Gladwell, you heard
Speaker 1: a little bit about that in there, and now we're
Speaker 1: gonna dive in whole hog. So today I thought we'd
Speaker 1: talked a bit about what edge computing actually means and
Speaker 1: contrast it with other types of computing models, and we'll
Speaker 1: talk about how all of this is meant to work
Speaker 1: together in different ways, and why it's even a thing
Speaker 1: in the first place, and where edge computing is today
Speaker 1: and what we might think of it in the future.
Speaker 1: I thought that a good way to approach edge computing
Speaker 1: is really to start with some basic facts. There are
Speaker 1: certain things that we, as smarty pants human types, can
Speaker 1: do to speed up computer systems, To speed up the
Speaker 1: the moment from where we put input into a system
Speaker 1: to an we get output from that system. We can
Speaker 1: create more efficient and powerful processors. For example, you know,
Speaker 1: we can lean on parallel processing for some types of
Speaker 1: computer problems. Doesn't work for everything. Quantum computing, similarly, will
Speaker 1: speed up certain types of computer problems exponentially. We can
Speaker 1: design better software, and we can try to avoid Worth's law.
Speaker 1: That's what the law that states that software tends to
Speaker 1: get slower at a rate that's faster than improvements in hardware.
Speaker 1: If we do combinations of all these sort of strategies,
Speaker 1: then the machines of tomorrow will in theory run software
Speaker 1: better than the machines of today. Again, assuming we don't
Speaker 1: just make even more bloated software that ends up canceling
Speaker 1: out our sick hardware gains. But there's one thing that
Speaker 1: we just cannot get around, and that is the top
Speaker 1: speed at which information can travel from one point to another.
Speaker 1: Even using a fiber optic cable and a clever optical
Speaker 1: system to deliver information, we are limited by the speed
Speaker 1: of light itself. Now that speed is um let me
Speaker 1: check my notes here says wicked fast. When traveling through
Speaker 1: a vacuum, light zips along at two hundred million, seven
Speaker 1: hundred thousand, four hundred fifty eight meters per second. Nothing
Speaker 1: goes faster, thanks a lot, Einstein. What this means for
Speaker 1: us is that distance matters. Of course, until fairly recently,
Speaker 1: this wasn't the biggest concern for us because the way
Speaker 1: we did computing was pretty much always right up close
Speaker 1: and personal. So let's talk about that for a second, alright. So,
Speaker 1: to begin with, we have computers that we physically access
Speaker 1: in some way in order to carry out a program.
Speaker 1: So in the very early days, people program computers by
Speaker 1: physically plugging in different cables into different sockets and throwing
Speaker 1: switches and I don't know, waiting for lightning to strike
Speaker 1: or something. Okay, ignore that last bit. The process was tedious,
Speaker 1: it was complicated, it was easy to come up. The
Speaker 1: speed of the computer was limited both by its own
Speaker 1: method of processing information as well as the speed at
Speaker 1: which human operators could operate it. But once the computer
Speaker 1: actually finished the calculations, delivering them was pretty fast. I mean,
Speaker 1: sometimes delivering meant printing out a sheet of paper or
Speaker 1: making little lights on a panel light up a specific way,
Speaker 1: and then the humans would have to consult a guide
Speaker 1: to figure out what that all meant. But if the
Speaker 1: computer had had a display, it would be able to
Speaker 1: throw up the answer as soon as it got there
Speaker 1: with zero delay. Flash forward a few decades, and we
Speaker 1: then had computers that had simplified input and output devices.
Speaker 1: You had your keyboards, you had your monitors and what not. Now,
Speaker 1: programming a computer was far less convoluted, though as programming
Speaker 1: language is evolved, it can still be fairly easy for
Speaker 1: a human to gum things up with a careless error
Speaker 1: or a miscalculation or typo. Again, most of the time
Speaker 1: we were talking about people being all right up on
Speaker 1: the computer, and so there was really no delay between
Speaker 1: the machine arriving at the endpoint of a computational process
Speaker 1: and then delivering the result to the person who was
Speaker 1: using the computer. The information wasn't really traveling anywhere, it
Speaker 1: was just there. Then we get ARPA, the Advanced Research
Speaker 1: Projects Agency. It's the predecessor to DARPA. One of the
Speaker 1: projects ARPA tackled was to find a way to network
Speaker 1: different types of computers together. This was a big challenge
Speaker 1: for several reasons, but one of them was that different
Speaker 1: computers ran on very different processes and what we'll call
Speaker 1: them operating systems, but that's really being a bit general us.
Speaker 1: But the point is that the computers from different manufacturers,
Speaker 1: effectively they spoke different languages and they could not directly
Speaker 1: communicate with one another. And in the easy way boiled down,
Speaker 1: the computers spoke math, but it was kind of like
Speaker 1: wildly different dialects of math. So there needed to be
Speaker 1: some sort of common language that all computers would be
Speaker 1: able to convert their native speech into and then translate
Speaker 1: incoming speech back into their native language. Now that's a
Speaker 1: super oversimplified way to say that very smart people built
Speaker 1: out the protocols that would allow for the transfer of
Speaker 1: information across networks we would eventually get stuff like T
Speaker 1: C P I P that would facilitate these connections. Now
Speaker 1: computers could connect into their network and they would be
Speaker 1: able to send information to and receive information from other
Speaker 1: computers on that same network. And as other networks took shape,
Speaker 1: they could interconnect with that first network, and then we
Speaker 1: got the network of networks, or the Internet. So I'm
Speaker 1: giving a really fast rundown of the history of the
Speaker 1: Internet here. This is like from space levels of high
Speaker 1: level view of the history of the Internet. All right,
Speaker 1: now we're gonna skip way ahead. Let's get up to
Speaker 1: the ninety nineties, where the general public became aware that
Speaker 1: there was this thing called the Internet, and the development
Speaker 1: and deployment of the Worldwide Web really helped that along considerably.
Speaker 1: Now we had this information super highway, or if you prefer,
Speaker 1: we had a series of pipes that let information flow
Speaker 1: from one source to another. Using this vast network of machines,
Speaker 1: we could send messages to friends on the other side
Speaker 1: of the planet, or check in on a particular coffee
Speaker 1: pot at the computer lab in the University of Cambridge
Speaker 1: in England, even if we happened to be in Athens, Georgia,
Speaker 1: at the time. This, by the way, was actually a
Speaker 1: thing that once existed. And yes I did use a
Speaker 1: computer in the University of Georgia Computer Lab to check
Speaker 1: and see whether or not there was coffee in a
Speaker 1: coffee pot across the pond. Normally there wasn't because I
Speaker 1: was often in there in the afternoon and it was
Speaker 1: several hours later over in the UK. But you get
Speaker 1: the point now. The way the information actually travels across
Speaker 1: the Internet is pretty fascinating. First, information travels in bunches
Speaker 1: of data called packets, and this was a brilliant move
Speaker 1: early on in the development of networking technology. When computers
Speaker 1: send data across the Internet, they chopped that data up
Speaker 1: into packets, and a packet has two different kinds of
Speaker 1: data in it. There's data that's all about control information.
Speaker 1: So in other words, this is the data that explains
Speaker 1: where the packet came from, where it's going to, how
Speaker 1: many other packets the receiving computers should get in order
Speaker 1: to make up the entire file, and where within that
Speaker 1: sequence this particular packet should go. So you can think
Speaker 1: of that information is sort of like being the information
Speaker 1: on the outside of an envelope that you would send
Speaker 1: through the mail. Then you've got the payload or the
Speaker 1: data that relates to the file itself, the thing you
Speaker 1: are sending. The packets are kind of like puzzle pieces
Speaker 1: that get reassembled on the other side. Actually, think of
Speaker 1: it a lot like the sequence of Mike TV and
Speaker 1: Willie Wonka and the Chocolate Factory. The gene Wilder version
Speaker 1: that is the description they give for how Mike gets
Speaker 1: broken up into millions of tiny pieces and then flies
Speaker 1: through the air and gets reassembled on the other side.
Speaker 1: Is sort of like what happens with data packets sort of. Well,
Speaker 1: those packets, which tend to be pretty small like bytes,
Speaker 1: is common. They can all travel different pathways in order
Speaker 1: to get to their intended destination. If you think of
Speaker 1: the Internet as just a huge, interconnected series of roads
Speaker 1: that allow you to get from point A to point B,
Speaker 1: but you can choose literally thousand of different routes in
Speaker 1: order to do so. That's why, I mean, these packets
Speaker 1: can all travel different routes. This actually helps make information
Speaker 1: transfers more robust. I mean that makes sense, right, because
Speaker 1: if you were to send a really big file that
Speaker 1: could not be broken up, well, first of all, you'd
Speaker 1: have to have a connection that could handle that much
Speaker 1: data being sent all at once, and that connection would
Speaker 1: need the same throughput all the way to the destination,
Speaker 1: or you would have to divide up the information in
Speaker 1: some way. And if you did do that, if you
Speaker 1: broke it up into packets, but all those packets had
Speaker 1: to zip down the exact same pathway, and then something
Speaker 1: happened halfway through the transfer, uh, like maybe a connection broke,
Speaker 1: maybe a server went offline, whatever it might be, the
Speaker 1: incoming file would be incomplete on the receiving end. So
Speaker 1: packet switching helps ensure that communication between two computers across
Speaker 1: different networks can actually happen. But as you can imagine,
Speaker 1: if the users can computer is in one part of
Speaker 1: the world and the destination computer is on the other
Speaker 1: end of a communication channel on the other side of
Speaker 1: the world, then there might be a bit of a
Speaker 1: delay between sending something and getting something back because that's
Speaker 1: a lot of distance to travel, a lot of hops
Speaker 1: to make on the way. We'll talk about hops a
Speaker 1: bit later, and so you can encounter some latency. Now
Speaker 1: let's move ahead a little bit more and we get
Speaker 1: to the early days of cloud computing. The most basic
Speaker 1: definition I've ever heard about cloud computing is that it's computing,
Speaker 1: but it's happening on someone else's computer, which is pretty accurate,
Speaker 1: and there are a lot of subcategories we can talk about,
Speaker 1: like cloud storage that doesn't necessarily require any computing on
Speaker 1: the server side, but it does mean you're saving stuff
Speaker 1: to someone else's machine, or more likely saving stuff to
Speaker 1: someone else's several other machines for the sake of redundancy.
Speaker 1: Cloud computing is really useful because you're no longer worried
Speaker 1: about the device that the end user is relying upon
Speaker 1: to do heavy lifting. One of the really big frustrations
Speaker 1: of owning a computing devices that well, Moore's Law is
Speaker 1: a thing. Basically, we interpret Moore's law to mean that
Speaker 1: every two years or so, the new computer processors that
Speaker 1: are rolling out of clean rooms are about twice as
Speaker 1: powerful as the ones that came out two years earlier,
Speaker 1: so we see processor capabilities effectively doubling every two years.
Speaker 1: It's actually a little bit more nuanced than that interpretation,
Speaker 1: but I've done full episodes about Moore's law in the past,
Speaker 1: so we'll just go with the overly simplified but widely
Speaker 1: accepted definition. This tendency means that computer capabilities are on
Speaker 1: a pretty incredible trajectory. But the flip side of that
Speaker 1: coin is that any computer you buy today has a
Speaker 1: limited shelf life, at least as far as running the
Speaker 1: most current software goes. Even in the early days of
Speaker 1: personal computers, the joke was that by the time you
Speaker 1: got your computer home from the store, it was already obsolete.
Speaker 1: And that joke wasn't that funny because it felt all
Speaker 1: too true. Well, cloud computing offloads the computational lift off
Speaker 1: of the end user device and puts it on a
Speaker 1: server farm somewhere in the world. If the company providing
Speaker 1: the service is a really big one, or it's piggybacking
Speaker 1: off of a really big company like Amazon, then it
Speaker 1: might distribute those servers in different geographic regions. Otherwise it
Speaker 1: could be in a centralized data center somewhere. The server
Speaker 1: farm provides the number crunching, and it means that the
Speaker 1: end users machine doesn't have to be that advanced in
Speaker 1: order to take advantage of some heavy duty computing power.
Speaker 1: This is what enables devices like Chrome books from Google.
Speaker 1: These are very lightweight computers, both in terms of physical weight,
Speaker 1: and their native processing power. That's because Chrome books rely
Speaker 1: heavily on cloud based services, so a lot of the
Speaker 1: actual processing is happening on machines that could be hundreds
Speaker 1: of miles away. The Chrome book itself is kind of
Speaker 1: a conduit for computational services. It's doing some work, but
Speaker 1: not most of it. This is the same strategy that
Speaker 1: powers things like streaming game services like Google Stadia or
Speaker 1: Microsoft's Xbox Game Pass. The game's run on specialized hardware
Speaker 1: that can crank up the settings on demanding games and
Speaker 1: then deliver all of that over a streaming internet connection.
Speaker 1: So as long as you have a good connection to
Speaker 1: the Internet, you can enjoy a gaming experience that would
Speaker 1: otherwise require you to have a souped up gaming rig
Speaker 1: or console. But while this removes some of the burden
Speaker 1: from the end user, who might no longer need to
Speaker 1: go out and buy the best computer to run the
Speaker 1: latest software, because that gets pretty darn expensive, particularly if
Speaker 1: you're interested in gaming. A aiming rig can run thousands
Speaker 1: of dollars if you want something that's state of the art,
Speaker 1: but it does bump up against that fundamental speed limit
Speaker 1: that we mentioned at the beginning of this podcast. When
Speaker 1: we come back, we'll talk about how edge computing fits
Speaker 1: into this strategy. But first let's take a quick break.
Speaker 1: I've got a couple of other things that i need
Speaker 1: to say about network computing, and then I promised we're
Speaker 1: going to get to edge computing. One thing is that
Speaker 1: the Internet has made it possible to have the actual
Speaker 1: Internet of things. Now, back when I first heard this term,
Speaker 1: it didn't seem to be much more than just a buzzword.
Speaker 1: It was a concept that sounded intriguing but hadn't really
Speaker 1: begun to manifest in a way that was visible to
Speaker 1: the general public. But starting around the early twenty tens,
Speaker 1: that began to change. And today there are more than
Speaker 1: thirty billion IoT devices connecting to the Internet, with experts
Speaker 1: estimating that the total number will be somewhere in the
Speaker 1: neighborhood of thirty five billion by the end of this year,
Speaker 1: and it's just going to get bigger from there. And
Speaker 1: these devices are all across the spectrum when it comes
Speaker 1: to purpose and intended user base and what the outcome
Speaker 1: would be. You've got the consumer facing stuff that a
Speaker 1: lot of us have encountered, you know, everything from smart
Speaker 1: thermostats to home security systems to personal medical devices, to
Speaker 1: athletic trackers, all that kind of stuff. Then you've got
Speaker 1: more specialized variations like lab technology for hospitals and research facilities.
Speaker 1: You've got municipal infrastructure components that are turning traffic lights
Speaker 1: into smart intersections and that kind of thing. The variety
Speaker 1: and scope of the Internet of Things is unbelievable, and many,
Speaker 1: if not most, of these devices are pretty light lifters
Speaker 1: when it comes to processing information. For most of them,
Speaker 1: their main job is to gather data in some way,
Speaker 1: whether that's through optics or other sensors, and then they
Speaker 1: send that data up through the Internet, where some other
Speaker 1: system somewhere connected to the network will process the information
Speaker 1: and then presumably will do something with that info. So
Speaker 1: the output might be a readout that's useful to an
Speaker 1: end user, like it might be that you look at
Speaker 1: your phone and you're able to see input based upon
Speaker 1: the Internet of Things that are around you, or it
Speaker 1: might send that information off to some other related system
Speaker 1: so that a result will show up somewhere else, maybe
Speaker 1: in a way that isn't even obvious to us. The
Speaker 1: traffic light example could be a version of that, right,
Speaker 1: You could have a citywide system of connected smart traffic
Speaker 1: lights that could detect changes in traffic patterns and perhaps
Speaker 1: respond proactively in an effort to minimize congestion. For example.
Speaker 1: This is actually a really really complicated problem. It's not
Speaker 1: something that's simple to solve, but it would be impossible
Speaker 1: to solve unless you had a sort of Internet of
Speaker 1: things infrastructure to collect and process all that data. But
Speaker 1: the era of lightweight devices connected to the Internet really
Speaker 1: brings into focus the limitations we face if we rely
Speaker 1: on centralized data centers. The further out you are from
Speaker 1: that data center, the more delay there's going to be
Speaker 1: as the devices in your area are trying to communicate
Speaker 1: back with that distant center. There's just no getting around that,
Speaker 1: because even if we made a perfect conduit between the
Speaker 1: data center and the end device, we'd still be limited
Speaker 1: by the fact that light has a speed limit. And
Speaker 1: here's where edge computing finally really comes into play. Now.
Speaker 1: I should also mention that edge computing is one of
Speaker 1: those things that has a few different interpretations and definitions.
Speaker 1: What it is largely depends upon whom you are talking
Speaker 1: to about it, so you might get slightly different definitions,
Speaker 1: but there are some general features that I think are
Speaker 1: common across all definitions. So if we visualize a typical
Speaker 1: cloud computer network, we might think of a centralized data
Speaker 1: center that connects out to various end points. Edge computing
Speaker 1: is a practice in which a company locates servers at
Speaker 1: the edge of networks. In other words, you are creating
Speaker 1: servers that can do data processing, and you are putting
Speaker 1: them close to where the data is actually being gathered
Speaker 1: or generated as and you're putting it physically close to them. So,
Speaker 1: for example, I live in the city of Atlanta, Georgia.
Speaker 1: Now let's say that Amazon's Web Services, which provides hosting
Speaker 1: services to thousands of different apps and processes. Let's say
Speaker 1: that they were all located in the state of Washington,
Speaker 1: that's where Amazon has its prime headquarters. Well, that's about
Speaker 1: two thousand, sixty five miles away from me, around four
Speaker 1: thousand two kilometers. So if I'm running an application that
Speaker 1: needs super fast response times in other words, I need
Speaker 1: really low latency, then I'm probably going to have a
Speaker 1: bad experience because the data has to travel pretty far,
Speaker 1: and it's not necessarily going in anything like a straight line,
Speaker 1: because that's not how data traveling on the Internet works.
Speaker 1: It's likely having to go through multiple hops, so I
Speaker 1: mentioned hops earlier. A hop is when a data packet
Speaker 1: moves from one network segment to the next network segment,
Speaker 1: So you can think of it as like hopping from
Speaker 1: one router to the next in order to get to
Speaker 1: its final destination. And the more hops that there are
Speaker 1: between me and the server that's running the app I'm
Speaker 1: actually using, the more latency I'm going to experience because
Speaker 1: the data has to travel more hops in order to
Speaker 1: get to the server that's doing all the number crunching
Speaker 1: then has to do the same thing in order to
Speaker 1: return results to me. So I'm going to experience this
Speaker 1: as lag or latency. But if Amazon instead set up
Speaker 1: different regional server farms around the world and located edge
Speaker 1: servers at those spots, the edge servers could take over
Speaker 1: the immediate processing requirements. So let's say Amazon set up
Speaker 1: that kind of data center in Atlanta where I live now.
Speaker 1: Instead of my device whatever it might be connecting back
Speaker 1: to Amazon's home headquarters in Seattle, Washington, it's instead connecting
Speaker 1: to this much closer edge server in Atlanta. The edge
Speaker 1: server can carry out whatever the immediate function is that
Speaker 1: I'm trying to do so. Maybe now the data traveling
Speaker 1: between me and the edge server is only going through
Speaker 1: one or two hops. Not only is it traveling a
Speaker 1: shorter physical distance, it is having to make fewer transitions
Speaker 1: from one machine like a router on the Internet, to
Speaker 1: the next than it would if it were to go
Speaker 1: all the way back to Seattle. And the reduction in
Speaker 1: hops is critical for reducing latency. Now, this doesn't mean
Speaker 1: that edge servers totally replace centralized data centers. Instead, they
Speaker 1: work in concert with those centralized data centers. Edge servers
Speaker 1: kind of act as a point of processing for quick response,
Speaker 1: but you might want to have deeper analytical work being
Speaker 1: done by your centralized server. This work isn't necessarily as
Speaker 1: time sensitive, and in fact, the results of that work
Speaker 1: might not return to the end user like me at all.
Speaker 1: It might be things like trend analysis, where you're looking
Speaker 1: at millions of different transactions over a course of months
Speaker 1: and months and then drawing conclusions from that data. Well,
Speaker 1: that's not as time sensitive. That's literally looking at changes
Speaker 1: over time. So that can be done in a big
Speaker 1: centralized data center. It doesn't need to be offloaded to
Speaker 1: the servers that are geographically close to me. Let's take
Speaker 1: an actual example. Let's say I'm using an augmented reality
Speaker 1: headset that connects wirelessly to hot spots and cellular networks.
Speaker 1: So this is an actual headset that I'm wearing. I've
Speaker 1: got a battery pack for it, and it's communicating with
Speaker 1: the network. I'm walking through Atlanta and I'm looking at
Speaker 1: various features, and the augmented headset is displaying information about
Speaker 1: the stuff I'm looking at, and I can see the
Speaker 1: information within my view. It's overlaid on top of my
Speaker 1: view of the world around me. The headset would likely
Speaker 1: be fitted with stuff like a GPS chip, accelerometers, magnetometer
Speaker 1: for compass directions, camera to identify what it is I'm
Speaker 1: looking at, a processor, and so on. The headset needs
Speaker 1: to relay data to servers to process this information, to
Speaker 1: interpret it, and then to return relevant information to my view.
Speaker 1: The reason you why do this is because by offloading
Speaker 1: those computational requirements to another machine, you don't have to
Speaker 1: make the a R goggles way like fifty pounds and
Speaker 1: have big cooling systems attached and everything, because they don't
Speaker 1: have to do as heavy a lift in the computational department.
Speaker 1: But this has to happen really fast, otherwise I'm going
Speaker 1: to see information about what I had been looking at
Speaker 1: a few moments before while I'm now looking at something else,
Speaker 1: which would be really disorienting. I might look at a
Speaker 1: historic building and I might wonder, oh, I wonder what
Speaker 1: this building used to be, and then I happen to
Speaker 1: look away and I'm looking at a tree or something,
Speaker 1: and then I see that, apparently that tree is actually
Speaker 1: the historic Wren's nest, which was the home of the
Speaker 1: controversial author Joel Chandler Harris. And heck, I might just
Speaker 1: think that my headset detected that there's an actual wren's
Speaker 1: nest in the tree I'm looking at. It would be confusing.
Speaker 1: So applications like streaming video games two players using a
Speaker 1: specialized device, edge computing is absolutely critical. Like a R
Speaker 1: and VR, latency will ruin your experience in gaming, There's
Speaker 1: nothing like playing a game and feeling that bit of
Speaker 1: lag between when you press a button and when something
Speaker 1: actually happens on screen. You don't want there to be
Speaker 1: a perceptible delay between hitting a jump button and having
Speaker 1: your little Italian plumber dude actually jump. You want that
Speaker 1: to feel seamless, and humans are pretty sensitive to delay.
Speaker 1: You would want there to be less than one hundred
Speaker 1: milliseconds or one hundred thousands of a second, but even
Speaker 1: that is a little long. The general consensus is that
Speaker 1: the goal post is to have delays of less than
Speaker 1: twenty milliseconds, and that is fast enough so that our
Speaker 1: mushy brains don't really process any kind of delay. If
Speaker 1: you've ever used a VR application that has even a
Speaker 1: tiny bit of latency in it, you've probably felt a
Speaker 1: sort of unpleasant swimming sensation that can frequently lead to
Speaker 1: a type of motion sickness. It's because you're sensing that
Speaker 1: delay between when you turn your head and when your
Speaker 1: actual point of view within the virtual environment adjusts, and
Speaker 1: your brain says, hey, something is like really wrong here,
Speaker 1: and then it sends a message to your stomach to
Speaker 1: go hog wild because somehow that's going to fix things
Speaker 1: all right. My understanding of biology is admittedly a little
Speaker 1: limited here, but the important bit is that latency is
Speaker 1: bad and we must do our best to eliminate it.
Speaker 1: A r VR and game streaming are all really obvious
Speaker 1: examples of technologies that rely on low latency response time.
Speaker 1: While also typically requiring a high data throughput communication channel.
Speaker 1: So when you hear people talking about applications that require
Speaker 1: stuff like five G connectivity and edge computing, a r VR,
Speaker 1: video games, those are all typically part the conversation. And
Speaker 1: before I go further, I shall also clarify that I
Speaker 1: specifically mean high frequency five G connectivity. If you've listened
Speaker 1: to my episodes about five G, you know that there
Speaker 1: are a few different flavors of that technology, all of
Speaker 1: which relate to the band of radio frequencies that are
Speaker 1: being used. The higher end frequencies within five G can
Speaker 1: carry an incredible amount of information all at once. These
Speaker 1: are bands of frequencies that provide data speeds that rival
Speaker 1: that of dedicated fiber optic lines. But these frequencies also
Speaker 1: don't travel very far and they can't penetrate solid walls
Speaker 1: very well, so you quickly lose out on that high
Speaker 1: volume throughput if you move away from the transmission antenna
Speaker 1: or something comes between you and it. It's why a
Speaker 1: really robust high speed five G network would need a
Speaker 1: lot of towers to make it work. Anyway, the five
Speaker 1: G would be the communication channel, while edge computing would
Speaker 1: provide the actual proces sessing capabilities to return relevant information quickly.
Speaker 1: You can imagine how edge computing would be important for
Speaker 1: all sorts of applications, not just VR, A R and
Speaker 1: video games. The Internet of Things depends pretty heavily on
Speaker 1: edge computing, as the end devices, like I said, tend
Speaker 1: to be pretty simple. A lot of IoT devices boiled
Speaker 1: down to a sensor that detects some sort of dynamic element,
Speaker 1: you know, a thermometer for example, detecting changes in temperature.
Speaker 1: Then it has a means of sending the information off
Speaker 1: to somewhere else, and it's that somewhere else that ends
Speaker 1: up making meaning of the data that the sensors are
Speaker 1: actually gathering. So the end device is at least in
Speaker 1: a way in this particular instance, kind of stupid. It's
Speaker 1: just giving constant updates and a processing center is actually
Speaker 1: making use of that information. However, there are also some
Speaker 1: IoT devices that actually do have some compute capacity built
Speaker 1: into them. There are machines that have processing units kind
Speaker 1: of like CPUs on a computer, and they also have
Speaker 1: memory and the ability to do at least some data
Speaker 1: processing right at the point of data generation or data collection.
Speaker 1: So if you were to go out and purchase a
Speaker 1: brand new car, chances are that car would have somewhere
Speaker 1: in the neighborhood of fifty CPUs built into it in
Speaker 1: order to control various functions, all of these operating independently
Speaker 1: of each other. But it also means that with the
Speaker 1: elements of the network, these can become effectively edge devices.
Speaker 1: So you've got your edge servers and you've got your
Speaker 1: edge devices, which if they weren't connected to any other network,
Speaker 1: you would just call them computers. When we come back,
Speaker 1: we'll talk a bit more about edge computing and some
Speaker 1: of the pauses and some of the challenges associated with it,
Speaker 1: and what we might expect to see develop in the
Speaker 1: near future. But first let's take another quick break. One
Speaker 1: thing I haven't talked about so far in this episode
Speaker 1: is containers, not physical containers that you would find in
Speaker 1: the real world, but rather the concept of containers within
Speaker 1: the context of software development and deployment. Now, remember how
Speaker 1: I talked about how packet switching and how information travels
Speaker 1: across the Internet and how data packets play apart. Well,
Speaker 1: in a kind of similar way, containers are standard units
Speaker 1: of software. So we're not just talking about data, we're
Speaker 1: actually talking about applications here, and a container is a
Speaker 1: way to put together everything that a specific piece of
Speaker 1: software needs in order for it to operate. That includes
Speaker 1: the system tools that it needs, the code of the
Speaker 1: app itself, any libraries the code has to draw upon
Speaker 1: in the process of executing the program, and so on.
Speaker 1: So essentially you can think of contain inners as all
Speaker 1: the stuff this particular app needs in order to do
Speaker 1: whatever it is the app does. Now, the reason that
Speaker 1: containers are important is that they allowed developers to move
Speaker 1: software two different operating environments easily. Let's say that you
Speaker 1: are developing an app, and you might first develop it
Speaker 1: on your own machine, but then you actually need to
Speaker 1: test the app out. You've built it up to a
Speaker 1: point where you can run some tests, get some people
Speaker 1: in there to check it out, go through all the features,
Speaker 1: make sure it works. So you want to deploy it
Speaker 1: to a test environment, a discrete environment in which the
Speaker 1: app can behave as if it were released to the wild.
Speaker 1: But here's the important part. You haven't actually released it
Speaker 1: out to the wild, so that gives the opportunity to
Speaker 1: find any problems with it, vulnerabilities, anything that could be
Speaker 1: detrimental Once it was released. You can do all that
Speaker 1: in a safe space. So you do that, and you
Speaker 1: find out what works and what doesn't work. You go back,
Speaker 1: you make some changes, you deploy it again to the
Speaker 1: test environment, you test it again. Once it gets to
Speaker 1: the point that the app seems to be working the
Speaker 1: way you wanted, then maybe you move it to a
Speaker 1: staging environment, and from there it goes into production and
Speaker 1: it becomes an app that end users can actually download
Speaker 1: and install on their devices and actually use well. Containers
Speaker 1: make it easier to move this app from one environment
Speaker 1: to another, from laptop to test environment and back again,
Speaker 1: or test environment to staging environment, staging environment to production,
Speaker 1: et cetera. And these environments can all have different elements
Speaker 1: from one another, and those differences could mean that code
Speaker 1: that works really well in one environment suddenly doesn't work
Speaker 1: at all or is doing really weird stuff in a
Speaker 1: different environment. But containers contain all the elements of the
Speaker 1: app needs to run properly, so that at least in theory,
Speaker 1: the code should run the same way regardless of whatever
Speaker 1: environment it is in, because all the requirements for the
Speaker 1: app are contained along with the code of the app itself.
Speaker 1: Now I get that this is a little difficult to
Speaker 1: grock for some folks. I mean it's tough for me
Speaker 1: and I have covered it multiple times. But beyond containers,
Speaker 1: we have another term that frequently pops up when we
Speaker 1: talk about cloud computing and edge computing, and that term
Speaker 1: is the dreaded Kubernetes, which refers to in now open
Speaker 1: source platform for a container management. So in other words,
Speaker 1: this is kind of one step up from the containers themselves.
Speaker 1: This is a product that helps teams operationalized containers at scale.
Speaker 1: Because it's one thing to move a container from a
Speaker 1: you know, a developer laptop to a testing environment. It's
Speaker 1: another thing to deploy software that is going to potentially
Speaker 1: millions of users. So from a software perspective, we could
Speaker 1: say that Kubernetes and containers are trying to do from
Speaker 1: a code approach what ed computing is trying to do
Speaker 1: from a hardware approach, But in reality, all the stuff
Speaker 1: kind of gets mixed up together. Containers make it easier
Speaker 1: from an operational standpoint to deploy apps to the edge,
Speaker 1: whether that's to edge devices where you're more likely to
Speaker 1: use a simple container platform, or to edge servers where
Speaker 1: you might be relying on the more robust Kubernetes platform.
Speaker 1: So these are all pieces of a puzzle that makes
Speaker 1: edge computing a viable strategy. Now, there's some other considerations
Speaker 1: that I T professionals have to make when it comes
Speaker 1: to edge computing. Distributing computing to the edge comes with challenges.
Speaker 1: For example, when you've got your own on premises cloud
Speaker 1: computing data center, you have a lot of control when
Speaker 1: it comes to ensuring the safety of your equipment and
Speaker 1: the information that it holds. That spans physical safety. That
Speaker 1: means you can actually make sure that those facilities are
Speaker 1: protected that unauthorized people cannot easily get physical access to machine.
Speaker 1: Means that you've got a properly cooled facility to deal
Speaker 1: with all the heat that those computers are giving off.
Speaker 1: That kind of thing. It also means that you have
Speaker 1: more control over cyber security, so you can make sure
Speaker 1: that protections are in place to keep things running smoothly.
Speaker 1: But moving out to the edge creates more opportunities for
Speaker 1: bad actors to find a way to attack a system.
Speaker 1: So creating an edge computing network that is easy to
Speaker 1: administer and orchestrate while also being secure is a pretty
Speaker 1: big hurdle. It may mean leaning heavily on other entities
Speaker 1: and trusting that they've got their act together, and as
Speaker 1: we've seen pretty recently, sometimes that it turns out that
Speaker 1: a trusted entity has been compromised and then there can
Speaker 1: be fallout of specifically, thinking about the Solar winds hack. Now,
Speaker 1: in that case, we weren't talking about edge computing, but
Speaker 1: I'm using it to illustrate a point. The interconnectedness of
Speaker 1: these systems and the fact that you might talking about
Speaker 1: half a dozen companies that own parts of this network
Speaker 1: that are all involved in this edge computing enterprise means
Speaker 1: that you're asking a lot of organizations to trust one another,
Speaker 1: and if one of those organizations gets compromised, there's a
Speaker 1: danger that hackers could take advantage of those trusted relationships
Speaker 1: to gain access to the others. Now, related to the
Speaker 1: issue of security is privacy. When it comes to the
Speaker 1: Internet of Things, we're often talking about devices that are
Speaker 1: gathering data about us in our activities. Yes, we've also
Speaker 1: got devices that are sensing environments and not so much
Speaker 1: focused on people, but a lot of devices are either
Speaker 1: directly or indirectly keeping track of where people are, who
Speaker 1: they are, and what they're doing. Now that data can
Speaker 1: be useful for a lot of good things, but it
Speaker 1: can obviously also be misused or outright abused. So there
Speaker 1: is an onus on companies to make sure they are
Speaker 1: good stewards of data and that they protect that information.
Speaker 1: And since this information is potentially moving between lots of
Speaker 1: different points, from say the endpoint in the environment or
Speaker 1: on a user through the edge network and potentially further
Speaker 1: up the chain to a cloud computing network, there are
Speaker 1: a lot of opportunities for vulnerabilities. Now. While we often
Speaker 1: associate vulnerabilities with hackers who are trying to find ways
Speaker 1: to exploit systems, a vulnerability could just as easily be
Speaker 1: a poorly protected web portal that is publishing what should
Speaker 1: otherwise be private data. We've seen this happen with companies
Speaker 1: where somewhere someone along the chain failed to take into
Speaker 1: account what was actually going on, and data that should
Speaker 1: have remained protected in private was somehow published publicly or
Speaker 1: semi publicly. As we look at decentralized computer systems, we
Speaker 1: see a lot more points where this kind of thing
Speaker 1: could potentially happen, either with the raw data collected in
Speaker 1: the wild or then the processed data that comes out
Speaker 1: of the edge network. Either way, that's something else that
Speaker 1: I T professionals have to focus on. Reducing the number
Speaker 1: of times data needs to move from one part of
Speaker 1: the system to the other is potentially one solution toward
Speaker 1: providing better privacy and security. You're reducing the number of hops.
Speaker 1: You're reducing the number of vulnerabilities that could potentially exist.
Speaker 1: If all the computing can stay at the edge and
Speaker 1: nothing needs to you know, phone home to the centralized
Speaker 1: data center, there are fewer opportunities for something to go astray. Similarly,
Speaker 1: we will likely see lots of companies specialize in ways
Speaker 1: to manage the flow of data between devices on the
Speaker 1: edge of a network and big data centers. I think
Speaker 1: that's going to be a really big business. That it's
Speaker 1: like enterprise to enterprise business. But but what if you're
Speaker 1: not an I T professional? I mean, I'm not so
Speaker 1: what if you're like me, it's not your job to
Speaker 1: worry about this kind of stuff. What does all this
Speaker 1: actually mean to you? Well, essentially, it means the gradual
Speaker 1: introduction of more lightweight technologies that have increasingly usefulness in
Speaker 1: our lives. Well, maybe usefulness is going a bit far.
Speaker 1: We'll be able to do a lot more stuff with
Speaker 1: different devices, interacting with our environments and with ourselves. Not
Speaker 1: all of it might be useful. I mean I often
Speaker 1: talk about augmented reality applications like I did earlier in
Speaker 1: this episode, where you know, you use an app on
Speaker 1: a smartphone, or maybe you're lucky you've got a pair
Speaker 1: of a R goggles and you're able to visualize the
Speaker 1: world around you in different ways. You know, I love
Speaker 1: this idea of going to the site of an old
Speaker 1: castle and looking at the ruins and then seeing a
Speaker 1: virtual reconstruction of what the castle looked like when it
Speaker 1: was in its heyday. That to me is like the
Speaker 1: gold standard of a R applications, Which can you know
Speaker 1: tells you that I majored in Medieval English literature when
Speaker 1: I was in college. But I also admit that the
Speaker 1: reality of a R means I'll probably see a lot
Speaker 1: more let's call them frivolous uses of the technology, like
Speaker 1: walking through a grocery store and seeing characters in the
Speaker 1: front of cereal boxes seemingly come to life, inviting me
Speaker 1: to enjoy their sugary goodness. Or I might look at
Speaker 1: a movie poster and suddenly a trailer for that film
Speaker 1: begins to play inside my vision. A lot of the
Speaker 1: services that we use are monetized in various ways, and
Speaker 1: I mean, I'm not knocking it. That makes sense. No
Speaker 1: one wants to work for free. But that often means
Speaker 1: that all certain technologies might have incredible potential. We also
Speaker 1: have to wade through a lot of less lofty applications.
Speaker 1: But edge computing is going to make that sort of
Speaker 1: stuff possible. Without edge computing, we wouldn't have the responsiveness
Speaker 1: capable of generating those experiences in a timely fashion. Sin
Speaker 1: So with edge computing, we're also going to see a
Speaker 1: lot of one of my old favorite words, convergence, the
Speaker 1: convergence of multiple disciplines of technology creating new approaches towards
Speaker 1: various problems. You've got your communication channels supplied by technologies
Speaker 1: like a robust five G rollout. You've got your computer
Speaker 1: technologies at the edge of the network. Behind that, you've
Speaker 1: got machine learning, artificial intelligence, autonomous management taking over tasks,
Speaker 1: optimizing them, always striving towards constant improvement. It's a pretty
Speaker 1: cool way to look at the future. Even something as
Speaker 1: seemingly dull as supply chain management really could have big
Speaker 1: results to consumers down the road. Literally and figuratively, imagine
Speaker 1: that the price of some goods starts to come down
Speaker 1: because we've actually developed far more efficient approaches to producing
Speaker 1: and shipping that stuff, and thus it costs less to
Speaker 1: get it to market, and various companies are competing with
Speaker 1: one another, so they reduce the price to you. That's
Speaker 1: one benefit we could see through this kind of robust
Speaker 1: rollout of edge computing. However, we have to remember one
Speaker 1: this version of the future is not a guarantee. It's
Speaker 1: a possibility. It's also good to think about the larger
Speaker 1: effect that we see as a consequence of more computing systems,
Speaker 1: more IoT devices, more processing, because this ultimately means we
Speaker 1: have to consume more energy. We need more electricity to
Speaker 1: fuel all this stuff, which means we got to produce
Speaker 1: more electricity, which frequently means we also are going to
Speaker 1: have a big ecological impact as a result of all
Speaker 1: this progress, assuming that we're still relying heavily on fossil
Speaker 1: fuels for our generation of electricity. Nothing exists in a
Speaker 1: vacuum except for all that light and zipping around out
Speaker 1: in space. This is all interconnected. We have to train
Speaker 1: ourselves to think about big picture stuff, to tackle problems
Speaker 1: in a way that aren't exacerbating different but very important problems. Now,
Speaker 1: I never said I had all the answers. Heck, I
Speaker 1: only have a couple of answers. For example, the capital
Speaker 1: of Iceland is Reka, Vic doesn't really apply here, but
Speaker 1: that's my point. But yes, that's our overview of edge
Speaker 1: computing and the role it plays within networks and our
Speaker 1: experiences with technology. It is one of those things that
Speaker 1: continues to evolve. And like I said, this one's a
Speaker 1: pretty young one. Like I think the earliest mentions I
Speaker 1: could find were somewhere around t so not that old
Speaker 1: in terms of technologies that we have at our disposal.
Speaker 1: So I'll probably be doing multiple episodes about this further
Speaker 1: into the future as we see it evolve over time
Speaker 1: and different implementations take shape. I'm excited to see what
Speaker 1: will become a reality based on this technology. Uh, And
Speaker 1: of course I am concerned about the impacts that the
Speaker 1: technology will have beyond just its direct application. But I
Speaker 1: think we can leave off here and then we will
Speaker 1: come back with new episodes about other stuff. So if
Speaker 1: you have any suggestions about other stuff, I can cover
Speaker 1: preferably related to technology. I mean, if you want me
Speaker 1: to talk about ka Vic, I'll do it. It's just
Speaker 1: not I don't know how well it fits in with
Speaker 1: tech stuff, and my sponsors might get mad the heck
Speaker 1: um game. If you are, let me know what you
Speaker 1: would like me to talk about in future episodes. The
Speaker 1: best way to do that is to reach out on Twitter.
Speaker 1: The handle I use is tech stuff H s W
Speaker 1: and I'll talk to you again. Release it. Tex Stuff
Speaker 1: is an I Heart Radio production. For more POE casts
Speaker 1: from I Heart Radio, visit the I Heart Radio app,
Speaker 1: Apple Podcasts, or wherever you listen to your favorite shows.
Speaker 1: H