WEBVTT - Cloud Computing Overview: Part Two 0:00:04.160 --> 0:00:07.160 Get in touch with technology with tech Stuff from how 0:00:07.240 --> 0:00:14.640 stuff Works dot com. Hey there, this is Jonathan Strickland 0:00:14.640 --> 0:00:17.080 and you are listening to tech Stuff. I am an 0:00:17.079 --> 0:00:19.680 executive producer with How Stuff Works and I love all 0:00:19.720 --> 0:00:23.959 things tech, and today we're going to rejoin the overview 0:00:24.160 --> 0:00:28.440 of cloud computing. What exactly is cloud computing and how 0:00:28.480 --> 0:00:31.080 does it work. We talked a little bit about the 0:00:31.120 --> 0:00:33.559 history of cloud computing in the last episode and kind 0:00:33.560 --> 0:00:36.000 of give some definitions of it. So if you haven't 0:00:36.040 --> 0:00:37.960 listened to that, go check that out. It is a 0:00:38.000 --> 0:00:40.519 bonus episode. This is also a bonus episode. I am 0:00:40.520 --> 0:00:44.080 in Las Vegas, Nevada. Since that's the correct way it's pronounced, 0:00:44.120 --> 0:00:49.440 I've learned, and I am covering Sweet World eighteen. It's 0:00:49.479 --> 0:00:52.920 a big cloud computing conference held by net Sweet and 0:00:53.000 --> 0:00:54.960 so as part of that, I thought I would do 0:00:55.000 --> 0:00:57.800 a couple of episodes about cloud computing, and in this one, 0:00:57.840 --> 0:01:00.920 we're going to look a little bit more into what 0:01:01.000 --> 0:01:04.480 cloud computing can do these days. Turns out it is 0:01:04.520 --> 0:01:09.280 a big, big business, a multibillion dollar business these days, 0:01:09.760 --> 0:01:12.200 and I'll talk a little bit more about that and 0:01:12.440 --> 0:01:17.080 uh enjoy So the ability to connect computers together also 0:01:17.120 --> 0:01:21.920 gave rise to computing models similar to cloud computing. For example, 0:01:22.000 --> 0:01:25.479 there's cluster computing. That's where you couple lots of different 0:01:25.520 --> 0:01:29.280 machines together to work as a unified system. Typically, I 0:01:29.280 --> 0:01:32.000 mean the coupling can be loose or tight. It doesn't 0:01:32.160 --> 0:01:37.120 really it doesn't necessitate tightly coupling machines together, but frequently 0:01:37.160 --> 0:01:39.520 that is the way it's done. And often these machines 0:01:39.520 --> 0:01:42.119 are all in the same location, so they may all 0:01:42.160 --> 0:01:44.679 be in the same data center. Clusters just tend to 0:01:44.720 --> 0:01:50.160 be more tightly connected than other computer models. So there's 0:01:50.200 --> 0:01:54.480 also grid computing. Grid computing is less tightly coupled than 0:01:54.480 --> 0:01:57.760 cluster computing. You may have computers that are part of 0:01:57.760 --> 0:02:01.040 this grid in remote locations there and nowhere close to 0:02:01.080 --> 0:02:05.800 each other, and they're all working together to solve various problems. 0:02:05.840 --> 0:02:09.000 But typically they're working kind of the way a multi 0:02:09.000 --> 0:02:12.360 core processor works. And by that I mean that the 0:02:12.639 --> 0:02:16.359 various computers in the grid are working on different parts 0:02:16.880 --> 0:02:19.840 of a problem. You could have the problem divide it 0:02:19.919 --> 0:02:23.760 up into various segments, and the various grid computers are 0:02:23.800 --> 0:02:26.160 working on each of them are working on a segment 0:02:26.240 --> 0:02:29.600 of that problem. This you can see examples of this, 0:02:29.680 --> 0:02:33.240 and things like the various at home projects like folding 0:02:33.280 --> 0:02:37.799 at Home or set at Home that use user computers 0:02:38.360 --> 0:02:42.360 as uh as units in a grid computing system to 0:02:42.560 --> 0:02:48.160 solve very difficult problems that would normally take a supercomputer 0:02:48.919 --> 0:02:51.240 ages to complete if it were working on it just 0:02:51.320 --> 0:02:55.760 by itself. So both cluster computers and grid computers, both 0:02:55.760 --> 0:03:00.520 of those models are sort of like virtual supercomputers because 0:03:00.600 --> 0:03:06.079 they are grouping the assets of various regular powered machines 0:03:06.120 --> 0:03:09.160 together to make it more than what it was, so 0:03:09.240 --> 0:03:12.200 you can create kind of a virtual supercomputer now. In 0:03:13.480 --> 0:03:18.480 Professor Ramna Chilapa at Emory University here in Atlanta described 0:03:18.520 --> 0:03:21.560 cloud computing as a method that would be defined not 0:03:21.760 --> 0:03:25.920 by technological limits, but rather by economic factors. So, in 0:03:25.960 --> 0:03:29.720 other words, the professor was saying that the costs associated 0:03:29.760 --> 0:03:33.920 with scaling processes would make it imperative for businesses to 0:03:34.000 --> 0:03:37.839 offload that burden by making use of cloud computing providers, 0:03:37.840 --> 0:03:41.160 and that this would in turn create the opportunity for 0:03:41.200 --> 0:03:44.560 such providers to kind of coalesce and become the partner 0:03:44.640 --> 0:03:47.240 these companies needed to grow and do work. In other words, 0:03:47.480 --> 0:03:51.400 he was saying the economic environment out there is such 0:03:52.160 --> 0:03:56.080 that there is a need for services that can provide 0:03:56.120 --> 0:04:00.360 these sort of cloud computing processes and storage. Uh So, 0:04:00.760 --> 0:04:03.840 because there's a need, sooner or later, they're going to 0:04:03.880 --> 0:04:07.040 be businesses filling that need. It's it's like nature of 0:04:07.120 --> 0:04:10.760 whorring a vacuum kind of concept. So cloud computing isn't 0:04:10.800 --> 0:04:14.280 just about technology but also the bottom line, and that 0:04:14.320 --> 0:04:17.479 should not come as a surprise since many factors that 0:04:17.520 --> 0:04:21.159 we frequently associate with technological advances are actually tied closely 0:04:21.200 --> 0:04:25.799 to economic factors. For example, Moore's law, which we frequently 0:04:25.880 --> 0:04:30.320 simplify by saying processing power doubles every two years or so, 0:04:31.080 --> 0:04:34.640 was originally an observation about how economic factors would drive 0:04:34.720 --> 0:04:37.479 the necessity to develop a means to double the number 0:04:37.480 --> 0:04:40.800 of transistors on a square inch of silicon substrate. In 0:04:40.839 --> 0:04:45.640 other words, money makes the world go round. In Evan 0:04:45.680 --> 0:04:49.680 Goldberg founded a company called net Ledger. The company was 0:04:49.720 --> 0:04:52.400 offering up software as a service, which means it's a 0:04:52.440 --> 0:04:55.120 good time to tackle a few common buzzwords associated with 0:04:55.120 --> 0:04:57.480 cloud computing. I'll get back to Mr Goldberg in just 0:04:57.560 --> 0:05:00.320 a minute. Now. For one thing, you'll find a lot 0:05:00.360 --> 0:05:04.160 of as a service buzz terms associated with cloud computing. 0:05:04.360 --> 0:05:07.280 Software as a service is a big one that is 0:05:07.320 --> 0:05:10.440 also known as S A A S, with both s 0:05:10.480 --> 0:05:13.040 as capitalized in the lower A the as in lower 0:05:13.040 --> 0:05:17.120 case UM. And this model, you don't sell software packages 0:05:17.200 --> 0:05:20.840 to a customer. Instead, you set up essentially a subscription 0:05:20.920 --> 0:05:24.839 service so that the customer can access the software. You 0:05:24.960 --> 0:05:28.160 maintain ownership of the software itself. You as the provider. 0:05:28.360 --> 0:05:31.360 You own the software. You're not selling instances of it 0:05:31.440 --> 0:05:35.239 to people. You provide access to the software in return 0:05:35.920 --> 0:05:39.640 for money. Then there's platform as a service that's P 0:05:40.080 --> 0:05:42.080 A A S. Again the P and the S or 0:05:42.200 --> 0:05:44.360 upper case the a's or lower case. That's the case 0:05:44.400 --> 0:05:49.200 for all of these as a service buzzwords. With platform 0:05:49.240 --> 0:05:52.919 as a service, you create a virtual platform for the 0:05:52.920 --> 0:05:58.240 customer for the purposes of developing programs or apps. So 0:05:58.360 --> 0:06:01.280 developers use the virtual platform them when creating whatever app 0:06:01.320 --> 0:06:03.440 they're working on at the time, and it can serve 0:06:03.440 --> 0:06:06.520 as a place where developers share tools and processes to 0:06:06.560 --> 0:06:09.760 help speed up development. There's a variant of this called 0:06:09.880 --> 0:06:13.800 mobile back end as a service that, as the name suggests, 0:06:13.839 --> 0:06:16.839 performs the task of being the back end operations of 0:06:16.839 --> 0:06:21.240 a mobile application. But this is all about creating the 0:06:21.279 --> 0:06:26.440 tools the developer needs in order to create and test 0:06:26.640 --> 0:06:30.640 and then deploy the software they are making. Next, you've 0:06:30.680 --> 0:06:35.240 got the infrastructure as a service or i a a S. 0:06:35.720 --> 0:06:39.160 This is even more robust than the platform as a service, 0:06:39.200 --> 0:06:42.400 and it's really meant for businesses for enterprises. So let's 0:06:42.440 --> 0:06:46.560 imagine that you start your own business and you're making toys, 0:06:46.960 --> 0:06:49.160 and you start out small, maybe you're even working out 0:06:49.160 --> 0:06:50.920 of your own home, and you're doing all of this 0:06:50.960 --> 0:06:55.320 by hand. But your business grows, your demand increases, and 0:06:55.520 --> 0:06:59.279 you are physically incapable of meaning that demand all by yourself. 0:06:59.320 --> 0:07:02.360 So you need to scale up operations. And this kind 0:07:02.360 --> 0:07:06.240 of starts slowly. You know, at first it's not too hectic. 0:07:06.360 --> 0:07:10.200 You can hire on some people and take on that responsibility. 0:07:10.240 --> 0:07:13.160 But if demand continues to increase, you have to take 0:07:13.200 --> 0:07:15.680 the next step. You have to start forming relationships with 0:07:15.720 --> 0:07:18.880 factories to make your toys. And this is both to 0:07:19.000 --> 0:07:21.800 increase the supply as well as to reduce the cost. 0:07:21.880 --> 0:07:24.720 By producing them in bulk, you can reduce the cost 0:07:24.800 --> 0:07:28.800 on a per unit basis to produce and also still 0:07:28.840 --> 0:07:31.680 meet the demand that your customers have. You have to 0:07:31.760 --> 0:07:34.080 manage supply chains. Though you have to make sure all 0:07:34.080 --> 0:07:37.080 the components you need to make your toys are getting 0:07:37.120 --> 0:07:39.480 to the factories. You have to figure out how to 0:07:39.520 --> 0:07:42.880 get the manufactured toys to retailers or to customers. You 0:07:42.920 --> 0:07:46.400 have to manage all the money that's involved in those transactions, 0:07:46.400 --> 0:07:50.560 whether it's payments to services like the factories or accepting 0:07:50.600 --> 0:07:54.280 payments from customers. And for some businesses, this becomes a 0:07:54.320 --> 0:07:59.560 barrier to growth because it's so overwhelming. The transformation of 0:07:59.640 --> 0:08:02.640 small company to mid size company or mid size company 0:08:02.640 --> 0:08:06.239 to large company can be really daunting. So the lure 0:08:06.480 --> 0:08:09.600 of infrastructure as a service is that companies that have 0:08:09.640 --> 0:08:15.680 already designed systems, usually suites of programs that streamlined various processes, 0:08:15.920 --> 0:08:19.320 will share that knowledge and capability with you for a price. 0:08:19.440 --> 0:08:21.960 So you pay a subscription and then you get all 0:08:22.120 --> 0:08:24.520 access to all these tools that may help you do 0:08:24.600 --> 0:08:29.240 things like track your supply chain, to track production and 0:08:29.360 --> 0:08:32.120 even see how things have changed over time. Like there 0:08:32.160 --> 0:08:35.320 are some very sophisticated programs out there that allow you 0:08:35.360 --> 0:08:39.240 to get very granular with data. Data analysis is a 0:08:39.360 --> 0:08:43.320 huge part of cloud computing services because it provides another 0:08:43.960 --> 0:08:47.160 value to the customer if you can say, not only 0:08:47.200 --> 0:08:50.439 will we show you what the UH you know where 0:08:50.480 --> 0:08:53.280 you are at any given time, will show you trends 0:08:53.440 --> 0:08:56.959 and will even start to predict risks that might be 0:08:57.200 --> 0:09:00.240 in place, like maybe we see that because of this 0:09:00.320 --> 0:09:03.120 one element in the supply chain, you're going to have 0:09:03.280 --> 0:09:06.960 a bottleneck in the manufacturing process, which might mean you 0:09:07.040 --> 0:09:09.440 need to be able to communicate out to customers that 0:09:09.480 --> 0:09:13.120 there's currently a shortage of whatever the product is and 0:09:13.160 --> 0:09:15.040 that you will be turning this around as soon as 0:09:15.040 --> 0:09:17.920 you can. Or it might even be something about how 0:09:18.160 --> 0:09:22.840 producing UH your product in one region might be more 0:09:22.920 --> 0:09:27.200 economically viable than another region, even within the same country, 0:09:27.400 --> 0:09:29.920 so that you can get your products to market with 0:09:30.000 --> 0:09:33.880 a lower cost, not just economic, but environmental. It could 0:09:33.920 --> 0:09:38.040 be something as as UH intrinsic as how many miles 0:09:38.440 --> 0:09:40.520 have to be traveled in order to get your product 0:09:40.600 --> 0:09:44.040 to market. So it gets really really complicated, and you 0:09:44.040 --> 0:09:47.040 can see how if you're running your own business, once 0:09:47.080 --> 0:09:51.880 you start layering on these different considerations, it rapidly gets 0:09:51.960 --> 0:09:55.760 outside of most people's comfort zone, so that that's kind 0:09:55.760 --> 0:09:58.960 of the selling point for infrastructure as a service. There's 0:09:59.000 --> 0:10:02.280 a more recent off ring that's called function as a 0:10:02.320 --> 0:10:05.320 service or f a a S. This creates a level 0:10:05.360 --> 0:10:09.280 of abstraction between the developer and virtual machines, so that 0:10:09.320 --> 0:10:13.240 developers only have to worry about creating very narrowly functional 0:10:13.360 --> 0:10:18.360 blocks of code, and essentially they're just creating the instructions 0:10:18.400 --> 0:10:21.360 that sit on top of this service, and the service 0:10:21.400 --> 0:10:25.480 does everything else. Like it removes the necessity to program 0:10:25.520 --> 0:10:30.640 for a specific stack of technology, so the developer just 0:10:30.679 --> 0:10:32.880 has to worry about the code that he or she 0:10:32.960 --> 0:10:35.680 needs to do whatever it is they want to do. 0:10:36.080 --> 0:10:40.360 And typically this kind of service executes upon a real 0:10:40.400 --> 0:10:43.840 world event happening. So something happens in the real world 0:10:44.240 --> 0:10:49.000 that triggers the function, and the function then gets executed 0:10:49.040 --> 0:10:52.480 by this service. So an example it would be, let's 0:10:52.480 --> 0:10:55.280 say you go to a website and there's a form 0:10:55.440 --> 0:10:57.360 you want to fill out in order to get access 0:10:57.440 --> 0:10:59.920 to something. So you fill out the form, you can 0:11:00.000 --> 0:11:03.640 complete it, and you submit it. That submission could be 0:11:03.679 --> 0:11:06.840 the real world event that then triggers this function, this 0:11:06.920 --> 0:11:10.960 hypothetical function I'm making up now. Unlike infrastructure as a 0:11:11.000 --> 0:11:14.079 service that's a perpetual model that means you have to 0:11:14.160 --> 0:11:16.280 keep paying a subscription for as long as you are 0:11:16.320 --> 0:11:20.120 relying upon that infrastructure. It is a day today thing. 0:11:20.679 --> 0:11:25.119 Function as a service typically only triggers a fee whenever 0:11:25.520 --> 0:11:29.720 the function itself gets triggered, so you're not paying every 0:11:29.720 --> 0:11:32.800 single day for this thing to exist. You're paying only 0:11:32.840 --> 0:11:35.240 when people are using it, which means that you can 0:11:35.280 --> 0:11:38.160 save money if it's not something that people are going 0:11:38.200 --> 0:11:40.959 crazy and using all the time. If it is, then 0:11:41.120 --> 0:11:43.400 maybe you have to look at a different model for 0:11:43.640 --> 0:11:46.640 economic purposes. But in general, it means that you can 0:11:46.679 --> 0:11:48.920 save a lot of money this way because it's very lightweight. 0:11:48.960 --> 0:11:52.880 It just exists on the top of the provider's services. 0:11:53.160 --> 0:11:55.680 Now there are other service models out there. I'm getting 0:11:55.679 --> 0:11:58.360 really tired of saying the word service, but it's that's 0:11:58.520 --> 0:12:02.240 just the term used. So there's storage as a service, 0:12:02.600 --> 0:12:05.960 that's what sounds like. That's your online document databases or 0:12:06.000 --> 0:12:09.520 photo albums or file storage or whatever. There's also video 0:12:09.559 --> 0:12:12.920 as a service. There's compute as a service. There's probably 0:12:12.960 --> 0:12:15.240 half a dozen more, but it all comes down to 0:12:15.280 --> 0:12:18.480 the concept of someone else running a process on lots 0:12:18.520 --> 0:12:21.079 of computers. You pay that someone a fee to make 0:12:21.160 --> 0:12:23.480 use of those assets, and it frees you up from 0:12:23.520 --> 0:12:26.720 having to build out your own massive computer system. Hey guys, 0:12:26.760 --> 0:12:29.760 before we go any further, I need to take a 0:12:29.880 --> 0:12:40.319 quick break to thank our sponsor. Let's get back to 0:12:40.440 --> 0:12:45.240 net Ledger and Evan Goldberg. The company ran accounting software 0:12:45.400 --> 0:12:48.720 that had a web enabled user interface, so customers could 0:12:48.720 --> 0:12:51.760 pay to use the service over the Internet rather than 0:12:51.760 --> 0:12:54.760 purchase a full software package and installed on their own machines. 0:12:55.080 --> 0:12:57.240 And one of the selling points of this approaches there's 0:12:57.240 --> 0:12:59.560 never a need to upgrade your software. And by that 0:12:59.640 --> 0:13:02.200 I mean if you buy a software package, like a 0:13:02.240 --> 0:13:06.680 conventional traditional software package, chances are sooner or later there's 0:13:06.679 --> 0:13:09.920 going to be an updated version coming along, which creates 0:13:09.960 --> 0:13:12.720 a lot of pressure on customers. So do you upgrade 0:13:12.880 --> 0:13:15.960 to the latest version? If so, you probably have to 0:13:15.960 --> 0:13:19.000 spend more money to do it. If you don't upgrade 0:13:19.040 --> 0:13:21.040 to the latest version, you might find that some of 0:13:21.080 --> 0:13:24.439 your data you work with becomes incompatible with your older 0:13:24.520 --> 0:13:29.640 legacy systems because it's meant for the newer versions of 0:13:29.679 --> 0:13:32.600 the software. So there could be features that the newer 0:13:32.720 --> 0:13:35.920 version has that your old version does not have and 0:13:35.920 --> 0:13:40.080 it doesn't support, and so you start running into compatibility issues. 0:13:40.320 --> 0:13:43.520 But with software as a service, the provider makes all 0:13:43.520 --> 0:13:45.880 the upgrades to the service on their end on the 0:13:45.960 --> 0:13:49.000 on the back end, So you're accessing the software through 0:13:49.040 --> 0:13:52.480 the Internet, whether it's through the web or through an app, 0:13:52.800 --> 0:13:56.000 whatever it may be. You don't have to worry about 0:13:56.400 --> 0:13:59.920 installing upgrades or patches necessarily. I mean sometimes you do, 0:14:00.040 --> 0:14:01.960 but that's what the app world. If you're talking about 0:14:02.000 --> 0:14:05.640 web browsers, you typically don't. So all you're doing is 0:14:05.679 --> 0:14:09.360 just accessing the service. All of the upgrades are being 0:14:09.400 --> 0:14:12.160 done behind the scenes on the provider side. So one 0:14:12.160 --> 0:14:14.400 of the benefits of this model is that you always 0:14:14.400 --> 0:14:18.000 have access to the latest version of the service as 0:14:18.000 --> 0:14:21.520 long as you remain a customer. Net Ledgers features grew 0:14:21.920 --> 0:14:25.600 the company evolved into net Suite, which better indicated that 0:14:25.640 --> 0:14:29.000 the company was offering up multiple internet based services. A 0:14:29.040 --> 0:14:31.720 short time after Goldberg found a net Suite, there was 0:14:31.760 --> 0:14:35.840 another cloud based services company that popped up called Salesforce 0:14:35.920 --> 0:14:39.800 dot Com. The founders of salesforce dot Com included one 0:14:39.920 --> 0:14:44.280 former Oracle executive named Mark bennie Off and three software 0:14:44.280 --> 0:14:49.080 developers named Frank Dominguez, Parker Harris, and Dave Mollenhoff, who 0:14:49.080 --> 0:14:53.280 had come from Left Coast Software. Their first product was 0:14:53.480 --> 0:14:57.560 a type of sales automation software, and Salesforce rapidly gained 0:14:57.560 --> 0:15:01.080 attention as it was offering up enterprise level services over 0:15:01.120 --> 0:15:05.160 a relatively simple web based interface. The company became incredibly 0:15:05.200 --> 0:15:07.960 successful and was able to weather the dot com crash 0:15:08.080 --> 0:15:12.760 and grow into a multibillion dollar global company. Net Suite 0:15:12.800 --> 0:15:15.080 also made it through the crash and became a much 0:15:15.160 --> 0:15:18.200 larger organization over time, and in two thousand and sixteen, 0:15:18.240 --> 0:15:21.000 the company was acquired by Oracle. I'll talk more about 0:15:21.080 --> 0:15:24.480 both net Suite and Oracle in upcoming episodes. But in 0:15:24.520 --> 0:15:28.600 two thousand two, Amazon made a move to maximize company efficiency. 0:15:28.960 --> 0:15:32.040 The standard practice at the time was to have enough capacity, 0:15:32.200 --> 0:15:36.520 like computer capacity, to do your work while only using 0:15:36.560 --> 0:15:41.040 ten of your capacity. But that's not very efficient. It 0:15:41.080 --> 0:15:44.720 means that nine cent of your computer capacity goes unused, 0:15:44.760 --> 0:15:47.240 and so Amazon began to explore other options that would 0:15:47.240 --> 0:15:51.480 allow them to leverage that. The answer turned out to 0:15:51.480 --> 0:15:55.200 be cloud storage and cloud computing, and in two thousand 0:15:55.320 --> 0:15:59.720 six they expanded this by introducing Amazon Web Services, which 0:15:59.800 --> 0:16:01.920 had a whole bunch of different web based services that 0:16:01.960 --> 0:16:05.800 companies can use, including mechanical turk so quick side note 0:16:05.800 --> 0:16:08.440 about Mechanical Turk because I just love this story. So 0:16:08.520 --> 0:16:11.640 Amazon markets it as a tool that allows customers to 0:16:11.760 --> 0:16:15.720 leverage human intelligence for specific tasks because humans tend to 0:16:15.760 --> 0:16:19.760 be better at certain things than computers. And by better, 0:16:19.800 --> 0:16:22.080 I mean we can do that particular type of work 0:16:22.160 --> 0:16:26.000 much more quickly and reliably. But it can be expensive 0:16:26.320 --> 0:16:29.720 to hire humans to do those tasks, especially if the 0:16:29.720 --> 0:16:34.160 tasks are very simple, and if you only need people 0:16:34.280 --> 0:16:36.840 for a short amount of time, then hiring a huge workforce, 0:16:36.920 --> 0:16:40.720 a temporary workforce, that's that's an an enormous expense, and 0:16:41.040 --> 0:16:44.480 not just money, but also in time. And so Amazon 0:16:44.560 --> 0:16:48.720 Mechanical Turk is an on demand workforce service. It's kind 0:16:48.720 --> 0:16:51.920 of like a group of people employed by Amazon to 0:16:52.040 --> 0:16:55.000 do whatever it is you need them to do with 0:16:55.120 --> 0:17:00.880 your human task issues. And then then once that's, once 0:17:00.920 --> 0:17:03.160 that projects done, they go on to do something else. 0:17:03.400 --> 0:17:05.679 And it sounds a little creepy if I'm being totally honest, 0:17:05.760 --> 0:17:07.960 But the reason why I wanted to talk about them 0:17:08.000 --> 0:17:11.040 was because of what mechanical Turk is a reference to. 0:17:11.240 --> 0:17:16.199 It's actually referencing an old piece of clockwork chicanery. The 0:17:16.280 --> 0:17:20.080 original device was called simply the turk, and it appeared 0:17:20.119 --> 0:17:24.600 to be a clockwork automaton that had the figure of 0:17:24.640 --> 0:17:27.639 a turk sitting at a chessboard. It was made by 0:17:27.680 --> 0:17:31.399 a guy named wolf Gang Fawn Kimberland. He built it 0:17:31.440 --> 0:17:34.680 in the late seventeen hundreds, like in the seventeen seventies, 0:17:35.080 --> 0:17:37.879 and upon casual glance you would think it was a 0:17:38.040 --> 0:17:42.680 robot of ingenious design, capable of defeating even skilled players 0:17:42.680 --> 0:17:45.879 in chess. But in reality, there was a human being 0:17:46.000 --> 0:17:49.320 hidden within the cabinet of the machine who was guiding 0:17:49.400 --> 0:17:53.440 the turk's movements, and a playing chess against a human opponents. 0:17:53.480 --> 0:17:56.920 So really it was just two humans playing chess, only 0:17:56.960 --> 0:17:59.639 one of the humans was hidden out of sight. Just 0:18:00.040 --> 0:18:02.119 I love that story, so I wanted to tell it quickly. 0:18:02.400 --> 0:18:05.400 Around the same time the Amazon was introducing web services, 0:18:05.440 --> 0:18:08.560 Google debuted Google Docs, which was actually based off two 0:18:08.560 --> 0:18:12.680 earlier products. One of them was Google Spreadsheets, which Google acquired. 0:18:12.680 --> 0:18:15.400 They bought it from a company called two Web Technologies, 0:18:15.960 --> 0:18:20.160 and they also acquired a company called Rightly that ended 0:18:20.240 --> 0:18:22.760 up being the basis for the Google Docs part, the 0:18:22.800 --> 0:18:26.880 actual document offering of the product. How those moves began 0:18:26.920 --> 0:18:29.680 to bring cloud computing into the world of the home 0:18:29.840 --> 0:18:34.600 user for the first time. Earlier implementations were almost completely 0:18:34.640 --> 0:18:38.040 focused on business to business operations, which means most of 0:18:38.119 --> 0:18:40.880 us never see it right when we talk about business 0:18:40.880 --> 0:18:45.399 to business stuff, it's interesting because it tells us how 0:18:45.480 --> 0:18:48.679 the stuff we interact with, how that happens, how it 0:18:48.680 --> 0:18:51.560 gets done in the background, but we don't see it directly. 0:18:52.040 --> 0:18:55.720 That's why when we talk about companies like IBM, most 0:18:55.760 --> 0:19:00.359 of us have very little experience working directly with IBM 0:19:00.359 --> 0:19:05.120 products unless it's within the realm of the office, because 0:19:05.200 --> 0:19:10.840 IBM doesn't really make products for the home consumer. The 0:19:10.920 --> 0:19:12.840 same sort of thing here was that cloud computing for 0:19:12.880 --> 0:19:14.720 the longest time was not for the home consumer. It 0:19:14.760 --> 0:19:18.920 was for businesses. But with the emergence of these kind 0:19:19.000 --> 0:19:22.600 of applications, we were starting to see people get access 0:19:22.680 --> 0:19:25.280 to that sort of stuff for the first time in 0:19:25.320 --> 0:19:28.520 a big way. And that's when it became necessary to 0:19:28.520 --> 0:19:31.879 figure out how to explain that technology to people. And 0:19:31.960 --> 0:19:35.840 that's when cloud computing really became a buzzword, and also 0:19:35.920 --> 0:19:38.359 how I came to write sixteen articles about the stuff. 0:19:39.119 --> 0:19:43.040 These days, many companies are involved with cloud services, along 0:19:43.040 --> 0:19:47.920 with net Suite and Salesforce there's Amazon, Google, Microsoft has 0:19:47.960 --> 0:19:52.800 its Azure platform, IBM is a big one, and there's 0:19:52.920 --> 0:19:55.800 tons of others. And the services being offered by these 0:19:55.800 --> 0:19:59.520 companies have grown significantly over time as well. For example, 0:19:59.760 --> 0:20:01.600 i EM offers you the chance to work on a 0:20:01.680 --> 0:20:05.040 quantum computer over the cloud, which still blows my mind. 0:20:05.760 --> 0:20:07.560 We got just a bit more to talk about with 0:20:07.600 --> 0:20:10.080 cloud computing, but before I get into it, let's take 0:20:10.080 --> 0:20:20.040 another quick break to thank our sponsor. One thing I 0:20:20.040 --> 0:20:21.919 feel we should talk about is the different types of 0:20:21.960 --> 0:20:25.680 cloud computing models. And I almost said different types of clouds, 0:20:25.680 --> 0:20:28.320 but I need to be more serious. That's a cloud joke. 0:20:28.840 --> 0:20:32.040 One type is the public cloud model. Now, these are 0:20:32.080 --> 0:20:34.760 services in which all the assets are run by a 0:20:34.840 --> 0:20:38.200 third party. So I talked about Google Docs. That's a 0:20:38.240 --> 0:20:41.879 great example of a public cloud computer model. So if 0:20:41.920 --> 0:20:46.760 your company relies on Google Suite for all of its processes, really, 0:20:47.280 --> 0:20:49.800 then you'll be relying on a public cloud. Then you've 0:20:49.800 --> 0:20:54.639 got private clouds and those models. The company itself, whatever 0:20:54.680 --> 0:20:58.240 company it is that's running the processes, it actually owns 0:20:58.720 --> 0:21:02.680 all the equipment and the services that run on that equipment. 0:21:03.359 --> 0:21:06.520 So let's say you work for a company ABC, The 0:21:06.640 --> 0:21:11.080 private cloud is also owned by ABC, and it's got 0:21:11.119 --> 0:21:15.280 all these different data centers and they're running all these processes. 0:21:15.520 --> 0:21:20.359 So you're still accessing apps and programs and storage that 0:21:20.440 --> 0:21:23.960 exists on other computers. It's just that you work for 0:21:24.000 --> 0:21:27.399 the same company that owns those computers. It's not owned 0:21:27.440 --> 0:21:29.600 by a third party. Now, you would want to use 0:21:29.600 --> 0:21:33.119 the private cloud approach if you had mission critical applications 0:21:33.160 --> 0:21:35.880 that you wanted under your full control and you didn't 0:21:35.920 --> 0:21:38.040 want to entrust that to a third party. So if 0:21:38.040 --> 0:21:41.720 you're handling really sensitive information or the processes you rely upon, 0:21:41.880 --> 0:21:44.920 or really big trade secrets, that might be the way 0:21:44.920 --> 0:21:46.919 you want to go. Or if your needs are just 0:21:47.040 --> 0:21:50.600 so particular that there's not really a provider out there 0:21:50.640 --> 0:21:53.720 that can meet your needs because they're so different from 0:21:53.720 --> 0:21:56.359 what everyone else needs, this would be the way you 0:21:56.400 --> 0:21:59.879 would go. There's a third model called the hybrid cloud 0:22:00.040 --> 0:22:03.480 that merges those two. You have both public and private 0:22:03.520 --> 0:22:07.320 cloud entities. So a company with a hybrid cloud approach 0:22:07.760 --> 0:22:11.760 would have a public cloud stuff to do to handle 0:22:11.760 --> 0:22:14.840 certain tasks, private cloud to handle other tasks, and as 0:22:14.880 --> 0:22:17.240 you might imagine, the more critical elements to the company's 0:22:17.240 --> 0:22:20.320 operations would probably run on the private cloud, while more 0:22:20.400 --> 0:22:24.040 mundane processes might be pushed to the public cloud service, 0:22:24.560 --> 0:22:28.080 and there's some sort of layer of communication and automation 0:22:28.400 --> 0:22:31.239 that allows for the exchange of data between those two 0:22:31.320 --> 0:22:34.440 clouds in a controlled manner so that the output from 0:22:34.480 --> 0:22:37.400 one can work with the information on the other. In fact, 0:22:37.440 --> 0:22:40.920 without that communication channel between the two clouds, you do 0:22:41.000 --> 0:22:44.560 not actually have a hybrid cloud. You would instead have 0:22:44.680 --> 0:22:47.679 what is called a multi cloud approach. You would have 0:22:48.040 --> 0:22:52.160 two distinct cloud services that do not communicate with each other. 0:22:52.440 --> 0:22:54.359 And there are valid reasons to go with a multi 0:22:54.359 --> 0:22:58.960 cloud approach where there is no communication between clouds. So again, 0:22:59.040 --> 0:23:02.000 let's talk about a really big company. Really big companies 0:23:02.040 --> 0:23:05.800 could have departments. They're so large and have such specific 0:23:05.840 --> 0:23:10.160 needs they do not need to communicate directly with other 0:23:10.200 --> 0:23:14.359 departments to get their their work done. Their their work 0:23:14.400 --> 0:23:17.160 may not relate directly with other departments, so in those 0:23:17.200 --> 0:23:19.680 cases it might make more sense to have a separate 0:23:19.720 --> 0:23:25.520 public or private cloud available to those departments either, so 0:23:25.600 --> 0:23:28.840 you can have multi cloud approach that uses either private 0:23:28.960 --> 0:23:32.240 or public or both. The important element here is that 0:23:32.280 --> 0:23:35.720 there isn't that communication channel between them. So as companies 0:23:35.720 --> 0:23:38.879 grow they often find that the departments inside them end 0:23:38.960 --> 0:23:41.600 up being larger than the original company was when it 0:23:41.640 --> 0:23:45.000 first got started, and at that size, finding processes that 0:23:45.160 --> 0:23:48.919 work and scale is critical. Now, at the top of 0:23:48.920 --> 0:23:50.760