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