Cloud Computing (Marketing Term)

Utility computing - we want to share computing capability, like power , water - most cost efficient

For a computation, we want to work in low power mode - we want to quickly shut down when the system is not in use, but power up quickly when we need it with a low power cost. For powering on, we want to stay away from rotating disk for cost efficiency, so we instead use flash drive to cache to reboot / power on.

Effect on OS design

Let's say there are a lot of VMs, which ease configuration, and client(typically multicore VM running Java VM or javascript apps) access to just a few of the servers in the cloud, which are called edge servers.

Is there a opportunity for a Cloud O.S? big O.S is messy.

Marketing at cloud computing

Short term commitment

As-needed payment

Can grow capabilities as needed 'instantly'. For example, when there is unknown demand for a startup for example there is Super bowl, they can always increase the server.

Administrative nightmare about cloud computing!

Issues

• Technical details: get VMs to work efficiently


• Who pay? (how is resource usage account for)


• Who controls / administrators?


• Security


• Resource management.

More Issues

• software licensing - can be a big implement for commercial software (e.g. charge per core)


• license trap - turns into a commitment


• Who controls / administrators?

Data confidentiality

• "do you trust your cloud vendor to keep your secrets?"

UCLA hospital has a lot of patient records. The database has a low level pixels containing patient's face, and primary relevant stuff.

Will this work? No, there is face recognition, so if we hack into the server and do face recognition, we will be able to detect who's patient record this is.

So we encrypt the data in the cloud (clouds see only encrypted data), then computations on your machine - then this loses benefit of cloud computing.

Data transfer bottleneck

node at UCLA ------> 1GB of data -----> node at USC

Big problem, Sneakernet is sometimes faster.

More Issues

Suppose your cloud server provider is busy.

• multiple suppliers (increase complexity)


• even so! global meltdown still possible (DDOS)

access overload is usually the biggest problem

Debugging cloud application

• Important bugs often happen only as you scale up


• How to test/debug large application in which many bugs are in race conditions?


• Conservatism in deployment

Debugging cloud application

• Important bugs often happen only as you scale up


• How to test/debug large application in which many bugs are in race conditions?


• Conservatism in deployment

CAP theorem

• Consistency - client sees a single consistent stat


• Availability - data/apps are always up


• Partition tolerance - work can be done even when the cloud is partitioned

Practical consequences of CAP

partition can get full

tiny partitions are more common

• (just client) - "disconnected mode" run off browser of dominant


• (just one edge server) - often connection is overloaded , not down


• latency issue often predominate

A common decisions when things seem slow (reg, no response)

• 1. retry (send request again) - after a timeout


• 2. cancel operation (give up)


• 3. proceed with the operation => create a partition

We want setup where during a partition, can't cause trouble.

One way is, during a partition, do only commutative operations

P1: A, B, C

P2: M, N, P, Q

===> A, M, N, B, P, C, Q