Slashdot Mirror
Why Corporate Cloud Storage Doesn't Add Up
snydeq writes "Deep End's Paul Venezia sees few business IT situations that could make good use of full cloud storage services, outside of startups. 'As IT continues in a zigzag path of figuring out what to do with this "cloud" stuff, it seems that some companies are getting ahead of themselves. In particular, the concept of outsourcing storage to a cloud provider puzzles me. I can see some benefits in other cloud services (though I still find the trust aspect difficult to reconcile), but full-on cloud storage offerings don't make sense outside of some rare circumstances.'"
I work for a printing company... cloud storage companies call us all the time with the pitches. Then they ask .. "how much data are you currently backing up?" .. we say "around 38 terabyte's" .. they say .. "no .. we aren't asking what your archives are, we are asking what your daily backups are." we say "we back up once a week. our weekly backups are around 38 terabytes." Then they say "that is a little more than we can handle" so I ask "well what can you handle?" almost every one of them has said they generally look for companies that have between 500GB and 1TB of storage. I guess if you fit that spec, it would work.
I just came from a very large banking organization, and their business case for cloud is to set up a series of private cloud servers. It's not about putting everything on Amazon etc, but rather about putting the services into their own datacentres.
They will literaly save hundreds of millions in hardware and power bills, as they can consolidate tons of servers together. The reason? Most boxes that they current have, utilize 1% of network traffic, less than 1% of CPU, and about 10% of hard disk space. Why? Because every project has their own boxes for political reasons, for redundancy, and most importantly, so that when they saved $10,000/year on hardware, they didn't lose $1,000,000 because the service was unavailable for half a day.
Because private cloud means that you have an instant sandbox for your apps, over a number of servers that the app can freely be moved to, this is the driver behind adoption of the model.
Public cloud is laughable to them, as the public cloud providers can pry their data from the company's cold dead hands.
Not to mention the wonderful PR side effect of the company being "green".
Science advances one funeral at a time- Max Planck
Why don't people look in the history books of computing. If they did they would see that in the before the 80's everything was in "the cloud", except back then they called it servers. They rented these servers and the storage space from IBM, Digital, HP and a few other server providers. The personal computer came a long and data started shifting on to local hard drives and WIntel or Novell LAN servers.
Now they have the problem of trying to maintain every spreadsheet and Access DB sitting on a managers laptop. To solve this they are going back to the future and storing stuff back on servers sold to us by young people who never knew what DASD is. Controls and audits will demand restricted access and rules be put in the cloud for protection just like before. After about 10 years we will all be bitching and complaining about the cloud and praising local storage for it's ease of access and not having our data held hostage by providers. Lather, rinse, repeat.
There is nothing new under the sun people, just move along.
The problem is that file storage is so dad-gum expensive these days. 15cents a gb at Amazon makes it $150 per month for a terabyte of storage. You're better off buying the 1TB drives yourself and rotating it to an employee's house every night. Sure there are some cheaper alternatives (nimbus.io) but even at 6cents a GB with Nimbus, you're still better off buying the external drives yourself.
Right - and when you can integrate your SAP Cloud ERP system, your SalesForce.com CRM system, your Workday HRIS, *and* the data from your 500 retail locations that you poll daily, all within your Netezza AppNexus data warehouse to generate dashboards using your MicroStrategy MCDWS BI system, without your IT department, you let us know...
For me the one attractive use case for cloud storage is for backups - and it's one that's catered to particularly poorly by current offerings.
For backups, you want (a) fast, unmetered links to the host and (b) moderately reliable, cheap, and not-that-fast storage you can access in a variety of different ways depending on what's most convenient, with or without running your own VPS to mediate between storage and storage clients.
One user will want to rsync to their cloud storage. One will want to remote-mount a file system on it via iSCSI. Another will want to run a Bacula storage daemon on it. Yet another will want to use it as a co-ordinator for a full network backup system. All these use cases should really be supported, and the first two shouldn't need the customer to maintain their own VPS to control the storage.
As things stand, almost everyone wants to sell SAN-based high performance storage that's *expensive* and *fast*, not cheap and slow. Most backup services seem to want you to use their tools or a local appliance to talk to their storage. Half of them act very confused when you mention "Linux" or "UNIX" and ask if that's a new kind of Mac or something. At least in Australia I've found the market miserably unsatisfying so far.
What I'd really like is for ISPs to begin offering, or partnering with others to offer via peering, bulk near-line storage at moderately affordable rates. That way you can talk to it over your business's main ADSL/SHDSL/fibre/whatever link(s) without dealing with quotas, it's fast, there are multiple routes to it, and it's unlikely to go down if an international link has a hiccup.
iiNet's cloud offering looked like it might have potential for this, but it turns out to be just another EC2-wannabe crossed with Linode-done-badly-and-expensively. The storage offerings are miserable and they don't even mention whether traffic between iiNet internet services and their cloud is metered
I have the same issue. I work for a small suburban newspaper, and even our hot data set is over 1TB, plus append-only archival data of more than 4TB.
When I tell these "cloud backup" providers this they do a double-take and then start talking laughably high prices or they just back off and say they can't really handle our archival data set. It's quite pathetic when my 10TB backup storage server in a fire-resistant, water-resistant enclosure in the shed cost under $5k when built - and that was when 10x1TB disks was a lot so the disks cost over $2500 by themselves.
Because I'm in Australia I also have the issue of bandwidth. I'd need a backup provider to peer with my ISP via a local peering point that offers unmetered traffic; with 100GB/month limits considered very big here I couldn't possibly back up over a metered link. Even then, my redundant two ADSL2+ links achive about 6Mbit/750kbit and 4Mbit/500kbit per second each, so I'd probably need to pay to run fibre from the nearest line along the train line (est $50,000) and pay over $1000/month for a fibre service just to talk to the backup storage host.
I'm negotiating to move our backup server to a business down the street and run an 802.11n point-to-point directional link between us instead. We each get to fail over to each others' Internet services if necessary, we exchange backup storage, and neither of us gets to pay through the nose for it. It's not as good as a fast link to a DC somewhere, but it's a hell of a lot more practical.
The other issue with cloud backups arises when you need that 5TB (mine) or 38TB (yours) in a hurry, for disaster recovery. You can't exactly run down the street and grab the server with its disk array then restore over 1Gbit ethernet or direct to locally attached SAS/eSATA/whatever. Nope, you have to download all that data over whatever Internet link you have access to. If that's not the dedicated fast link your premises has (say, if they've burned down) then you are screwed.
I'll keep my primary backups within driving distance, thanks.