UC Berkeley Lab Examines Cloud Computing Obstacles

alphadogg writes "UC Berkeley researchers have outlined their view of cloud computing, which they say has great opportunity to exploit unprecedented IT resources if vendors can overcome a litany of obstacles. 'We argue that the construction and operation of extremely large-scale, commodity-computer data centers at low-cost locations was the key necessary enabler of Cloud Computing,' The paper outlines 10 obstacles to cloud computing [PDF]."

Comments

Vaporware Alert

[Spazztastic]

Do you trust your data being up in the "cloud"? Do you want to risk that company tanking and your work going away? I don't. I can work fine over a IPSec link to my storage server (with more redundancy) and run subversion to keep track of my work.

Re:Vaporware Alert

[morgan_greywolf]

Do you trust your data being up in the "cloud"?

Why not? Is it any worse than trusting your data being in the datacenter? As long as you have good backups and a good disaster recovery plan, who cares where your data sits? As long as the company whose servers the data is sitting on have appropriate SLAs that say how the data and access to the data will be protected and to what extent, how, etc., is that any different from the SLA you have with your IT department?

top-10 list: Anonymous so I'm not Karma whoring

[Anonymous Coward]

Table 1: Quick Preview of Top 10 Obstacles to and Opportunities for Growth of Cloud Computing.
Obstacle Opportunity
1 Availability of Service Use Multiple Cloud Providers; Use Elasticity to Prevent DDOS
2 Data Lock-In Standardize APIs; Compatible SW to enable Surge Computing
3 Data Confidentiality and Auditability Deploy Encryption, VLANs, Firewalls; Geographical Data Storage
4 Data Transfer Bottlenecks FedExing Disks; Data Backup/Archival; Higher BW Switches
5 Performance Unpredictability Improved VM Support; Flash Memory; Gang Schedule VMs
6 Scalable Storage Invent Scalable Store
7 Bugs in Large Distributed Systems Invent Debugger that relies on Distributed VMs
8 Scaling Quickly Invent Auto-Scaler that relies on ML; Snapshots for Conservation
9 Reputation Fate Sharing Offer reputation-guarding services like those for email
10 Software Licensing Pay-for-use licenses; Bulk use sales

ironic: my captcha is "retyping"

They forgot operational transparency

[psydeshow]

The list:

1 Availability of Service
2 Data Lock-In
3 Data Conïdentiality and Auditability
4 Data Transfer Bottlenecks
5 Performance Unpredictability
6 Scalable Storage
7 Bugs in Large Distributed Systems
8 Scaling Quickly
9 Reputation Fate Sharing
10 Software Licensing

I'm surprised they don't mention my biggest pet peeve with cloud services: lack of operational transparency. You don't know who the admins are, what their policies are, and what code they are using to operate the system.

It's a big black box and you're just supposed to trust that Amazon (or whoever) has sound policies, peer-reviewed code, and a reasonable level of accountability built-in. That's a bit like trusting your bank to only make good loans.

I actually want to know who the admins are. I want to see the code. I want to read the policies. Is that so wrong?

Re:RTFA

[brian_tanner]

"Moreover, companies with large batch-oriented tasks can get results as quickly as their programs can scale, since using 1000 servers for one hour costs no more than using one server for 1000 hours." Is that a given? Is it that simple? I think that statement assumes too much... As an example, it assumes all servers are operating on the same grid, in the same environment. Last time I checked, the cloud was the epitome of vagary.

Nonsense! I'm starting to get tired of all this "last time I checked" bullshit. You NEVER checked. My aggression is not leveled at you necessarily, but at all of the Slashdot posters who bring up the same arguments every time there is a cloud computing story.

The truth is, Amazon's offering (for EXAMPLE), lets you start up multiple virtual machine instances, and you pay per minute per instance. Lots of (NOT ALL) academic and industrial research relies on running many independent experiments. Let's try algorithm X with parameter set [1...100]. If each parameter set takes an hour, then you can either invest 100 hours on 1 machine, or 1 hour on a 100 machines. Aside from a tiny bit of overhead to create scripts to start the virtual instances and upload the jobs, this works exactly as advertised. It is great for some of us, and it's that simple.

Okay, it's a buzzword

[CopaceticOpus]

Every time a story mentions the "cloud", we get to enjoy many complaints about the use of this buzzword. I think it's time to accept it. It is a useful term, describing a trend which is only going to grow over time. Having a concise way to refer to it will be convenient, regardless of what you think of the trend.

When people started talking about the "web", did you complain about this buzzword too? After all, it's nothing but a system of interlinked hypertext documents accessed via the Internet. Why not just say that every time?

I love watching people reinvent the Mainframe!

[DutchUncle]

Once upon a time, when I started working with computers, you had a very dumb terminal connected to a remote computer. For lots of years the objective was to bring more intelligence closer to the user; editing terminals led to local storage. At the point where we could have individual computers all to ourselves, anyone acknowledging the splintering effect - the fact that you couldn't add back the cycles and memory to make one big computer - was mocked as a throwback to the outdated mainframe days. Same for anyone pointing out the problems with backup and maintenance. After all, why would you want to leave your work under the thumb of the people in the glass house when you can have your very own personal computer?

Since then we've been trying to find the best way to split the load between local and remote intelligence, distributing processing across communications, whether it's for business applications or multiplayer games. And most important, we have found that one solution does not fit all problems. Sometimes distributed knowledge addresses the problem or enables a brand new activity (like the multiplayer games); sometimes close direct access offers the most speed or best function (like Google's massive data centers).

So now, after we can put multi-gigahertz multi-core processors and gigabytes of RAM and terabytes of storage at the disposal of each individual, people are reinventing the remote mainframe. Call it a server, call it a cloud, whatever.

It is to laugh.

Those who will not learn from history are doomed to rediscover lots of things at their own cost.