Consider three scenarios from the buyer’s perspective:

1 – I need more storage, but can’t get the CAPEX+OPEX approval to buy and provision the next big chunk of storage that would carry us through 1-3 years of projected requirements.

So I store all new data in the cloud using incremental OPEX. Some users complain that off-site storage is too slow.

Eventually, my OPEX and user complaints climb to the point that I can get CAPEX+OPEX approval to buy and provision the next big chunk of storage. Lather, rinse, repeat.

In this scenario, the incremental price I’m willing to pay for another terabyte in the cloud will be much higher than my marginal purchase/provision cost. I need that extra terabyte *now*, not when I can get multiple approvals for data center expansion, server purchase, sys admin hires, …

2 – We want to acquire a 300 TB data set that will ultimately be reduced to a few TB. Once we’re done, we don’t need the original 300 TB data set any more. Cloud storage and computing would be ideal for this project. I avoid large investments in server capacity, data center buildout, etc. I’m happy to pay much more than my marginal purchase/provision cost for this short-term project.

3 – My formerly very obscure web site gets a sudden spike in interest (see Indian Ocean Tsunami, see “slashdotted”). I move my most popular content to a quickly provisioned CDN/S3 site, and my users are happy. I deprovision quickly after the spike subsides, and my web site sinks back into well-deserved obscurity. I avoid large investments in rarely used network bandwidth, server capacity, etc. I’m happy to pay much more than my marginal purchase/provision cost for this temporary service. Here’s a good paper on using the cloud (“utility computing”) for just this scenario: http://research.microsoft.com/~howell/papers/flashcrowds-camera-ready.pdf

Seems like you could build a pretty good business model around these scenarios (and others), even if your marginal cost is 10%-20% higher than mine.

For Wes Felter: I’m quite confident PUE in this Microsoft experiment was below 1.1: http://blogs.msdn.com/the_power_of_software/archive/2008/09/19/intense-computing-or-in-tents-computing.aspx

Availablity? Flexibility? Security? Customer ease-of-use?

In addition, a big selling point is the ability to grow capacity. A small operator faces hard-to-predict growth, and often has to grow in painful increments on short notice (which is expensive). A large aggregator smooths out variation, so can plan and grow. Finally, there’s the whole tradeoff between capital and operating expense.

Put these together and, yes, it’s hard to see an advantage for the top end guys, who can afford to build at a scale comparable to cloud providers. But for smaller guys below that level, and especially for new guys who are growing rapidly (or hope to), there’s an advantage. (There’s a particular advantage, perhaps, to an in-the-cloud service that provides 100% compatibility with an in-the-datacenter box. Then when I’m small, I can go to the cloud; transition cleanly to my own hardware when it makes sense; and perhaps even use the cloud later if I’ve planned badly and need to tide myself over while expanding in-house.)

As for special services in the cloud: Absolutely, though you have to answer the same questions about scaling. But there’s a fairly obvious such service that’s already out there, namely computing in the cloud: Amazon’s EC2 tied to their S3. Good connectivity between computational and storage resources is obviously important for many classes of application. Any other special services will have to run in “EC2″. But, even without those special services, computational resources currently have the property that I need to pay for my peak usage, even if my average is way below that. Over the years, there have been a number of attempts to attack this – remember IBM’s “speed dial” on leased machines? But large shared computational resources are potentially the first really effective answer. There’s some report around that a typical Google query involves 1000 CPU’s. For Google, that’s part of average usage; as we figure out how the Google style of computing can be applied to other kinds of problems, most users will probably find they need 1,000 CPU’s – but for only a hour a day, perhaps. Putting that kind of thing out on an EC2-like service may prove very attractive. (BTW, in principle, the same argument might apply to storage – but at least right now, all the big storage applications I know of keep stuff around indefinitely. Usage isn’t spiky – it just grows.)

Anyway you can negotiate pretty good prices from storage vendors if you’re buying a PB every other month is one answer. Homogeneity is another.

A large, homogeneous storage operation requires quite a lot less in terms of labor. We have a site that adds one PB every other month to its ops, and it only has ONE on site storage engineer. Part of the key to that is that is the software that manages it all, of course.

C//

Nik, agree, comodity HW in general cuts capex.

Tony, does the technology exist that auto-magically adds capacity for people who need it and removes it from people who aren’t using it? The portfolio effect argument is appealing, but it depends on the granularity and reaction time of the infrastructure to shifts in demand.

James, sounds like a variety of the “edge-centric network.” I like the concept, but how do you get end users to offer up their unused capacity?

Robin

I agree. We are currently testing Wuala at Storage Monkeys to determine just what the value is. Wuala is a new peer-to-peer online storage that allows you to share and use the storage you make available online. When you boil it down, Wuala is just capacity with a clever way of aggregating storage resources. It is clearly consumer-grade storage for now. In my opinion, cloud storage is going to have a tough time making it in the enterprise which is why I am very curious to hear what EMC’s plans are with Maui.

-James Orlean
http://www.StorageMonkeys.com/

Overall, I think the key push comes back to savings in IT people’s time. One key Google advantage is they are able to run their server farms with far fewer admins than anybody else. Same goes non-storage cloud apps – a lot of their allure is: 1)Access anywhere and 2)Very low administrative costs (compared to keeping a bunch of Windows PC’s happily running up to date).

Overall, however, I’m a bit of a cloud skeptic – there are a lot of potential problems the hypesters haven’t thought through.