1 00:00:00,060 --> 00:00:00,893 These days, 2 00:00:00,893 --> 00:00:02,820 cloud computing can be found everywhere, 3 00:00:02,820 --> 00:00:05,520 and it's really because there are so many great benefits 4 00:00:05,520 --> 00:00:07,230 to using cloud computing, 5 00:00:07,230 --> 00:00:09,420 and that's what we're going to focus on in this lesson 6 00:00:09,420 --> 00:00:11,580 as we start talking about the different characteristics 7 00:00:11,580 --> 00:00:12,870 of the cloud. 8 00:00:12,870 --> 00:00:14,550 When we talk about cloud computing, 9 00:00:14,550 --> 00:00:17,130 there are a handful of benefits or characteristics 10 00:00:17,130 --> 00:00:19,620 that we see when we choose to use the cloud. 11 00:00:19,620 --> 00:00:23,400 These include high availability, scalability, elasticity, 12 00:00:23,400 --> 00:00:25,650 metered utilization, shared resources, 13 00:00:25,650 --> 00:00:27,480 and file synchronization. 14 00:00:27,480 --> 00:00:28,980 Let's take a look at these. 15 00:00:28,980 --> 00:00:31,290 First, we have high availability. 16 00:00:31,290 --> 00:00:33,510 Now, high availability refers to the fact 17 00:00:33,510 --> 00:00:36,030 that services experience very little downtime 18 00:00:36,030 --> 00:00:37,710 when you're using the cloud. 19 00:00:37,710 --> 00:00:39,210 This is because most of the services 20 00:00:39,210 --> 00:00:40,500 that are built on the cloud are built 21 00:00:40,500 --> 00:00:43,110 to be highly reliable and very fault tolerant. 22 00:00:43,110 --> 00:00:45,840 This means that we can ensure a high level of availability. 23 00:00:45,840 --> 00:00:47,550 Now, when it comes to availability, 24 00:00:47,550 --> 00:00:50,070 we usually measure this in terms of a percentage 25 00:00:50,070 --> 00:00:53,700 of how much uptime there is versus how much downtime. 26 00:00:53,700 --> 00:00:56,910 So for example, the gold standard inside of networks 27 00:00:56,910 --> 00:00:58,800 is known as five nines. 28 00:00:58,800 --> 00:01:03,800 Five nines means 99.999% uptime or availability 29 00:01:04,080 --> 00:01:06,330 as experienced by your end users. 30 00:01:06,330 --> 00:01:07,920 This means that we can only have 31 00:01:07,920 --> 00:01:12,480 about 5 minutes and 15 seconds of downtime every year. 32 00:01:12,480 --> 00:01:15,000 That's right, only 5 minutes and 15 seconds 33 00:01:15,000 --> 00:01:18,480 across the entire 365 days in a year. 34 00:01:18,480 --> 00:01:20,340 Now to do that, that means you have 35 00:01:20,340 --> 00:01:23,370 to have highly reliable systems that are highly available. 36 00:01:23,370 --> 00:01:26,640 So if you have one website, you're actually going to have 37 00:01:26,640 --> 00:01:29,010 at least two web servers that are hosting that. 38 00:01:29,010 --> 00:01:30,240 So if one goes down, 39 00:01:30,240 --> 00:01:32,100 the other one is still carrying the load. 40 00:01:32,100 --> 00:01:35,670 And that means the end user doesn't experience any downtime. 41 00:01:35,670 --> 00:01:36,630 That's what we're talking about 42 00:01:36,630 --> 00:01:38,580 when we talk about high availability. 43 00:01:38,580 --> 00:01:42,150 For example, with my own website, diontraining.com, 44 00:01:42,150 --> 00:01:44,700 we actually have a very highly available setup 45 00:01:44,700 --> 00:01:47,220 that has been created using cloud services. 46 00:01:47,220 --> 00:01:50,010 So depending on where you are coming from in the world, 47 00:01:50,010 --> 00:01:52,050 you're going to reach one of our multiple servers 48 00:01:52,050 --> 00:01:54,240 located around the world that's closest to you 49 00:01:54,240 --> 00:01:55,650 to get a better experience. 50 00:01:55,650 --> 00:01:57,930 Now, if your server is down for some reason, 51 00:01:57,930 --> 00:01:59,460 you'll automatically be rerouted 52 00:01:59,460 --> 00:02:01,410 to another one that's a little bit further from you, 53 00:02:01,410 --> 00:02:02,550 but it's still up. 54 00:02:02,550 --> 00:02:04,470 And so that way, you still get the service 55 00:02:04,470 --> 00:02:05,430 you're looking for, 56 00:02:05,430 --> 00:02:08,400 and that is a way to ensure high availability. 57 00:02:08,400 --> 00:02:10,020 The second characteristic of the cloud 58 00:02:10,020 --> 00:02:12,450 we're going to talk about is known as scalability. 59 00:02:12,450 --> 00:02:14,430 Now, when we talk about scalability, 60 00:02:14,430 --> 00:02:15,840 this is talking about the fact 61 00:02:15,840 --> 00:02:17,880 that we can increase the number of people 62 00:02:17,880 --> 00:02:21,270 or the number of things in our system at a linear rate 63 00:02:21,270 --> 00:02:23,160 or less than a linear rate. 64 00:02:23,160 --> 00:02:24,270 Now, what I mean by that is, 65 00:02:24,270 --> 00:02:26,700 let's say, I have 100 users using my system, 66 00:02:26,700 --> 00:02:28,560 and it costs me $10. 67 00:02:28,560 --> 00:02:30,510 Well, if I put 200 users on my system, 68 00:02:30,510 --> 00:02:32,940 it should cost me $20 or less, 69 00:02:32,940 --> 00:02:34,920 and that would be a linear scale. 70 00:02:34,920 --> 00:02:37,770 Now, if I went from 100 users to 200 users 71 00:02:37,770 --> 00:02:40,440 and the price went from $10 to $100, 72 00:02:40,440 --> 00:02:43,320 that would be an exponential scale, and we don't want that. 73 00:02:43,320 --> 00:02:45,090 So as we're building out our cloud systems, 74 00:02:45,090 --> 00:02:47,040 we're always looking for scalability. 75 00:02:47,040 --> 00:02:49,770 And that means that even if we only have 10 users today, 76 00:02:49,770 --> 00:02:51,030 tomorrow, we might have 100. 77 00:02:51,030 --> 00:02:52,530 The day after that, we might have 1,000. 78 00:02:52,530 --> 00:02:55,170 The day after that, we might have 10,000, and so on. 79 00:02:55,170 --> 00:02:57,000 If you look at some of the big companies out there 80 00:02:57,000 --> 00:03:00,540 like Facebook, and Google, and LinkedIn, and Udemy, 81 00:03:00,540 --> 00:03:02,820 they have millions of end users who are accessing 82 00:03:02,820 --> 00:03:04,710 their platforms every single day, 83 00:03:04,710 --> 00:03:06,330 and they're able to scale up 84 00:03:06,330 --> 00:03:09,450 based on the scalability of cloud services, 85 00:03:09,450 --> 00:03:12,600 because I don't have to go and buy another $10,000 server 86 00:03:12,600 --> 00:03:14,430 to put in my local data center, 87 00:03:14,430 --> 00:03:16,590 because instead, I can just use Amazon's, 88 00:03:16,590 --> 00:03:19,500 and use a portion of their capability as I need it. 89 00:03:19,500 --> 00:03:20,910 Now, when it comes to scalability, 90 00:03:20,910 --> 00:03:22,590 there are two ways you can scale. 91 00:03:22,590 --> 00:03:25,500 One is to scale up, which is known as vertical scale. 92 00:03:25,500 --> 00:03:27,030 This is by adding more resources 93 00:03:27,030 --> 00:03:28,950 to a particular server or node. 94 00:03:28,950 --> 00:03:30,960 For example, if you're using a cloud-based server 95 00:03:30,960 --> 00:03:32,880 that has two virtual CPUs, 96 00:03:32,880 --> 00:03:35,670 you can actually increase that to four virtual CPUs. 97 00:03:35,670 --> 00:03:37,080 This is the idea of scaling up. 98 00:03:37,080 --> 00:03:38,520 You're adding more resources, 99 00:03:38,520 --> 00:03:40,980 whether that's more processors, more ram, more storage, 100 00:03:40,980 --> 00:03:43,050 more bandwidth, or things like that. 101 00:03:43,050 --> 00:03:45,060 Now, on the other hand, you can also scale out, 102 00:03:45,060 --> 00:03:47,010 which is known as horizontal scaling. 103 00:03:47,010 --> 00:03:49,380 This is where you still use smaller machines, 104 00:03:49,380 --> 00:03:51,690 but you use more of them all working in tandem 105 00:03:51,690 --> 00:03:53,310 behind a load balancer. 106 00:03:53,310 --> 00:03:55,500 So instead of having one server that's handling 107 00:03:55,500 --> 00:03:58,860 all of your load and scaling upward by increasing the CPUs 108 00:03:58,860 --> 00:04:01,350 and increasing the memory, you can instead scale out, 109 00:04:01,350 --> 00:04:03,270 and go from one server to two servers, 110 00:04:03,270 --> 00:04:05,880 or two servers to four, or four to eight, 111 00:04:05,880 --> 00:04:08,400 and you can keep moving outward by adding additional servers 112 00:04:08,400 --> 00:04:09,780 behind your load balancer 113 00:04:09,780 --> 00:04:11,850 that you can then handle additional traffic with. 114 00:04:11,850 --> 00:04:13,650 Now, this brings us to our third area, 115 00:04:13,650 --> 00:04:16,320 which is known as rapid elasticity. 116 00:04:16,320 --> 00:04:18,870 Now, when we talk about rapid elasticity, 117 00:04:18,870 --> 00:04:21,300 we are talking about the fact that we can scale up 118 00:04:21,300 --> 00:04:23,640 or scale down very quickly. 119 00:04:23,640 --> 00:04:25,710 Now, this is done because we use automation 120 00:04:25,710 --> 00:04:28,020 and orchestration with a lot of virtual machines 121 00:04:28,020 --> 00:04:29,910 on these physical servers that are owned 122 00:04:29,910 --> 00:04:33,600 by Amazon, Google, Microsoft, and other corporations 123 00:04:33,600 --> 00:04:36,510 that allow us to use portions or all of their services 124 00:04:36,510 --> 00:04:38,430 as we need to on demand. 125 00:04:38,430 --> 00:04:40,980 And this gives us that rapid elasticity. 126 00:04:40,980 --> 00:04:43,140 When you hear the term "rapid elasticity" 127 00:04:43,140 --> 00:04:45,150 or elasticity in general, 128 00:04:45,150 --> 00:04:47,490 think about it as the fact of the system's ability 129 00:04:47,490 --> 00:04:50,310 to handle changes to demand in real time. 130 00:04:50,310 --> 00:04:52,530 So, let's go back to the example of using 131 00:04:52,530 --> 00:04:54,720 my website at diontraining.com. 132 00:04:54,720 --> 00:04:56,430 If right now, I check my website 133 00:04:56,430 --> 00:04:58,710 and I have 1,000 students logged in, 134 00:04:58,710 --> 00:05:00,240 and I check in 5 minutes from now, 135 00:05:00,240 --> 00:05:02,430 and there's 10,000 students logged in, 136 00:05:02,430 --> 00:05:04,050 my systems are designed to spin up 137 00:05:04,050 --> 00:05:05,760 additional cloud resources 138 00:05:05,760 --> 00:05:08,340 and push some of that load from those new users 139 00:05:08,340 --> 00:05:10,170 onto those additional services. 140 00:05:10,170 --> 00:05:12,720 That is the idea of rapid elasticity. 141 00:05:12,720 --> 00:05:14,520 Generally, when you're working in the cloud, 142 00:05:14,520 --> 00:05:16,410 if you've designed your systems correctly, 143 00:05:16,410 --> 00:05:19,320 you have the ability to rapidly have elasticity 144 00:05:19,320 --> 00:05:21,060 and scale up very fast. 145 00:05:21,060 --> 00:05:23,460 And then similarly, when the demand goes away, 146 00:05:23,460 --> 00:05:25,680 you can quickly get rid of those extra servers, 147 00:05:25,680 --> 00:05:27,060 and bring them back down. 148 00:05:27,060 --> 00:05:28,200 And the reason you'd want to do that 149 00:05:28,200 --> 00:05:29,790 is because all those extra servers 150 00:05:29,790 --> 00:05:31,410 are going to cost you more money. 151 00:05:31,410 --> 00:05:33,330 And if you don't have enough users to have them, 152 00:05:33,330 --> 00:05:34,410 you don't want to pay for that. 153 00:05:34,410 --> 00:05:35,850 So you're going to release those, 154 00:05:35,850 --> 00:05:37,320 give it back to your service provider, 155 00:05:37,320 --> 00:05:40,080 so they can then rent that service out to somebody else. 156 00:05:40,080 --> 00:05:42,660 Instead, if you are doing an on-premise model, 157 00:05:42,660 --> 00:05:44,910 let's say, I had 1,000 students today. 158 00:05:44,910 --> 00:05:48,090 Well, for 1,000 students, I might need three web servers, 159 00:05:48,090 --> 00:05:49,770 but if I go to 10,000 students, 160 00:05:49,770 --> 00:05:52,230 I'm going to need another 15 web servers. 161 00:05:52,230 --> 00:05:55,020 Well, to do that, I would have to buy 15 more servers. 162 00:05:55,020 --> 00:05:55,860 I'd have to rack them. 163 00:05:55,860 --> 00:05:57,180 I'd have to install all the software. 164 00:05:57,180 --> 00:05:58,380 I'd have to configure them. 165 00:05:58,380 --> 00:05:59,520 All of that takes time. 166 00:05:59,520 --> 00:06:02,550 And so it's not very rapid in elasticity measures 167 00:06:02,550 --> 00:06:04,920 for us to be able to scale up to meet that demand. 168 00:06:04,920 --> 00:06:07,800 If you have a very slow growing business model, that's fine, 169 00:06:07,800 --> 00:06:10,110 but if you're dealing with something that has high velocity 170 00:06:10,110 --> 00:06:12,420 or any of these modern social media platforms, 171 00:06:12,420 --> 00:06:14,310 and something you've done has gone viral, 172 00:06:14,310 --> 00:06:15,630 and everyone goes to your website 173 00:06:15,630 --> 00:06:16,860 and starts flooding you, 174 00:06:16,860 --> 00:06:18,960 if you don't have the ability to scale up rapidly, 175 00:06:18,960 --> 00:06:21,870 you're going to miss out on the ability to capture that traffic 176 00:06:21,870 --> 00:06:23,880 that's coming from that viral incident. 177 00:06:23,880 --> 00:06:25,530 And so you want to be able to build your stuff 178 00:06:25,530 --> 00:06:27,300 in a rapid elastic manner, 179 00:06:27,300 --> 00:06:29,640 and that's what the cloud allows us to do. 180 00:06:29,640 --> 00:06:32,820 The fourth thing we have is known as metered utilization. 181 00:06:32,820 --> 00:06:35,520 Now, this goes back to our rapid elasticity discussion 182 00:06:35,520 --> 00:06:36,450 we just had. 183 00:06:36,450 --> 00:06:39,060 Now, when we are talking about metered utilization, 184 00:06:39,060 --> 00:06:40,080 we are talking about the fact 185 00:06:40,080 --> 00:06:43,740 that we are paying for a service on a pay-per-use basis. 186 00:06:43,740 --> 00:06:46,590 So when we're using a metered service like a database, 187 00:06:46,590 --> 00:06:48,660 they may charge us based on the number of users, 188 00:06:48,660 --> 00:06:49,770 or the number of connections, 189 00:06:49,770 --> 00:06:51,960 or the number of data being stored. 190 00:06:51,960 --> 00:06:55,020 Essentially, we're being charged based on the actual usage 191 00:06:55,020 --> 00:06:56,820 of the service being consumed. 192 00:06:56,820 --> 00:06:59,670 And we do that either on a second basis, a minute basis, 193 00:06:59,670 --> 00:07:03,420 an hourly basis, or a daily basis, or even a monthly basis. 194 00:07:03,420 --> 00:07:06,120 For example, I use AWS Lambda for a lot 195 00:07:06,120 --> 00:07:08,430 of my backend automations and functions, 196 00:07:08,430 --> 00:07:10,950 and they charge me based on my usage. 197 00:07:10,950 --> 00:07:13,230 Now, for every 1 million requests I make, 198 00:07:13,230 --> 00:07:14,760 they charge me 20 cents. 199 00:07:14,760 --> 00:07:16,380 And so it's a very efficient way for me 200 00:07:16,380 --> 00:07:17,820 to get my automations done, 201 00:07:17,820 --> 00:07:20,370 because it's a very, very low cost thing. 202 00:07:20,370 --> 00:07:22,530 I can have millions and millions of requests, 203 00:07:22,530 --> 00:07:24,870 and it would only cost me a couple of dollars. 204 00:07:24,870 --> 00:07:27,030 That is the idea of a metered service. 205 00:07:27,030 --> 00:07:29,250 Now, the other thing you'll see is, sometimes, 206 00:07:29,250 --> 00:07:31,530 you'll see a distinction between metered service 207 00:07:31,530 --> 00:07:32,910 and measured service. 208 00:07:32,910 --> 00:07:35,580 Now, when we talk about metered or measured services, 209 00:07:35,580 --> 00:07:37,440 we're really talking about the same thing 210 00:07:37,440 --> 00:07:39,570 and it's our ability to pay for something 211 00:07:39,570 --> 00:07:41,100 on a consumption basis. 212 00:07:41,100 --> 00:07:42,780 But there is a difference here. 213 00:07:42,780 --> 00:07:44,760 When you're using a metered service, 214 00:07:44,760 --> 00:07:48,090 you're paying for things based on the actual usage 215 00:07:48,090 --> 00:07:49,320 of what you've done. 216 00:07:49,320 --> 00:07:50,820 So if you think about your water bill 217 00:07:50,820 --> 00:07:52,440 or your electric bill at home, 218 00:07:52,440 --> 00:07:53,820 if you turned on your water hose 219 00:07:53,820 --> 00:07:55,560 and you filled up your swimming pool this month, 220 00:07:55,560 --> 00:07:57,330 you're going to pay a lot more for your water bill, 221 00:07:57,330 --> 00:07:59,610 because you used a lot more water. 222 00:07:59,610 --> 00:08:02,640 Now, conversely, when you deal with a measured service, 223 00:08:02,640 --> 00:08:04,860 this is more like your cell phone plan. 224 00:08:04,860 --> 00:08:08,070 In most places, you pay a monthly fee for a certain amount 225 00:08:08,070 --> 00:08:09,870 of usage of that cell phone, 226 00:08:09,870 --> 00:08:12,180 whether that's the number of text messages, minutes, 227 00:08:12,180 --> 00:08:14,040 or data you're allowed to consume. 228 00:08:14,040 --> 00:08:15,300 And once you go up to that limit, 229 00:08:15,300 --> 00:08:16,650 they will stop your service, 230 00:08:16,650 --> 00:08:19,380 and not give you any more until you pay them again. 231 00:08:19,380 --> 00:08:21,030 So when you think about a measured service, 232 00:08:21,030 --> 00:08:22,290 think about the fact that you're paying 233 00:08:22,290 --> 00:08:24,750 for a certain amount of quantity upfront, 234 00:08:24,750 --> 00:08:25,860 and whether you use it or not, 235 00:08:25,860 --> 00:08:27,600 you've already paid for that amount. 236 00:08:27,600 --> 00:08:28,860 But when you're dealing with metered service, 237 00:08:28,860 --> 00:08:31,020 you're paying for the exact amount you're using. 238 00:08:31,020 --> 00:08:33,419 And this is really one of the benefits of using the cloud, 239 00:08:33,419 --> 00:08:36,030 is that most things are done on a metered basis, 240 00:08:36,030 --> 00:08:38,370 where you're only paying for what you use. 241 00:08:38,370 --> 00:08:41,100 The next thing we're going to talk about is shared resources. 242 00:08:41,100 --> 00:08:43,679 Now, when we talk about shared resources, 243 00:08:43,679 --> 00:08:46,440 we're really talking about the ability to minimize our cost, 244 00:08:46,440 --> 00:08:48,240 because we're able to put our virtual machines 245 00:08:48,240 --> 00:08:50,160 on somebody else's servers. 246 00:08:50,160 --> 00:08:52,860 When you look at those servers that we're using for Amazon, 247 00:08:52,860 --> 00:08:55,080 and Azure, and Google Cloud, those things 248 00:08:55,080 --> 00:08:59,070 are 10, 20, $30,000 a piece for a good quality server. 249 00:08:59,070 --> 00:09:00,630 And so if you need to buy one of those 250 00:09:00,630 --> 00:09:02,580 to be able to host your WordPress blog, 251 00:09:02,580 --> 00:09:04,590 you're not really using all that capacity, 252 00:09:04,590 --> 00:09:06,360 because if you only have a couple hundred readers, 253 00:09:06,360 --> 00:09:08,040 it's not going to use that much load. 254 00:09:08,040 --> 00:09:09,930 So instead, it makes a lot more sense 255 00:09:09,930 --> 00:09:12,600 to take that one really expensive server, 256 00:09:12,600 --> 00:09:14,460 cut it up into little pieces essentially, 257 00:09:14,460 --> 00:09:16,530 and give it out in virtual machines 258 00:09:16,530 --> 00:09:18,390 out to everybody else who wants to use it. 259 00:09:18,390 --> 00:09:21,300 So we might be able to host 50 or 100 WordPress blogs 260 00:09:21,300 --> 00:09:24,420 on that one server instead of hosting just one. 261 00:09:24,420 --> 00:09:26,700 That's the idea of using shared resources. 262 00:09:26,700 --> 00:09:28,260 When we talk about shared resources, 263 00:09:28,260 --> 00:09:30,690 we're talking about pooling together all the hardware 264 00:09:30,690 --> 00:09:33,060 to make up the cloud provider's data center. 265 00:09:33,060 --> 00:09:35,670 And that way, it's not dedicated to a single individual, 266 00:09:35,670 --> 00:09:38,580 but we can all use it based on rapid elasticity, 267 00:09:38,580 --> 00:09:41,640 because hopefully what Amazon, and Google, and Azure 268 00:09:41,640 --> 00:09:43,620 are thinking is that when there's high periods 269 00:09:43,620 --> 00:09:44,910 of demand for my company, 270 00:09:44,910 --> 00:09:48,000 there might be low periods for your company and vice versa. 271 00:09:48,000 --> 00:09:50,220 So instead of us having to have dedicated hardware resources 272 00:09:50,220 --> 00:09:51,390 to each of our companies, 273 00:09:51,390 --> 00:09:54,240 we can share resources across the board. 274 00:09:54,240 --> 00:09:56,100 And the final characteristic of the cloud 275 00:09:56,100 --> 00:09:58,650 is the ability to do file synchronization. 276 00:09:58,650 --> 00:10:01,620 Now, the great thing about using a cloud-based resource 277 00:10:01,620 --> 00:10:03,630 is that you can put something in one place, 278 00:10:03,630 --> 00:10:05,820 and it can then spread to other places 279 00:10:05,820 --> 00:10:07,440 based on how you configure it. 280 00:10:07,440 --> 00:10:08,760 For example, in my company, 281 00:10:08,760 --> 00:10:11,220 we rely on file synchronization a lot, 282 00:10:11,220 --> 00:10:14,040 because most of our people are actually remote employees 283 00:10:14,040 --> 00:10:17,550 that work all over the world, not just in our own offices. 284 00:10:17,550 --> 00:10:18,810 So as I'm sitting here in my office 285 00:10:18,810 --> 00:10:20,040 recording this right now, 286 00:10:20,040 --> 00:10:21,240 I need a way to give this file 287 00:10:21,240 --> 00:10:22,740 over to my graphic designer, 288 00:10:22,740 --> 00:10:24,630 so that she can create all the different things 289 00:10:24,630 --> 00:10:27,000 that you're seeing on the screen as I'm talking. 290 00:10:27,000 --> 00:10:29,490 And then she's going to go and send it over to another country, 291 00:10:29,490 --> 00:10:31,350 where my video editor is located. 292 00:10:31,350 --> 00:10:33,150 And when they're done, they're going to send it back over 293 00:10:33,150 --> 00:10:34,920 to my offices where one of my staff 294 00:10:34,920 --> 00:10:36,840 is going to do our quality assurance checks, 295 00:10:36,840 --> 00:10:38,340 and then we're going to send it to another country 296 00:10:38,340 --> 00:10:39,990 who's going to then upload it to the final site, 297 00:10:39,990 --> 00:10:41,070 where you're going to see it. 298 00:10:41,070 --> 00:10:43,470 And so this one video has traveled 299 00:10:43,470 --> 00:10:45,600 probably to four or five different places 300 00:10:45,600 --> 00:10:47,310 to be able to be that finished product 301 00:10:47,310 --> 00:10:49,410 that you're seeing right now on the screen. 302 00:10:49,410 --> 00:10:51,570 This is the idea of file synchronization, 303 00:10:51,570 --> 00:10:52,890 because when I record this, 304 00:10:52,890 --> 00:10:55,410 I'm recording it to a cloud-based file server. 305 00:10:55,410 --> 00:10:57,540 Everyone on my team can access that file, 306 00:10:57,540 --> 00:10:59,310 because we have that synchronized copy 307 00:10:59,310 --> 00:11:02,100 on all of their devices and across all of our servers 308 00:11:02,100 --> 00:11:02,970 around the world, 309 00:11:02,970 --> 00:11:05,340 so they can access it and do what they need to. 310 00:11:05,340 --> 00:11:06,540 And as they're doing that, 311 00:11:06,540 --> 00:11:08,460 it's not sitting just on their computer, 312 00:11:08,460 --> 00:11:11,010 but it's being synchronized across all of our cloud servers. 313 00:11:11,010 --> 00:11:13,620 So everybody else along that path that needs to happen 314 00:11:13,620 --> 00:11:15,450 between recording and publishing 315 00:11:15,450 --> 00:11:18,990 and then you watching it can happen across all those servers 316 00:11:18,990 --> 00:11:20,700 in a very streamlined manner. 317 00:11:20,700 --> 00:11:22,860 And that's one of the real big benefits of doing cloud 318 00:11:22,860 --> 00:11:24,330 from a business perspective, 319 00:11:24,330 --> 00:11:26,910 is that you don't have this server sitting in your office. 320 00:11:26,910 --> 00:11:29,520 It's now sitting out in the cloud in a data center 321 00:11:29,520 --> 00:11:31,590 that's protected, that's highly available, 322 00:11:31,590 --> 00:11:33,480 that has the ability to be scalable, 323 00:11:33,480 --> 00:11:35,700 and can be elastic in responding to demands 324 00:11:35,700 --> 00:11:37,680 of higher and lower periods of demands. 325 00:11:37,680 --> 00:11:39,450 We only have to pay for what we use 326 00:11:39,450 --> 00:11:41,460 and we can share resources with other people 327 00:11:41,460 --> 00:11:42,870 that we may not even know, 328 00:11:42,870 --> 00:11:45,420 because we're all sitting on the same physical server. 329 00:11:45,420 --> 00:11:47,190 And these are all the things we're talking about 330 00:11:47,190 --> 00:11:49,110 when we start talking about cloud characteristics, 331 00:11:49,110 --> 00:11:51,870 and why there's been this big migration into the cloud 332 00:11:51,870 --> 00:11:53,733 by many companies around the world.