WEBVTT - The Zoom Boom 0:00:04.400 --> 0:00:07.760 Welcome to Text Time, a production from I Heart Radio. 0:00:12.560 --> 0:00:15.560 Hey there, and welcome to tech Stuff. I'm your host, 0:00:15.720 --> 0:00:19.280 Jonathan Strickland. I'm an executive producer with I Heart Radio 0:00:19.320 --> 0:00:23.439 and I love all things tech. And as we continue 0:00:23.520 --> 0:00:28.120 to try and maintain some sense of normalcy and regularity 0:00:28.160 --> 0:00:33.479 in our lives while simultaneously dealing with a pandemic, certain 0:00:33.520 --> 0:00:38.479 potential topics just seemed to beg to be addressed, including 0:00:38.640 --> 0:00:41.960 in the world of tech. Recently, I went on Twitter 0:00:42.159 --> 0:00:45.080 and I asked my followers if they had any suggestions 0:00:45.080 --> 0:00:49.000 for episode topics, and I got a whole bunch of different, 0:00:49.360 --> 0:00:52.720 you know, candidates, But the one that received the most 0:00:52.880 --> 0:00:58.560 independent submissions was the video conferencing service Zoom. For many, 0:00:58.840 --> 0:01:01.840 Zoom was something that just kind of popped up once 0:01:01.960 --> 0:01:04.679 millions of us had to shift to work from home. 0:01:05.200 --> 0:01:07.840 The company, as it turns out, has been around for 0:01:07.880 --> 0:01:10.319 a few years, but it was really when people were 0:01:10.360 --> 0:01:15.039 rushing to find conferencing solutions that it became mainstream news. 0:01:15.440 --> 0:01:18.080 A lot of you out there were probably using Zoom, 0:01:18.120 --> 0:01:22.520 possibly for years, because it was already a popular video 0:01:22.600 --> 0:01:25.280 conferencing tool, but it's just that a lot of folks 0:01:25.360 --> 0:01:28.920 never really had occasion to use it until current circumstances 0:01:29.319 --> 0:01:34.400 changed things. Add to that some pretty high profile controversies 0:01:34.440 --> 0:01:38.360 regarding everything from Internet security to privacy concerns, and you've 0:01:38.400 --> 0:01:42.080 got yourself a prime tech stuff topic. So today we're 0:01:42.080 --> 0:01:45.480 going to talk about the Zoom service, where it came from, 0:01:45.520 --> 0:01:48.640 how it made its founder a billionaire, and we'll look 0:01:48.640 --> 0:01:51.320 into some of those controversies. But let's start with what 0:01:51.480 --> 0:01:54.760 Zoom is. Just in case you don't know, the basic 0:01:54.800 --> 0:01:57.080 idea behind Zoom is pretty easy to get your mind 0:01:57.120 --> 0:02:00.880 wrapped around. It's a conferencing service that uses the Internet, 0:02:01.360 --> 0:02:04.840 so you can do audio conferences, video conferences, you can 0:02:04.880 --> 0:02:09.000 do web conferences, including sharing screens so that multiple people 0:02:09.000 --> 0:02:13.360 can view the same documents simultaneously. It works on mobile 0:02:13.360 --> 0:02:17.040 devices as well as desktop or laptop computers. It can 0:02:17.040 --> 0:02:19.799 support meetings with as few as two people or as 0:02:19.840 --> 0:02:23.040 many as five hundred. There are also options to have 0:02:23.160 --> 0:02:26.760 a single presenter streamed to an unlimited audience. This would 0:02:26.800 --> 0:02:30.919 be one way communication like a lecture. Obviously, a lot 0:02:30.960 --> 0:02:33.560 has to happen in the back end for all of 0:02:33.600 --> 0:02:37.400 this to work, and it requires a persistent Internet connection. 0:02:37.720 --> 0:02:39.959 But we'll get into all of that later. Right now, 0:02:40.040 --> 0:02:43.160 let's talk about the company's history, and the story of 0:02:43.240 --> 0:02:47.200 Zoom really starts with a different company, and that company 0:02:47.200 --> 0:02:51.360 would be Cisco, which is an enormous technology conglomerate that 0:02:51.440 --> 0:02:54.000 does a whole lot of stuff, and among that stuff 0:02:54.200 --> 0:02:58.440 is a web conferencing service called WebEx. Now WebEx didn't 0:02:58.520 --> 0:03:01.920 come out of Cisco. Cisco actually acquired the company in 0:03:01.919 --> 0:03:05.600 two thousand seven. WebEx itself was founded in the late 0:03:05.680 --> 0:03:09.400 nineteen nineties. Originally it was called Active Touch, but quickly 0:03:09.480 --> 0:03:15.400 became WebEx. One Cisco executive named Eric Yuan found the 0:03:15.440 --> 0:03:21.160 WebEx service needed several improvements. Yuan was born in China. 0:03:21.560 --> 0:03:25.560 He grew up attended school and later college in China. 0:03:25.960 --> 0:03:29.760 As a kid, Yuan's first attempt at making money involved 0:03:30.200 --> 0:03:34.040 taking copper out of leftover material from construction sites and 0:03:34.200 --> 0:03:36.760 selling it. And he found out that the company he 0:03:36.800 --> 0:03:39.520 was selling these scraps to really just wanted the copper 0:03:39.560 --> 0:03:43.320 that was it. So he decided, you know, to streamline things, 0:03:43.360 --> 0:03:46.240 he would go a step further and attempt to extract 0:03:46.360 --> 0:03:50.960 copper from everything else by burning it, you know, burning 0:03:51.120 --> 0:03:54.280 the everything else away and leaving the copper behind. As 0:03:54.320 --> 0:03:59.200 a result, he accidentally burned down his neighbor's shack, which 0:03:59.200 --> 0:04:03.720 he was using to secretly conduct his business, and he 0:04:03.800 --> 0:04:07.200 was doing this d I y copper reclamation project. As 0:04:07.240 --> 0:04:09.800 a kid burned down his neighbor's shack, and you could 0:04:09.840 --> 0:04:13.720 say this first business venture was a failure. But unlike 0:04:13.720 --> 0:04:18.719 the shack, Yuan did not suffer from burnout but um bum. 0:04:18.760 --> 0:04:21.920 As a young adult, he was in a long distance 0:04:22.000 --> 0:04:25.800 relationship with a girlfriend and she lived so far away 0:04:25.839 --> 0:04:28.080 that he would have to take the train to see her, 0:04:28.120 --> 0:04:30.720 and it would take a ten hour trip by train 0:04:30.800 --> 0:04:33.960 to get there. Yuan frequently wished there was some easier 0:04:34.000 --> 0:04:37.200 way for him to see his girlfriend, and later said 0:04:37.279 --> 0:04:40.679 it was this desire that fueled his motivation for creating 0:04:40.760 --> 0:04:44.200 Zoom in the first place. He studied computer science at 0:04:44.279 --> 0:04:48.479 university and then married that long distance girlfriend when he 0:04:48.520 --> 0:04:51.040 was twenty two years old, and he was pursuing a 0:04:51.080 --> 0:04:53.919 master's degree at the time, and he was thinking about 0:04:53.920 --> 0:04:55.800 what was going to come next once he got out 0:04:55.800 --> 0:04:58.360 of school, what he was going to pursue as a career. 0:04:59.160 --> 0:05:03.400 Yuan learned of the Internet and felt that this technology 0:05:03.440 --> 0:05:06.800 would be truly transformative, but he lived in China, and 0:05:06.800 --> 0:05:10.800 the Chinese government hadn't rolled out internet infrastructure, and it 0:05:10.839 --> 0:05:12.960 was pretty obvious that the government was going to keep 0:05:13.000 --> 0:05:16.280 a tight control on what could come into China once 0:05:16.320 --> 0:05:18.279 it was connected to the rest of the world. This 0:05:18.320 --> 0:05:22.240 would be the Great Chinese Firewall. Yuan decided that he 0:05:22.279 --> 0:05:24.800 wanted to immigrate to the United States so that he 0:05:24.839 --> 0:05:27.479 could work on projects connected to the Internet and be 0:05:27.680 --> 0:05:32.640 free of that particular obstacle. The first time he applied 0:05:32.680 --> 0:05:35.039 for a visa to work in the United States, he 0:05:35.120 --> 0:05:37.880 received a rejection. He didn't let that get to him, 0:05:37.880 --> 0:05:42.520 so he applied again, and he was rejected again. So 0:05:42.640 --> 0:05:46.719 he applied again and again. In fact, it wasn't until 0:05:46.800 --> 0:05:51.039 his ninth try that he was accepted. Upon arriving in 0:05:51.040 --> 0:05:54.440 the United States in nine seven, at the age of 0:05:54.480 --> 0:05:59.320 twenty seven, Yuan secured a job with Webbex, which itself 0:05:59.440 --> 0:06:01.360 was just a couple of years old. In fact, a 0:06:01.440 --> 0:06:03.960 little less than two years old. It only had a 0:06:04.000 --> 0:06:08.359 few employees, but it was growing fairly quickly, and unlike 0:06:08.480 --> 0:06:11.599 many web based companies, WebEx was able to get through 0:06:11.600 --> 0:06:14.120 the dot com bubble burst of two thousand and two 0:06:14.160 --> 0:06:19.120 thousand one, when the economy stabilized WebEx began to grow again, 0:06:19.680 --> 0:06:22.920 and it held its own I p O. Several years later, 0:06:23.440 --> 0:06:27.600 a decade after you Want joined WebEx, Cisco came a colon. 0:06:27.960 --> 0:06:31.919 The mega company acquired WebEx for the princely sum of 0:06:32.080 --> 0:06:36.839 three point two billion dollars. At the time, WebEx was 0:06:36.920 --> 0:06:40.520 reporting three hundred eighty million dollars in revenue with a 0:06:40.560 --> 0:06:44.200 fifty million dollar profits, so the company was doing well. 0:06:44.480 --> 0:06:46.640 It was no wonder that a big company like Cisco, 0:06:46.880 --> 0:06:49.960 which is all about providing internet and text services mostly 0:06:50.000 --> 0:06:54.000 to other big companies, would be interested. Even at the 0:06:54.080 --> 0:06:57.480 time people were criticizing WebEx as being a bit too 0:06:57.560 --> 0:07:02.240 bloated and costly. Michael Arrington of tech Crunch posted about 0:07:02.279 --> 0:07:06.400 the acquisition announcement and mentioned that several startups were aiming 0:07:06.600 --> 0:07:10.280 at the same general suite of services that WebEx provided, 0:07:10.680 --> 0:07:13.240 and that these startups were on the rise, indicating that 0:07:13.280 --> 0:07:17.240 perhaps WebEx was already loaded with feature creep, that it 0:07:17.280 --> 0:07:20.200 was getting too unwieldy for its own good, and it 0:07:20.280 --> 0:07:25.240 was creating its own opportunities for competition to jump up 0:07:25.280 --> 0:07:28.680 and and take some of the pie u wan transition 0:07:28.720 --> 0:07:31.640 to Cisco, he became the company's VP of Engineering in 0:07:31.760 --> 0:07:35.760 charge of collaboration software. And Uan stated in interviews that 0:07:35.840 --> 0:07:38.520 he met with several Cisco customers over the course of 0:07:38.560 --> 0:07:40.720 his tenure with the company, and he heard from many 0:07:40.720 --> 0:07:43.560 of them that they found WebEx to be clunky, hard 0:07:43.560 --> 0:07:46.960 to use, and expensive. He could tell that these weren't 0:07:47.000 --> 0:07:51.520 outlying opinions, but rather indicated some real areas of opportunity 0:07:51.680 --> 0:07:55.440 to improve the service. One thing he felt very strongly 0:07:55.480 --> 0:07:58.000 about was that the service was anchored in a more 0:07:58.040 --> 0:08:01.840 traditional approach, a client a kind of approach, and Yuan 0:08:02.000 --> 0:08:05.120 felt that a cloud based service would be more suitable. 0:08:05.280 --> 0:08:08.240 He argued that Cisco should let him rebuild the WebEx 0:08:08.280 --> 0:08:12.080 product as a cloud based product, reinvigorating it, and his 0:08:12.160 --> 0:08:15.200 efforts to do so were met with resistance within Cisco. 0:08:15.400 --> 0:08:17.720 So by two thousand and eleven he had had enough. 0:08:18.160 --> 0:08:20.920 Yuan resigned from Cisco so that he could go and 0:08:20.960 --> 0:08:24.640 found his own web conferencing company, and around thirty to 0:08:24.760 --> 0:08:28.040 forty engineers from Cisco, some of them in China, would 0:08:28.120 --> 0:08:32.040 follow him and join his new venture, which would become Zoom. 0:08:32.080 --> 0:08:35.280 Between the time he left Cisco and the time Zoom 0:08:35.320 --> 0:08:39.360 actually launched, two years would pass. So what was going 0:08:39.400 --> 0:08:43.080 on in those two years, well pretty much what you'd expect. 0:08:43.360 --> 0:08:46.600 Yuan was meeting with investors raising money to fund his 0:08:46.640 --> 0:08:49.400 new company. At the same time, his team of engineers 0:08:49.400 --> 0:08:52.000 were building out the service with certain goals in mind. 0:08:52.400 --> 0:08:55.960 Two of the big ones were really key to Zoom's survival, 0:08:56.120 --> 0:08:58.280 and those were making sure the service would work on 0:08:58.320 --> 0:09:02.640 pretty much any platform, including mobile devices, and making sure 0:09:02.760 --> 0:09:08.000 latency was as low as possible. Latency is lag or delay, 0:09:08.040 --> 0:09:12.040 and it's an incredibly frustrating thing to encounter with technology. 0:09:12.080 --> 0:09:15.560 In communication, it makes things even more challenging. You have 0:09:15.640 --> 0:09:18.080 to ask was that a pause or is the person 0:09:18.160 --> 0:09:20.800 done speaking? Is it time for me to speak up? 0:09:21.240 --> 0:09:23.680 If you're video conferencing with me, I'm likely to think 0:09:23.720 --> 0:09:25.560 you have nothing to say, so I'll just keep on 0:09:25.640 --> 0:09:29.160 going because I'm a total chatterbox. This comes as news 0:09:29.200 --> 0:09:33.320 to nobody. I know that. But we humans are really 0:09:33.400 --> 0:09:37.360 good at picking up on latency, even unconsciously, and this 0:09:37.400 --> 0:09:41.000 makes developing certain technologies a real challenge, such as really 0:09:41.000 --> 0:09:44.760 good virtual reality. If you have noticeable latency with VR, 0:09:45.200 --> 0:09:48.320 it creates a sort of swimmy experience and it tends 0:09:48.440 --> 0:09:51.600 to lead to motion sickness, and while you might feel 0:09:51.679 --> 0:09:56.040 nauseated on some video calls. That's not really due to latency. 0:09:56.160 --> 0:09:58.720 Most times it's usually just due to the content of 0:09:58.760 --> 0:10:02.199 the call, But it's still difficult to have a natural 0:10:02.200 --> 0:10:06.840 conversation if there's latency involved. Over on the website protocol, 0:10:07.280 --> 0:10:11.160 David Pierce wrote that when he asked about latency and communication, 0:10:11.559 --> 0:10:14.640 he found that a lag of just one hundred fifty 0:10:14.720 --> 0:10:19.400 milliseconds or point one five seconds, is long enough for 0:10:19.480 --> 0:10:21.960 us to pick up on it. So the service needed 0:10:21.960 --> 0:10:24.880 to deliver video and audio at a lower latency than 0:10:25.000 --> 0:10:29.640 point one five seconds. Combining these two goals created a 0:10:29.720 --> 0:10:32.880 real engineering challenge. The team needed to come up with 0:10:32.920 --> 0:10:36.280 solutions that would work on multiple devices and not contribute 0:10:36.280 --> 0:10:40.280 to latency. Some services that cater to multiple platforms take 0:10:40.320 --> 0:10:44.520 a pretty straightforward route. The service will cater to whichever 0:10:44.640 --> 0:10:48.199 device or connection is the slowest. So this you could 0:10:48.240 --> 0:10:52.360 call the weakest link strategy. You deliver the experience at 0:10:52.400 --> 0:10:56.559 the fastest speed that the slowest connection can handle, and 0:10:56.679 --> 0:10:59.960 everybody has to deal with that. But that means everyone 0:11:00.000 --> 0:11:02.520 and gets a pretty lousy experience, or at least not 0:11:02.640 --> 0:11:05.640 as good as what it could be. The team instead 0:11:05.679 --> 0:11:08.800 wanted to create an approach in which their service would 0:11:08.800 --> 0:11:11.959 be adaptable. It would be able to deliver an optimized 0:11:12.040 --> 0:11:15.760 experience for each and every participant in a session. This 0:11:15.800 --> 0:11:18.600 would require a flexible approach in which the service could 0:11:18.640 --> 0:11:22.560 do things like downscale video quality or audio quality in 0:11:22.640 --> 0:11:25.600 order to stay synchronized with people on more capable devices 0:11:25.640 --> 0:11:28.880 and faster connections. It required a lot more programming on 0:11:28.920 --> 0:11:31.120 the back end for the service to identify what people 0:11:31.120 --> 0:11:34.600 were using and how to best serve them. By the 0:11:34.720 --> 0:11:37.640 end of two thousand twelve, Yuan's group had a beta 0:11:37.760 --> 0:11:40.480 version of the Zoom service and it could host around 0:11:40.480 --> 0:11:42.600 a dozen or so people at once. It was only 0:11:42.640 --> 0:11:45.080 a hint of what the service would become, but it 0:11:45.120 --> 0:11:48.079 was a handy tool when meeting with potential investors. So 0:11:48.200 --> 0:11:51.320 for two years, Un and his team build out Zoom 0:11:51.360 --> 0:11:54.600 and secure funding with rounds of investment. It must have 0:11:54.600 --> 0:11:57.360 been pretty challenging, since, as I mentioned earlier, there was 0:11:57.400 --> 0:12:00.440 already a host of video conferencing services using the internet 0:12:00.480 --> 0:12:03.720 back in those days, but he managed it. Yuan boared 0:12:03.760 --> 0:12:05.760 a lot of his own money into the venture himself. 0:12:06.200 --> 0:12:11.360 CBS Insights reports that Yuan held an estimated eighteen point 0:12:11.520 --> 0:12:14.800 five percent steak in the company, so nearly twenty percent steak, 0:12:15.400 --> 0:12:18.360 and that was when it would go public just in 0:12:18.440 --> 0:12:22.000 two thousand nineteen, so the company wouldn't hold its Series 0:12:22.040 --> 0:12:25.160 A round of funding until two thousand thirteen when it 0:12:25.200 --> 0:12:28.400 would first launch. As part of this fundraising approach, Uan 0:12:28.520 --> 0:12:31.720 had investors used the Zoom product and he would hold 0:12:31.760 --> 0:12:34.920 meetings in Zoom. He reportedly would only show up in 0:12:34.960 --> 0:12:38.000 person for the first time to make sure investors had 0:12:38.080 --> 0:12:40.240 access to the service and had signed up for it, 0:12:40.600 --> 0:12:43.240 and then he held all other meetings on the service itself. 0:12:43.640 --> 0:12:46.120 It's reported that over the course of five years he 0:12:46.200 --> 0:12:51.040 had fewer than ten work related trips, so averaging out 0:12:51.080 --> 0:12:55.520 to two work trips per year. Man I envy that schedule, 0:12:56.240 --> 0:12:59.240 But he was using this product that his company was 0:12:59.280 --> 0:13:02.480 providing to hold virtual meetings instead. He was practicing what 0:13:02.600 --> 0:13:04.800 he was preaching, and it was an effective way to 0:13:04.800 --> 0:13:08.920 get buy in from investors and later on customers. In fact, 0:13:08.960 --> 0:13:13.000 there's a story that he would personally contact customers who 0:13:13.000 --> 0:13:16.679 were canceling subscription services and he would reach out to 0:13:16.720 --> 0:13:20.160 them himself. People thought there was an automated service, but no, 0:13:20.800 --> 0:13:23.880 it was actually Yuan himself. The founder of the company 0:13:24.000 --> 0:13:27.120 writing to them to say, hey, would you reconsider, which 0:13:27.160 --> 0:13:30.040 is kind of a crazy level of dedication. He could 0:13:30.080 --> 0:13:31.920 only keep that up for so long, because, as it 0:13:31.960 --> 0:13:34.319 turns out, it would get pretty popular. See the product 0:13:34.440 --> 0:13:37.080 launched in two thousand thirteen and by the end of 0:13:37.080 --> 0:13:40.839 the first month had nearly half a million users, so 0:13:41.160 --> 0:13:44.480 keeping up with that many as a little tricky. By 0:13:44.760 --> 0:13:48.040 half a year, it was hitting a million users, and 0:13:48.080 --> 0:13:52.320 growth just exploded from there. Was Zoom making strategic partnerships 0:13:52.360 --> 0:13:55.120 both to enhance the services features and to become the 0:13:55.160 --> 0:13:59.119 preferred video conferencing an online meeting solution for several companies. 0:13:59.600 --> 0:14:02.679 Skipping ahead to two thousand nine team that's when Zoom 0:14:02.679 --> 0:14:06.000 would hold its initial public offering and it became a 0:14:06.080 --> 0:14:10.040 publicly traded company. At the market's open, the price per 0:14:10.080 --> 0:14:13.520 share of stock was thirty six dollars. By the end 0:14:13.520 --> 0:14:16.600 of the day, the price had climbed to a whopping 0:14:16.800 --> 0:14:20.960 sixty two dollars per share, And with Yuan's steak in 0:14:21.000 --> 0:14:23.960 the company, that would mean that his personal wealth would 0:14:24.000 --> 0:14:27.360 be pushed somewhere between two point nine and three point 0:14:27.400 --> 0:14:32.520 to billion dollars billion with a B. So yeah, that 0:14:32.600 --> 0:14:36.040 I p o made him a billionaire. Now when we 0:14:36.120 --> 0:14:39.560 come back, I'll talk a little bit more about what 0:14:39.760 --> 0:14:43.320 actually makes Zoom tick in the background, and then we'll 0:14:43.360 --> 0:14:54.640 conclude with some stories about some trouble waters for Zoom. 0:14:54.640 --> 0:14:57.800 So let's talk a little about the tech that makes 0:14:57.840 --> 0:15:01.400 a service like Zoom possible. At the heart of this 0:15:01.680 --> 0:15:05.120 is the cloud infrastructure. And I've been doing this long 0:15:05.240 --> 0:15:07.920 enough to remember a time when cloud computing was a 0:15:08.040 --> 0:15:10.720 term that was just starting to make its way into 0:15:10.720 --> 0:15:14.760 the mainstream. And typically you get pretty high level explanations 0:15:14.800 --> 0:15:18.440 for what cloud computing is, and they can range from 0:15:18.520 --> 0:15:23.280 their services that exist online, which that's not terribly helpful, 0:15:23.720 --> 0:15:26.960 or the stuff you are accessing, whether it's storage or 0:15:26.960 --> 0:15:31.120 a program or whatever, lives on someone else's computer, which 0:15:31.160 --> 0:15:35.200 is more accurate but not very satisfying. So let's talk 0:15:35.240 --> 0:15:38.600 about cloud computing, and we'll start with that second definition 0:15:38.600 --> 0:15:41.200 we're gonna build on that. Cloud computing refers to a 0:15:41.240 --> 0:15:45.560 system in which a computer, or really a network of computers, 0:15:45.600 --> 0:15:49.120 sometimes a network of computers that can dynamically add more 0:15:49.160 --> 0:15:53.040 machines to support a service in times need. This network 0:15:53.120 --> 0:15:57.320 hosts something that remote users can access. Uh in the 0:15:57.360 --> 0:16:00.040 case of cloud storage. You're talking about a computer a 0:16:00.120 --> 0:16:02.640 network that serves as a kind of you know, file 0:16:02.720 --> 0:16:07.480 repository for users. People can access it through some online portal. 0:16:07.960 --> 0:16:12.640 Cloud computing usually refers to systems in which applications themselves 0:16:12.640 --> 0:16:15.840 are running on a network of machines, and end users 0:16:15.960 --> 0:16:20.240 access those applications through some sort of client interface or portal. 0:16:20.800 --> 0:16:24.400 And it might be a dedicated app that exists on 0:16:24.560 --> 0:16:27.960 top of a desktop computer or a smartphone or something, 0:16:28.320 --> 0:16:31.400 or it might just be a web client that exists 0:16:31.480 --> 0:16:34.600 in a special web page or whatever. The programs are 0:16:34.720 --> 0:16:39.000 running on this computer network, and usually it's designed for 0:16:39.040 --> 0:16:41.440 that purpose, and therefore it does a really good job, 0:16:41.560 --> 0:16:44.360 like a better job at running that application than a 0:16:44.480 --> 0:16:48.560 more general purpose computing machine would be able to do, 0:16:48.600 --> 0:16:51.240 you know, like a personal computer. The real beauty of 0:16:51.280 --> 0:16:54.840 cloud computing is that it shifts the burden of the 0:16:54.880 --> 0:16:58.680 work off the end users machine, whether that's a laptop, 0:16:58.760 --> 0:17:02.240 a desktop, a table computer, or a smartphone, and it 0:17:02.320 --> 0:17:06.040 moves it to these dedicated computer systems or servers. Users 0:17:06.080 --> 0:17:08.720 don't have to upgrade their devices or by the latest 0:17:08.760 --> 0:17:12.159 and greatest computers in order to use these services, because 0:17:12.200 --> 0:17:15.600 the hard work is really happening elsewhere. We say that 0:17:15.680 --> 0:17:17.840 the hard work is happening in the cloud, but really 0:17:17.880 --> 0:17:19.760 what we mean is that the work is going on 0:17:19.840 --> 0:17:23.480 in some data centers filled with servers, and a person 0:17:23.560 --> 0:17:25.600 with a state of the art system and a person 0:17:25.720 --> 0:17:29.600 using a smartphone could have a fairly comparable experience with 0:17:29.720 --> 0:17:33.920 the same cloud based service, assuming that both users also 0:17:34.000 --> 0:17:38.680 have a decent Internet connection, and the Internet connection can 0:17:38.760 --> 0:17:41.919 become the new bottleneck with this model of computing. So 0:17:41.960 --> 0:17:44.879 a couple of decades ago, the limiting factor was the 0:17:45.000 --> 0:17:48.119 end users hardware, like was the machine that the end 0:17:48.200 --> 0:17:52.440 user had good enough to run the program. Well, that 0:17:52.520 --> 0:17:55.720 was where the concern was. These days now we tend 0:17:55.760 --> 0:17:58.920 to worry about the end users internet connection. Folks who 0:17:58.960 --> 0:18:01.960 have fiber connect ativity and high speeds tend to have 0:18:02.000 --> 0:18:05.560 a better experience than those who have tighter bandwidth restrictions. 0:18:06.160 --> 0:18:09.200 In addition to being cloud based, Zoom can create and 0:18:09.280 --> 0:18:13.600 leverage peer to peer networks. This particular network strategy got 0:18:13.600 --> 0:18:16.840 a really bad rap abound a decade ago or so 0:18:17.280 --> 0:18:20.159 when some people were using peer to peer networks to 0:18:20.280 --> 0:18:24.000 pass around pirated copies of stuff like music and TV 0:18:24.080 --> 0:18:26.320 shows and movies and pretty much anything else that could 0:18:26.320 --> 0:18:30.000 be copied digitally, But the actual concept of a peer 0:18:30.040 --> 0:18:33.560 to peer network is agnostic towards anything that is shared 0:18:33.640 --> 0:18:37.199 on top of that network. P two P structures are 0:18:37.240 --> 0:18:41.680 a legitimate way to distribute files or services to multiple users. 0:18:41.720 --> 0:18:45.640 So what is it? Well, basically, it's a decentralized network 0:18:45.920 --> 0:18:48.800 in which all the machines, which can be called peers 0:18:49.040 --> 0:18:53.200 or nodes join the network play a pivotal role within 0:18:53.280 --> 0:18:56.439 that network. This is in contrast with the traditional client 0:18:56.640 --> 0:19:00.720 server model and which numerous clients all connect to one 0:19:00.960 --> 0:19:06.679 centralized server. These peers or nodes have special software running 0:19:06.680 --> 0:19:08.680 on them that allow them to connect to other nodes 0:19:08.720 --> 0:19:12.679 on that network, and they also share some portion of 0:19:12.760 --> 0:19:16.040 their own capabilities with the other nodes on the network. 0:19:16.400 --> 0:19:19.280 That might be storage, so you might have computers on 0:19:19.320 --> 0:19:22.480 the network storing files on behalf of other computers on 0:19:22.520 --> 0:19:26.400 the network, or it might be processing power or bandwidth, 0:19:26.480 --> 0:19:29.280 that kind of thing. So why does Zoom make use 0:19:29.359 --> 0:19:33.440 of P twop networks? In some cases, the local P 0:19:33.600 --> 0:19:37.320 two P structure might work just as well to facilitate 0:19:37.359 --> 0:19:41.639 an online meeting as a Zoom server proxy. So in 0:19:41.680 --> 0:19:44.440 those cases, the computers that connect to the meeting make 0:19:44.520 --> 0:19:48.200 up this network and they share some resources, and Zooms 0:19:48.240 --> 0:19:51.440 cloud servers don't really have to do very much outside 0:19:51.440 --> 0:19:54.520 of initiating the meeting, keeping track of who is in there, 0:19:54.960 --> 0:19:59.919 and some other load demand basic tasks and the mainstream 0:20:00.240 --> 0:20:05.320 tasks are offloaded onto the Zoom users computers. But in 0:20:05.359 --> 0:20:10.000 other cases, the Zoom server figures out that p TP 0:20:10.240 --> 0:20:13.600 network really isn't a viable option, and so it will 0:20:13.640 --> 0:20:17.480 shift all those online meeting functions to a more conventional 0:20:17.560 --> 0:20:21.920 cloud server based approach. To determine which way it's gonna go, 0:20:22.560 --> 0:20:25.200 Zoom goes through a very technical process, but I can 0:20:25.240 --> 0:20:27.800 simplify it a little bit, and it does become important 0:20:27.840 --> 0:20:31.080 later on the host of the meeting launches the app 0:20:31.200 --> 0:20:34.080 and starts the meeting within it or within the web 0:20:34.119 --> 0:20:36.520 client or whatever. But the host chooses to start a 0:20:36.560 --> 0:20:40.159 meeting that sends a message to Zooms servers over t 0:20:40.359 --> 0:20:44.159 c P or Transmission Control Protocol. This is one of 0:20:44.160 --> 0:20:48.520 the basic Internet standard communication protocols, and a protocol is 0:20:48.600 --> 0:20:52.160 essentially a set of rules or instructions. The Zoom server 0:20:52.440 --> 0:20:57.239 notifies the invitees to the meeting also through TCP, and 0:20:57.320 --> 0:21:00.400 that manifests itself to users as a message that's says, hey, 0:21:00.400 --> 0:21:02.520 your meeting is starting, you need to join it, and 0:21:02.640 --> 0:21:05.639 it allows those users to join the meeting. The server 0:21:05.800 --> 0:21:08.280 then does a P two P check among the host 0:21:08.480 --> 0:21:12.920 and all the invitees of this meeting, and it evaluates 0:21:12.920 --> 0:21:17.080 the peered connections between these different computers. If that evaluation 0:21:17.240 --> 0:21:21.240 passes a threshold of acceptable performance, then the server says, 0:21:21.240 --> 0:21:23.080 all right, you guys are good to go. I'm going 0:21:23.119 --> 0:21:26.040 to hand over the streaming duties to this peer to 0:21:26.080 --> 0:21:28.760 peer network and I'll just keep an eye on what's 0:21:28.800 --> 0:21:31.640 going on. But if it doesn't meet that threshold, then 0:21:31.680 --> 0:21:33.720 the Zoom server steps in and says, all right, we're 0:21:33.720 --> 0:21:37.640 gonna have a Zoom proxy server step in and handle 0:21:37.720 --> 0:21:40.720 all those duties because the peer to peer network wouldn't 0:21:40.720 --> 0:21:43.560 be able to do it otherwise. And the streaming is 0:21:43.560 --> 0:21:48.199 sent over a different protocol, not TCP. Instead, it's a 0:21:48.200 --> 0:21:51.600 protocol called User Data Gram Protocol or u d P. 0:21:53.400 --> 0:21:57.480 And now we need to talk about packets because this 0:21:57.600 --> 0:22:00.960 is also important. So the NATE sure the Internet means 0:22:01.000 --> 0:22:03.560 the machines are popping on and off the Internet all 0:22:03.600 --> 0:22:05.640 the time, right, So if you think about the Internet 0:22:05.680 --> 0:22:10.520 as being this interconnected web of UH servers that allow 0:22:10.680 --> 0:22:14.080 information to pass from point A to point B. Some 0:22:14.160 --> 0:22:16.679 of those servers are coming online, some of them servers 0:22:16.680 --> 0:22:20.240 are going offline, which means you cannot predict which pathway 0:22:20.440 --> 0:22:25.720 is going to be reliable, right, So that makes communication 0:22:25.920 --> 0:22:30.280 really tricky. It means that sometimes a pathway that existed 0:22:30.320 --> 0:22:33.119 at the beginning of a transfer may go offline in 0:22:33.160 --> 0:22:36.600 the middle of a transfer, So you need a backup 0:22:36.640 --> 0:22:39.639 plan if something goes wrong, and the protocols and packets 0:22:39.720 --> 0:22:42.760 are meant to deal with this. They are the style 0:22:42.800 --> 0:22:47.520 of backup plan. So packets are bundles of data. Rather 0:22:47.600 --> 0:22:52.800 than sending a file through the Internet entirely whole, computers 0:22:52.800 --> 0:22:57.000 will divide files up into more manageable packets or bundles. 0:22:57.680 --> 0:23:00.720 And this is easy to under stand if you think 0:23:00.760 --> 0:23:02.439 about what could happen if you were to try and 0:23:02.480 --> 0:23:04.720 send a file and it's a huge file. Let's say 0:23:04.720 --> 0:23:08.840 it's like a two hour high resolution video file. Well, 0:23:08.880 --> 0:23:11.560 you're trying to send this from one machine to another. 0:23:12.080 --> 0:23:16.879 Now imagine that some server along that pathway goes offline 0:23:16.920 --> 0:23:19.840 in the middle of that transfer. Maybe you're halfway through 0:23:19.960 --> 0:23:23.960 sending this file. And that server goes offline, you'd be 0:23:24.000 --> 0:23:27.080 back at square one, because now you have a useless file. 0:23:27.160 --> 0:23:30.200 You only got half of it to its destination. And 0:23:30.320 --> 0:23:33.600 it's even possible you wouldn't even know that something wrong 0:23:33.720 --> 0:23:37.160 had happened and that the file didn't go through, and 0:23:37.240 --> 0:23:39.080 that would be even worse than being at square one. 0:23:39.520 --> 0:23:42.800 So instead, what computers do is they divide those big 0:23:42.840 --> 0:23:46.720 files into packets, and those packets have information in them 0:23:46.760 --> 0:23:49.600 about what file they belong to, where they're supposed to go, 0:23:49.720 --> 0:23:51.600 how they fit in with all the other packets, kind 0:23:51.600 --> 0:23:54.520 of like a puzzle, and they all go across the Internet, 0:23:54.960 --> 0:23:58.000