1 1 00:00:00,150 --> 00:00:02,720 Cloud concepts in this lesson, 2 2 00:00:02,720 --> 00:00:04,130 we're going to discuss some of the different 3 3 00:00:04,130 --> 00:00:07,060 cloud computing concepts that you need to be aware of. 4 4 00:00:07,060 --> 00:00:08,950 These include things like elasticity, 5 5 00:00:08,950 --> 00:00:11,070 scalability, multitenancy 6 6 00:00:11,070 --> 00:00:12,940 as well as the different security implications 7 7 00:00:12,940 --> 00:00:15,660 that you need to consider when using a cloud-based solution. 8 8 00:00:15,660 --> 00:00:17,550 First, let's talk about the concepts 9 9 00:00:17,550 --> 00:00:20,590 of elasticity and scalability because many people 10 10 00:00:20,590 --> 00:00:23,260 get these two concepts completely confused. 11 11 00:00:23,260 --> 00:00:25,600 Now, when we're referring to Cloud elasticity, 12 12 00:00:25,600 --> 00:00:27,830 we're attempting to match the resources allocated 13 13 00:00:27,830 --> 00:00:29,510 with the actual amount of resources needed 14 14 00:00:29,510 --> 00:00:31,320 at any given point in time. 15 15 00:00:31,320 --> 00:00:34,250 with elasticity, our Cloud-based servers and networks 16 16 00:00:34,250 --> 00:00:36,370 can grow or shrink dynamically 17 17 00:00:36,370 --> 00:00:39,450 as they need to in order to adapt to a changing workload. 18 18 00:00:39,450 --> 00:00:41,610 And all this happens automatically 19 19 00:00:41,610 --> 00:00:44,300 using automated workflows and orchestration. 20 20 00:00:44,300 --> 00:00:45,760 Now each different Cloud provider 21 21 00:00:45,760 --> 00:00:47,240 is going to define elasticity 22 22 00:00:47,240 --> 00:00:49,050 just a little bit differently. 23 23 00:00:49,050 --> 00:00:51,270 For example, Amazon web services 24 24 00:00:51,270 --> 00:00:54,360 defines elasticity as the ability to acquire resources 25 25 00:00:54,360 --> 00:00:56,550 as you need them and release resources 26 26 00:00:56,550 --> 00:00:58,240 when you no longer need them. 27 27 00:00:58,240 --> 00:01:00,000 Microsoft Azure on the other hand 28 28 00:01:00,000 --> 00:01:02,170 is going to define elasticity as the ability 29 29 00:01:02,170 --> 00:01:04,189 to quickly expand or decrease computer processing, 30 30 00:01:04,189 --> 00:01:07,960 memory and storage resources to meet changing demands 31 31 00:01:07,960 --> 00:01:09,830 without worrying about capacity planning 32 32 00:01:09,830 --> 00:01:12,060 and engineering for peak usage. 33 33 00:01:12,060 --> 00:01:13,610 When it comes to elasticity, 34 34 00:01:13,610 --> 00:01:15,470 I want you to think of a rubber band. 35 35 00:01:15,470 --> 00:01:17,440 Now let's say I have a single rubber band 36 36 00:01:17,440 --> 00:01:18,960 and you handed me some envelopes. 37 37 00:01:18,960 --> 00:01:20,120 I could take my rubber band 38 38 00:01:20,120 --> 00:01:22,430 and I could hold those envelopes together with them. 39 39 00:01:22,430 --> 00:01:25,000 Let's pretend you hit on me 10 envelopes, no problem. 40 40 00:01:25,000 --> 00:01:26,620 I put my rubber band around them 41 41 00:01:26,620 --> 00:01:28,430 and they're all bundled together now. 42 42 00:01:28,430 --> 00:01:30,160 Now, you may decide that you want to hand me 43 43 00:01:30,160 --> 00:01:32,040 another five envelopes, okay. 44 44 00:01:32,040 --> 00:01:33,600 I put those five with the other 10. 45 45 00:01:33,600 --> 00:01:35,520 And so now I have 15 total envelopes 46 46 00:01:35,520 --> 00:01:37,220 and my rubber band will stretch out 47 47 00:01:37,220 --> 00:01:40,350 to hold all of them without breaking most of the time. 48 48 00:01:40,350 --> 00:01:42,940 Now, if you ask me for the first 10 envelopes back, 49 49 00:01:42,940 --> 00:01:45,170 I can remove those and give them to you. 50 50 00:01:45,170 --> 00:01:46,860 And now the rubber band will shrink down 51 51 00:01:46,860 --> 00:01:48,810 and still hold the remaining five envelopes 52 52 00:01:48,810 --> 00:01:50,500 in a nice little bundle. 53 53 00:01:50,500 --> 00:01:52,770 This is the idea of elasticity at work. 54 54 00:01:52,770 --> 00:01:54,930 It's going to quickly stretch to meet the larger needs 55 55 00:01:54,930 --> 00:01:57,440 or contract down into the smaller needs, 56 56 00:01:57,440 --> 00:01:58,780 depending on what number of envelopes 57 57 00:01:58,780 --> 00:02:00,810 I actually need inside my bundle. 58 58 00:02:00,810 --> 00:02:04,560 Well, elasticity in the Cloud works exactly the same way. 59 59 00:02:04,560 --> 00:02:06,380 Elasticity is going to be focused on meeting 60 60 00:02:06,380 --> 00:02:08,260 the sudden increases and decreases 61 61 00:02:08,260 --> 00:02:10,190 in your workloads that are going to be experienced 62 62 00:02:10,190 --> 00:02:12,020 for a short period of time. 63 63 00:02:12,020 --> 00:02:14,700 Elasticity is very dynamic and it can quickly add 64 64 00:02:14,700 --> 00:02:17,540 or remove cloud resources to meet your needs. 65 65 00:02:17,540 --> 00:02:20,490 Now, elasticity is often used in public Cloud services, 66 66 00:02:20,490 --> 00:02:22,720 especially under a pay as you go model. 67 67 00:02:22,720 --> 00:02:25,820 For example, with AWS or Amazon Web Services, 68 68 00:02:25,820 --> 00:02:28,070 you can quickly add or remove additional bandwidth, 69 69 00:02:28,070 --> 00:02:30,870 storage or resources to your cloud based systems. 70 70 00:02:30,870 --> 00:02:33,510 And they'll just add or remove that and some of their costs 71 71 00:02:33,510 --> 00:02:34,810 to your monthly bill. 72 72 00:02:34,810 --> 00:02:37,220 Now, on the other hand, we also have scalability 73 73 00:02:37,220 --> 00:02:39,040 when we talk about cloud services. 74 74 00:02:39,040 --> 00:02:40,790 Now scalability is designed to be more 75 75 00:02:40,790 --> 00:02:43,110 of a static or long-term solution. 76 76 00:02:43,110 --> 00:02:44,320 Scalability is going to be used 77 77 00:02:44,320 --> 00:02:45,700 to handle the growing workload 78 78 00:02:45,700 --> 00:02:48,260 that's required to maintain good performance and efficiency 79 79 00:02:48,260 --> 00:02:50,460 for a given software or application. 80 80 00:02:50,460 --> 00:02:52,820 Commonly, you're going to find scalability used 81 81 00:02:52,820 --> 00:02:55,410 when the persistent or long-term deployment of resources 82 82 00:02:55,410 --> 00:02:57,560 is going to be necessary to handle the workload 83 83 00:02:57,560 --> 00:02:59,300 in a more static manner. 84 84 00:02:59,300 --> 00:03:01,790 For example, the underlying learning management software 85 85 00:03:01,790 --> 00:03:03,550 that I use allows me to scale up 86 86 00:03:03,550 --> 00:03:05,540 or scale down based on how big 87 87 00:03:05,540 --> 00:03:07,480 my student base actually grows. 88 88 00:03:07,480 --> 00:03:09,920 So I can sign up for an annual contract 89 89 00:03:09,920 --> 00:03:11,300 based on a given number of students 90 90 00:03:11,300 --> 00:03:13,060 that I expect to have this year. 91 91 00:03:13,060 --> 00:03:15,480 If I expect to have between one and 5000 students, 92 92 00:03:15,480 --> 00:03:16,520 I'll pay one amount. 93 93 00:03:16,520 --> 00:03:19,370 If I expect 5000 to 10,000, I pay a little bit more. 94 94 00:03:19,370 --> 00:03:21,090 If I expect 10,000, 15,000, 95 95 00:03:21,090 --> 00:03:23,260 I pay even more, and so on. 96 96 00:03:23,260 --> 00:03:24,760 This cloud based solution, 97 97 00:03:24,760 --> 00:03:26,530 I don't have to actually pay for what I use, 98 98 00:03:26,530 --> 00:03:28,830 but instead, I'm paying for a certain capacity 99 99 00:03:28,830 --> 00:03:30,160 based on the total amount of people 100 100 00:03:30,160 --> 00:03:32,290 that I plan to provide services to. 101 101 00:03:32,290 --> 00:03:34,450 Now, this is different than elasticity. 102 102 00:03:34,450 --> 00:03:35,960 If this was an elastic plan, 103 103 00:03:35,960 --> 00:03:37,940 you might see it set up that at the end of each month, 104 104 00:03:37,940 --> 00:03:39,600 they count the number of users I had 105 105 00:03:39,600 --> 00:03:41,790 and then charge me one cent per day, per user, 106 106 00:03:41,790 --> 00:03:43,460 for each one that was signed up. 107 107 00:03:43,460 --> 00:03:45,280 This way, I could increase or decrease 108 108 00:03:45,280 --> 00:03:47,260 the number of users each and every day. 109 109 00:03:47,260 --> 00:03:49,090 And therefore the workload being processed 110 110 00:03:49,090 --> 00:03:50,950 by their cloud service would go up or down 111 111 00:03:50,950 --> 00:03:52,000 each and every day. 112 112 00:03:52,000 --> 00:03:53,890 And then I only would pay for what I need 113 113 00:03:53,890 --> 00:03:55,390 each and every day. 114 114 00:03:55,390 --> 00:03:57,330 Now, in the case of this learning management system, 115 115 00:03:57,330 --> 00:03:59,760 we can only change our plan one time per year. 116 116 00:03:59,760 --> 00:04:01,470 So once we pick it, we're stuck with it 117 117 00:04:01,470 --> 00:04:03,010 for a good amount of time. 118 118 00:04:03,010 --> 00:04:05,190 Therefore, when we're dealing with scalability, 119 119 00:04:05,190 --> 00:04:07,160 we're dealing with more of a long-term solution, 120 120 00:04:07,160 --> 00:04:08,980 as opposed to a more elastic approach 121 121 00:04:08,980 --> 00:04:11,020 that can change every day or every hour 122 122 00:04:11,020 --> 00:04:12,370 or even every minute. 123 123 00:04:12,370 --> 00:04:15,090 Now, in both cases, whether we're going to be using elasticity 124 124 00:04:15,090 --> 00:04:17,270 or scalability, we need to have the ability 125 125 00:04:17,270 --> 00:04:20,110 to add or remove more resources to our networks. 126 126 00:04:20,110 --> 00:04:23,340 This is done using either vertical or horizontal scaling. 127 127 00:04:23,340 --> 00:04:26,130 Now don't get confused here because this type of scaling 128 128 00:04:26,130 --> 00:04:29,350 is used in both elasticity and scalability. 129 129 00:04:29,350 --> 00:04:30,980 So just because you see the word scaling 130 130 00:04:30,980 --> 00:04:33,580 doesn't mean it's tied just to scalability. 131 131 00:04:33,580 --> 00:04:35,130 Now remember, the big difference here 132 132 00:04:35,130 --> 00:04:37,680 is that with elasticity, we're looking at a short term 133 133 00:04:37,680 --> 00:04:40,810 addition or subtraction of resources, but with scalability, 134 134 00:04:40,810 --> 00:04:41,643 we're going to be focused 135 135 00:04:41,643 --> 00:04:43,970 on more long-term planning and adoption. 136 136 00:04:43,970 --> 00:04:46,010 So let's go back to the idea of vertical 137 137 00:04:46,010 --> 00:04:48,040 and horizontal scaling here for a minute. 138 138 00:04:48,040 --> 00:04:50,570 Vertical scaling, also known as scaling up, 139 139 00:04:50,570 --> 00:04:53,160 is used to increase the power of our existing resources 140 140 00:04:53,160 --> 00:04:54,630 in the working environment. 141 141 00:04:54,630 --> 00:04:56,510 For example, let's say you have a laptop 142 142 00:04:56,510 --> 00:04:58,090 that has four gigabytes of Ram in it, 143 143 00:04:58,090 --> 00:04:59,820 and it begins to slow down over time 144 144 00:04:59,820 --> 00:05:01,660 because you're doing a lot of work today. 145 145 00:05:01,660 --> 00:05:04,380 Well, if you wanted to vertically scale up that laptop, 146 146 00:05:04,380 --> 00:05:05,700 you could add more Ram to it. 147 147 00:05:05,700 --> 00:05:07,800 And this would speed up that device. 148 148 00:05:07,800 --> 00:05:08,780 In the cloud environment, 149 149 00:05:08,780 --> 00:05:11,440 we can often scale up our compute resources. 150 150 00:05:11,440 --> 00:05:13,520 Now, if you're using Amazon LightSail, for example, 151 151 00:05:13,520 --> 00:05:14,990 to host your brand new blog, 152 152 00:05:14,990 --> 00:05:16,600 you could start out with a minimal setup 153 153 00:05:16,600 --> 00:05:18,840 that costs about $3.50 a month. 154 154 00:05:18,840 --> 00:05:21,010 This will give you a 512 megabytes of Ram, 155 155 00:05:21,010 --> 00:05:24,220 a one core processor and 20 gigabytes of storage space. 156 156 00:05:24,220 --> 00:05:25,950 Now, as your new blog gets more popular 157 157 00:05:25,950 --> 00:05:27,180 and more people start reading it, 158 158 00:05:27,180 --> 00:05:30,100 you may start to notice that your server is slowing down. 159 159 00:05:30,100 --> 00:05:33,110 Well, you can simply scale up using vertical scaling 160 160 00:05:33,110 --> 00:05:34,760 by selecting the next higher plan, 161 161 00:05:34,760 --> 00:05:37,143 which would charge you $5 per month. 162 162 00:05:37,143 --> 00:05:39,058 And this will double the amount of memory 163 163 00:05:39,058 --> 00:05:40,241 and storage that you're going to get. 164 164 00:05:40,241 --> 00:05:41,789 A few weeks go by and your blog 165 165 00:05:41,789 --> 00:05:42,622 is getting more and more fans. 166 166 00:05:42,622 --> 00:05:43,970 And again, it starts to slow down. 167 167 00:05:43,970 --> 00:05:46,790 So you can again scale up by moving to the next plan, 168 168 00:05:46,790 --> 00:05:48,050 which is $10 per month. 169 169 00:05:48,050 --> 00:05:49,160 And again, you're going to double 170 170 00:05:49,160 --> 00:05:50,650 the amount of memory you have. 171 171 00:05:50,650 --> 00:05:51,530 You can keep doing this 172 172 00:05:51,530 --> 00:05:53,490 every time your site begins to slow down, 173 173 00:05:53,490 --> 00:05:56,240 but eventually, you're going to reach the highest level plan. 174 174 00:05:56,240 --> 00:05:58,390 And in the case of AWS's LightSail product, 175 175 00:05:58,390 --> 00:06:01,070 this is a virtual server with 32 gigabytes of Ram, 176 176 00:06:01,070 --> 00:06:04,060 an eight core processor and 640 gigabytes of storage 177 177 00:06:04,060 --> 00:06:06,280 for about $160 per month. 178 178 00:06:06,280 --> 00:06:09,370 Now, the other option we have is to use horizontal scaling, 179 179 00:06:09,370 --> 00:06:11,320 which is known as scaling out. 180 180 00:06:11,320 --> 00:06:13,710 With scaling out, you can add additional resources 181 181 00:06:13,710 --> 00:06:16,320 to help handle the extra load that's being experienced. 182 182 00:06:16,320 --> 00:06:19,020 Essentially, instead of having one server to host your blog, 183 183 00:06:19,020 --> 00:06:20,900 we would now have two servers to host your blog. 184 184 00:06:20,900 --> 00:06:22,120 And as you gain more readers, 185 185 00:06:22,120 --> 00:06:23,630 we're going to load bounce between them. 186 186 00:06:23,630 --> 00:06:24,600 If we get more readers, 187 187 00:06:24,600 --> 00:06:26,070 we're going to add a third and a fourth, 188 188 00:06:26,070 --> 00:06:27,520 and we'll keep adding more servers 189 189 00:06:27,520 --> 00:06:28,870 and doing more load balancing 190 190 00:06:28,870 --> 00:06:30,770 between all those different instances 191 191 00:06:30,770 --> 00:06:32,660 as you have more and more demand, 192 192 00:06:32,660 --> 00:06:34,600 this is the idea of scaling out. 193 193 00:06:34,600 --> 00:06:36,670 So, which type should we use? 194 194 00:06:36,670 --> 00:06:38,840 Well, vertical scaling or scaling up 195 195 00:06:38,840 --> 00:06:41,500 is really easy to use because you simply add faster 196 196 00:06:41,500 --> 00:06:44,180 and better components to your existing single server. 197 197 00:06:44,180 --> 00:06:45,440 This makes it easier to use, 198 198 00:06:45,440 --> 00:06:47,840 and it works well for long-term scalability. 199 199 00:06:47,840 --> 00:06:49,880 Normally when you're dealing with scalability, 200 200 00:06:49,880 --> 00:06:52,070 you're going to be dealing with vertical scaling. 201 201 00:06:52,070 --> 00:06:54,200 Now, on the other hand, if you want to use horizontal 202 202 00:06:54,200 --> 00:06:56,560 scaling or scaling out, you're going to need to ensure 203 203 00:06:56,560 --> 00:06:58,740 that your system is designed to support it. 204 204 00:06:58,740 --> 00:07:00,430 With scaling out, you need to have a method 205 205 00:07:00,430 --> 00:07:02,530 of breaking up a sequential piece of logic, 206 206 00:07:02,530 --> 00:07:05,390 into smaller pieces that each can be executed in parallel 207 207 00:07:05,390 --> 00:07:07,060 across multiple machines. 208 208 00:07:07,060 --> 00:07:09,130 Essentially, we're going to have a lot of different horses 209 209 00:07:09,130 --> 00:07:10,750 all running in the same direction. 210 210 00:07:10,750 --> 00:07:12,410 So we need to make sure they know that. 211 211 00:07:12,410 --> 00:07:13,880 When you're dealing with elasticity, 212 212 00:07:13,880 --> 00:07:16,420 normally you're going to be seeing scaling out 213 213 00:07:16,420 --> 00:07:17,890 or horizontal scaling being used, 214 214 00:07:17,890 --> 00:07:20,700 instead of vertical scaling or scaling up. 215 215 00:07:20,700 --> 00:07:22,500 Another benefit of using horizontal scaling 216 216 00:07:22,500 --> 00:07:24,450 over vertical scaling is that as you're adding 217 217 00:07:24,450 --> 00:07:26,020 more and more machines to the pool, 218 218 00:07:26,020 --> 00:07:28,210 we're not relying on a single machine anymore. 219 219 00:07:28,210 --> 00:07:30,670 For this reason, scaling out will provide more redundancy 220 220 00:07:30,670 --> 00:07:33,220 and it will result in less downtime. 221 221 00:07:33,220 --> 00:07:35,490 The next cloud computing concept that we need to cover 222 222 00:07:35,490 --> 00:07:37,270 is known as multitenancy. 223 223 00:07:37,270 --> 00:07:40,110 Now multitenancy means that a cloud computing architecture 224 224 00:07:40,110 --> 00:07:42,170 will allow customers to share computing resources 225 225 00:07:42,170 --> 00:07:43,960 in a public or private cloud. 226 226 00:07:43,960 --> 00:07:46,210 In multitenancy, each of the tenant's data 227 227 00:07:46,210 --> 00:07:48,120 is going to be isolated and remains invisible 228 228 00:07:48,120 --> 00:07:49,730 to all of the other tenants. 229 229 00:07:49,730 --> 00:07:50,880 Now, when I talk about a tenant, 230 230 00:07:50,880 --> 00:07:52,430 I'm really talking about a customer 231 231 00:07:52,430 --> 00:07:54,380 of business or an organization. 232 232 00:07:54,380 --> 00:07:56,760 Now in traditional, on-premise server environments, 233 233 00:07:56,760 --> 00:07:59,150 there's only going to be one tenant using your server. 234 234 00:07:59,150 --> 00:08:00,980 You, this is because your server 235 235 00:08:00,980 --> 00:08:02,630 is going to be sitting in your data center, 236 236 00:08:02,630 --> 00:08:05,030 on premise, inside your organization. 237 237 00:08:05,030 --> 00:08:06,790 This is a lot like having a single family home 238 238 00:08:06,790 --> 00:08:07,920 out in the suburbs. 239 239 00:08:07,920 --> 00:08:09,560 Everybody who lives inside of that house 240 240 00:08:09,560 --> 00:08:10,920 is part of the organization. 241 241 00:08:10,920 --> 00:08:12,570 In that case, your family. 242 242 00:08:12,570 --> 00:08:14,740 Now here, you're going to have a single tendency solution 243 243 00:08:14,740 --> 00:08:17,010 or dedicated solution by having one house 244 244 00:08:17,010 --> 00:08:19,110 with one family living inside of it. 245 245 00:08:19,110 --> 00:08:21,290 But if you lived in a big city like New York, 246 246 00:08:21,290 --> 00:08:23,258 you might instead choose to live 247 247 00:08:23,258 --> 00:08:24,091 in a large apartment building. 248 248 00:08:24,091 --> 00:08:24,924 In this large building, 249 249 00:08:24,924 --> 00:08:26,760 there might be 50 different apartments. 250 250 00:08:26,760 --> 00:08:28,160 Each family that lives in this building 251 251 00:08:28,160 --> 00:08:29,510 is assigned their own apartment. 252 252 00:08:29,510 --> 00:08:31,160 And they're only going to have one tenant 253 253 00:08:31,160 --> 00:08:32,470 inside that apartment, 254 254 00:08:32,470 --> 00:08:35,360 but there are 50 tenants inside this building. 255 255 00:08:35,360 --> 00:08:37,520 This allows that one tenant or family 256 256 00:08:37,520 --> 00:08:40,030 to be able to live in that one particular apartment. 257 257 00:08:40,030 --> 00:08:41,260 Now, when you go home from work, 258 258 00:08:41,260 --> 00:08:42,550 you're going to go into your apartment. 259 259 00:08:42,550 --> 00:08:44,900 You're going to shut the door and now none of your neighbors 260 260 00:08:44,900 --> 00:08:46,080 can see what you're doing. 261 261 00:08:46,080 --> 00:08:48,470 You're invisible to them and you have your privacy, 262 262 00:08:48,470 --> 00:08:50,920 even though you're in a multi-tenant environment. 263 263 00:08:50,920 --> 00:08:52,400 Well, a multi-tendency server 264 264 00:08:52,400 --> 00:08:54,790 works much the same way, with the physical server 265 265 00:08:54,790 --> 00:08:56,790 being divided up into individual portions 266 266 00:08:56,790 --> 00:08:58,140 that different tenants can use, 267 267 00:08:58,140 --> 00:08:59,580 while keeping all the other data 268 268 00:08:59,580 --> 00:09:01,010 from the other tenants invisible 269 269 00:09:01,010 --> 00:09:04,010 to the other tenants inside that same physical server. 270 270 00:09:04,010 --> 00:09:06,210 Now a multi-tenant solution will be able to provide 271 271 00:09:06,210 --> 00:09:07,970 increased storage and access 272 272 00:09:07,970 --> 00:09:09,830 compared to a single tenancy solution, 273 273 00:09:09,830 --> 00:09:12,000 because use a larger pool of shared resources 274 274 00:09:12,000 --> 00:09:14,560 that becomes available to everybody inside the group. 275 275 00:09:14,560 --> 00:09:16,350 Now multi-tenant solutions also provide 276 276 00:09:16,350 --> 00:09:18,930 a better use of resources and a lower overall cost 277 277 00:09:18,930 --> 00:09:20,910 for each individual tenant or customer, 278 278 00:09:20,910 --> 00:09:22,230 because we're all sharing the costs 279 279 00:09:22,230 --> 00:09:24,360 over a larger pool of customers. 280 280 00:09:24,360 --> 00:09:25,470 So for example, 281 281 00:09:25,470 --> 00:09:27,620 let's say you wanted to host your own website. 282 282 00:09:27,620 --> 00:09:29,330 You could go out and spend $10,000 283 283 00:09:29,330 --> 00:09:31,380 on a physical, single tenant server. 284 284 00:09:31,380 --> 00:09:32,880 And you would know that you have 100% 285 285 00:09:32,880 --> 00:09:34,350 of the computing power, memory 286 286 00:09:34,350 --> 00:09:36,560 and storage at all times available to you 287 287 00:09:36,560 --> 00:09:38,560 because you're not going to share it with anybody, 288 288 00:09:38,560 --> 00:09:40,360 but if you instead wanted to simply use 289 289 00:09:40,360 --> 00:09:43,070 a shared hosting solution using multitenancy, 290 290 00:09:43,070 --> 00:09:44,890 you might pay only a few dollars per month 291 291 00:09:44,890 --> 00:09:46,690 for that same capacity. 292 292 00:09:46,690 --> 00:09:49,750 Now, multitenancy isn't without its drawbacks though, 293 293 00:09:49,750 --> 00:09:51,520 when you use a multitenancy solution, 294 294 00:09:51,520 --> 00:09:53,560 there are two major concerns. 295 295 00:09:53,560 --> 00:09:55,800 First, we have the noisy neighbor effect. 296 296 00:09:55,800 --> 00:09:57,570 If you've ever lived in an apartment building, 297 297 00:09:57,570 --> 00:09:59,610 you've probably dealt with this in real life. 298 298 00:09:59,610 --> 00:10:01,530 You go out and you rent a really nice apartment 299 299 00:10:01,530 --> 00:10:02,980 in a multi-tenant building. 300 300 00:10:02,980 --> 00:10:04,930 Everything is going great, and everything is fine 301 301 00:10:04,930 --> 00:10:07,150 until a noisy neighbor moves in next door. 302 302 00:10:07,150 --> 00:10:10,130 Now the noisy neighbor may be playing loud music at 2:00 AM 303 303 00:10:10,130 --> 00:10:13,020 and waking you up or it might be a bunch of college students 304 304 00:10:13,020 --> 00:10:14,990 who decided it was a great deal to save money 305 305 00:10:14,990 --> 00:10:18,210 by putting five of them into a one bedroom studio apartment, 306 306 00:10:18,210 --> 00:10:20,310 either way they're moving in has started to cause 307 307 00:10:20,310 --> 00:10:22,160 all sorts of problems for you. 308 308 00:10:22,160 --> 00:10:25,170 Now, the same thing can happen in a multitenancy solution. 309 309 00:10:25,170 --> 00:10:27,450 Let's say you're running your company's emails automations 310 310 00:10:27,450 --> 00:10:28,980 on a multi-tendency solution. 311 311 00:10:28,980 --> 00:10:31,230 Something like MailChimp or Active Campaign. 312 312 00:10:31,230 --> 00:10:33,640 Well, those are multi-tendency solutions. 313 313 00:10:33,640 --> 00:10:35,060 There are a lot of different companies here 314 314 00:10:35,060 --> 00:10:36,240 that are using those services. 315 315 00:10:36,240 --> 00:10:39,000 And usually, those companies are going to have between 50 316 316 00:10:39,000 --> 00:10:41,960 and 100 customers on a single email server. 317 317 00:10:41,960 --> 00:10:43,880 Now, the problem is that if your company 318 318 00:10:43,880 --> 00:10:45,470 gets assigned to a shared server 319 319 00:10:45,470 --> 00:10:47,540 with somebody else who is sending out a lot of spam, 320 320 00:10:47,540 --> 00:10:48,880 everyone on that shared server 321 321 00:10:48,880 --> 00:10:51,140 is going to see their email delivery rates drop 322 322 00:10:51,140 --> 00:10:52,660 because you're all using the same server 323 323 00:10:52,660 --> 00:10:53,980 and the same IP address. 324 324 00:10:53,980 --> 00:10:55,720 And that IP addresses reputation 325 325 00:10:55,720 --> 00:10:57,730 is being hurt by that noisy neighbor. 326 326 00:10:57,730 --> 00:10:59,040 In this case, the spammer 327 327 00:10:59,981 --> 00:11:01,430 who is part of our multitenancy solution. 328 328 00:11:01,430 --> 00:11:03,550 The same thing can happen with shared web hosts. 329 329 00:11:03,550 --> 00:11:05,650 Maybe there's 20 sites on a single server 330 330 00:11:05,650 --> 00:11:07,670 and one of them starts getting really popular. 331 331 00:11:07,670 --> 00:11:09,990 Well, that's actually a bad thing for the rest of you 332 332 00:11:09,990 --> 00:11:12,410 because that popular site is now using an unfair amount 333 333 00:11:12,410 --> 00:11:14,300 of resources on that shared server. 334 334 00:11:14,300 --> 00:11:15,580 And this can reduce the performance 335 335 00:11:15,580 --> 00:11:17,180 for all the other tenants. 336 336 00:11:17,180 --> 00:11:19,700 After all, once we begin to rely on virtualization 337 337 00:11:19,700 --> 00:11:21,350 and cloud computing for our deployments, 338 338 00:11:21,350 --> 00:11:22,770 it becomes important to recognize 339 339 00:11:22,770 --> 00:11:25,590 that our data might be hosted on the same physical server 340 340 00:11:25,590 --> 00:11:27,300 as another organization's data, 341 341 00:11:27,300 --> 00:11:29,480 if we're using a multi-tendency solution. 342 342 00:11:29,480 --> 00:11:31,500 So we have to be aware of these risks. 343 343 00:11:31,500 --> 00:11:33,070 Now, by choosing one of these solutions, 344 344 00:11:33,070 --> 00:11:34,850 we are introducing some vulnerabilities 345 345 00:11:34,850 --> 00:11:36,640 into the security of our systems. 346 346 00:11:36,640 --> 00:11:38,550 First, if the physical server crashes 347 347 00:11:38,550 --> 00:11:40,350 due to something one organization does, 348 348 00:11:40,350 --> 00:11:41,830 it can affect the other organizations 349 349 00:11:41,830 --> 00:11:43,660 hosted on this same physical server. 350 350 00:11:43,660 --> 00:11:45,970 Again, this is the concept of the noisy neighbor 351 351 00:11:45,970 --> 00:11:47,280 that we just discussed. 352 352 00:11:47,280 --> 00:11:49,000 Similarly, if one organization 353 353 00:11:49,000 --> 00:11:49,950 has not maintained the security 354 354 00:11:49,950 --> 00:11:51,170 of their virtual environment, 355 355 00:11:51,170 --> 00:11:52,700 that's being hosted on that server, 356 356 00:11:52,700 --> 00:11:54,360 there is a possibility that an attacker 357 357 00:11:54,360 --> 00:11:56,570 could utilize that as a jumping off point 358 358 00:11:56,570 --> 00:11:58,346 and use that to the detriment of all the other organizations 359 359 00:11:58,346 --> 00:12:01,280 based on that same shared server. 360 360 00:12:01,280 --> 00:12:02,990 Just as there are concerns when you conduct 361 361 00:12:02,990 --> 00:12:05,130 interconnection of your networks with somebody else's, 362 362 00:12:05,130 --> 00:12:06,140 you also have to be concerned 363 363 00:12:06,140 --> 00:12:07,910 when hosting multiple organizations data 364 364 00:12:07,910 --> 00:12:09,380 on the same physical server, 365 365 00:12:09,380 --> 00:12:11,660 that's being run by giving cloud provider. 366 366 00:12:11,660 --> 00:12:13,599 Therefore it's important for us to properly configure, 367 367 00:12:13,599 --> 00:12:16,840 manage and audit user access to the virtual servers 368 368 00:12:16,840 --> 00:12:18,340 that are being hosted here. 369 369 00:12:18,340 --> 00:12:20,800 Also, you need to ensure that your cloud-based servers 370 370 00:12:20,800 --> 00:12:22,750 have the latest patches, anti-virus, 371 371 00:12:22,750 --> 00:12:25,170 anti-malware and access controls in place 372 372 00:12:25,170 --> 00:12:27,340 if you're going to be using the infrastructure as a service, 373 373 00:12:27,340 --> 00:12:29,340 as part of your cloud service model. 374 374 00:12:29,340 --> 00:12:30,790 Now, to minimize the risk 375 375 00:12:30,790 --> 00:12:32,680 of having a single physical service resources 376 376 00:12:32,680 --> 00:12:34,530 being overwhelmed, it's a good idea 377 377 00:12:34,530 --> 00:12:36,490 to set up your virtual servers in the cloud 378 378 00:12:36,490 --> 00:12:39,720 with proper fail-over, redundancy and elasticity. 379 379 00:12:39,720 --> 00:12:41,200 By monitoring the network's performance 380 380 00:12:41,200 --> 00:12:42,840 and the physical service resources, 381 381 00:12:42,840 --> 00:12:44,040 you should be able to balance the load 382 382 00:12:44,040 --> 00:12:45,670 across several physical machines 383 383 00:12:45,670 --> 00:12:48,080 instead of relying on just one single machine. 384 384 00:12:48,080 --> 00:12:50,350 After all, elasticity and scalability 385 385 00:12:50,350 --> 00:12:51,690 are some of the main benefits 386 386 00:12:51,690 --> 00:12:53,640 of our moving to the cloud in the first place. 387 387 00:12:53,640 --> 00:12:56,070 So we might as well take advantage of them. 388 388 00:12:56,070 --> 00:12:57,680 Most cloud security is going to rely 389 389 00:12:57,680 --> 00:12:59,930 on the same security practices that you would perform 390 390 00:12:59,930 --> 00:13:01,260 for other servers and networks 391 391 00:13:01,260 --> 00:13:02,830 in your regular organization. 392 392 00:13:02,830 --> 00:13:05,030 Things like ensuring complex passwords are used, 393 393 00:13:05,030 --> 00:13:07,460 strong authentication mechanisms have to be in place 394 394 00:13:07,460 --> 00:13:09,060 and strong encryption being used to protect 395 395 00:13:09,060 --> 00:13:12,150 your data at rest, in transit or in process. 396 396 00:13:12,150 --> 00:13:13,410 Now your cloud environment 397 397 00:13:13,410 --> 00:13:15,390 should have strong policies in place to ensure 398 398 00:13:15,390 --> 00:13:17,570 that it is clear what things a user can do 399 399 00:13:17,570 --> 00:13:20,490 and what they can't do with that given cloud service. 400 400 00:13:20,490 --> 00:13:22,730 Remember, that data that you're hosting in the cloud 401 401 00:13:22,730 --> 00:13:25,010 is on somebody else's physical servers. 402 402 00:13:25,010 --> 00:13:26,740 If you're using a public cloud model, 403 403 00:13:26,740 --> 00:13:29,110 you also need to be concerned about that are remnants 404 404 00:13:29,110 --> 00:13:31,020 that could be left behind when a cloud server 405 405 00:13:31,020 --> 00:13:33,160 is de-provisioned after the demand for the service 406 406 00:13:33,160 --> 00:13:36,330 is reduced using our principles of elasticity. 407 407 00:13:36,330 --> 00:13:38,530 This occurs because when a service is scaled out 408 408 00:13:38,530 --> 00:13:39,960 using horizontal scaling, 409 409 00:13:39,960 --> 00:13:41,830 a new virtual instance is going to be created 410 410 00:13:41,830 --> 00:13:43,350 on a physical server. 411 411 00:13:43,350 --> 00:13:46,000 This new instance is going to take up some hard drive space 412 412 00:13:46,000 --> 00:13:48,950 on that physical server to represent the virtual hard disk, 413 413 00:13:48,950 --> 00:13:51,350 the operating system and all the associated configuration 414 414 00:13:51,350 --> 00:13:54,180 and data files for this new virtual instance. 415 415 00:13:54,180 --> 00:13:56,110 When this virtual server is no longer needed 416 416 00:13:56,110 --> 00:13:57,630 because the load has gone down, 417 417 00:13:57,630 --> 00:13:59,280 the virtual machine can be de-provisioned 418 418 00:13:59,280 --> 00:14:02,420 as we scale back in, and this means we're going to shut it down 419 419 00:14:02,420 --> 00:14:04,040 and the files are going to be deleted. 420 420 00:14:04,040 --> 00:14:05,150 Now, when this occurs, 421 421 00:14:05,150 --> 00:14:07,470 those confidential data files from the virtual machine 422 422 00:14:07,470 --> 00:14:10,220 are still left on the physical server's storage system. 423 423 00:14:10,220 --> 00:14:13,330 And these deleted files become known as data remnants. 424 424 00:14:13,330 --> 00:14:15,710 These data remnants could be recovered by an attacker 425 425 00:14:15,710 --> 00:14:17,080 and therefore it could breach 426 426 00:14:17,080 --> 00:14:19,210 the confidentiality of your data. 427 427 00:14:19,210 --> 00:14:21,090 For this reason, cloud infrastructures 428 428 00:14:21,090 --> 00:14:23,130 that rely on virtualization can introduce 429 429 00:14:23,130 --> 00:14:24,783 a data remnant vulnerability to your company 430 430 00:14:24,783 --> 00:14:27,590 because these physical servers are not being controlled 431 431 00:14:27,590 --> 00:14:29,700 by your organization and are instead controlled 432 432 00:14:29,700 --> 00:14:32,470 by the physical servers of the cloud organization. 433 433 00:14:32,470 --> 00:14:33,860 Now, our final security concern 434 434 00:14:33,860 --> 00:14:36,390 that you need to think about is a virtual machine escape 435 435 00:14:36,390 --> 00:14:38,530 because after all, these cloud-based servers 436 436 00:14:38,530 --> 00:14:40,430 all rely on virtualization. 437 437 00:14:40,430 --> 00:14:43,020 So what is a virtual machine escape? 438 438 00:14:43,020 --> 00:14:45,600 Well, a virtual machine escape or a VM escape 439 439 00:14:45,600 --> 00:14:46,850 is going to occur when an attacker 440 440 00:14:46,850 --> 00:14:48,020 is able to break out of one of these 441 441 00:14:48,020 --> 00:14:49,850 normally isolated virtual machines. 442 442 00:14:49,850 --> 00:14:51,810 And then they begin to interact directly 443 443 00:14:51,810 --> 00:14:53,760 with the underlying hypervisor. 444 444 00:14:53,760 --> 00:14:55,730 Now from this underlying hypervisor, 445 445 00:14:55,730 --> 00:14:57,220 the attacker can then migrate themselves 446 446 00:14:57,220 --> 00:14:59,536 out to one of the tenant servers 447 447 00:14:59,536 --> 00:15:01,510 and into another tenant server that is contained 448 448 00:15:02,547 --> 00:15:03,555 within another virtual machine 449 449 00:15:03,555 --> 00:15:04,490 hosted on the same vertical server. 450 450 00:15:04,490 --> 00:15:06,810 This allows them to jump from tenant to tenant. 451 451 00:15:06,810 --> 00:15:08,810 Now the good news is that VM escapes 452 452 00:15:08,810 --> 00:15:10,550 are extremely difficult to conduct 453 453 00:15:10,550 --> 00:15:12,820 because they rely on exploiting the physical resources 454 454 00:15:12,820 --> 00:15:14,469 that are shared 455 455 00:15:14,469 --> 00:15:15,560 between the different hosted virtual machines. 456 456 00:15:15,560 --> 00:15:17,160 But it is still a vulnerability 457 457 00:15:17,160 --> 00:15:18,710 that you need to be aware of. 458 458 00:15:18,710 --> 00:15:20,300 To mitigate this vulnerability, 459 459 00:15:20,300 --> 00:15:23,190 virtual servers should be hosted on the same physical server 460 460 00:15:23,190 --> 00:15:24,390 as the other virtual machines 461 461 00:15:24,390 --> 00:15:26,530 in the same network or network segment 462 462 00:15:26,530 --> 00:15:28,660 based upon their classification level. 463 463 00:15:28,660 --> 00:15:30,130 This way, if someone's able to escape 464 464 00:15:30,130 --> 00:15:31,260 out of the virtual machine, 465 465 00:15:31,260 --> 00:15:32,850 they can only access a similar type 466 466 00:15:32,850 --> 00:15:34,600 or classification of data. 467 467 00:15:34,600 --> 00:15:36,860 This works well if you're running your own private cloud, 468 468 00:15:36,860 --> 00:15:39,100 but if you're running on top of a public cloud, 469 469 00:15:39,100 --> 00:15:41,250 you really don't get to control which physical servers 470 470 00:15:41,250 --> 00:15:43,120 your virtual machines and cloud-based instances 471 471 00:15:43,120 --> 00:15:44,290 are being run on. 472 472 00:15:44,290 --> 00:15:45,970 For this reason, your organization 473 473 00:15:45,970 --> 00:15:48,130 needs to consider carefully what data it's going to allow 474 474 00:15:48,130 --> 00:15:49,210 to be stored in the cloud 475 475 00:15:49,210 --> 00:15:51,680 and what data they want to maintain full control over 476 476 00:15:51,680 --> 00:15:53,283 by using an on-premise solution.