If we place too many restrictions on how companies should offer preview releases, they'll just stop entirely. Are you suggesting that even those comfortable taking on risk to get a sneak peak should be forced to wait for general availability?

Nobody is placing restrictions, but it's understandable if people are skeptical.

Praise be the skeptical! It allows the courageous easy advantages. SLAs are almost worthless. And, really, has Google ever retired something like this (i.e., not an acquisition, not Google Reader, etc)?

ReplyTo aros: The two main criteria I would have are: 1) not an acquisition and 2) important development/developer service. I can't think of any and didn't see any after a cursory look at the list.

I think SLAs are literally worthless since I don't think they encourage even slightly more effort in minimizing whatever issues the customer is concerned about. No one wants servers to go down, no one wants to shut down a service. That a few Google bucks might be on the line would have zero impact.

Easy there Ayn Rand.

If they lose your data, yes, that's one thing.

But if the 3 seconds becomes 6 seconds... Or the price goes up... Or they announce they're end-of-life'ing the product...

Just move your data somewhere else.

Sure, it'd be inconvenient (and maybe expensive) to move. So, you balance all of that out in your mind, and maybe this is the right service for you, and maybe it's not.

I'm not even sure it'd be "expensive to move". Are people _really_ considering using this (or Glacier/rsync.net/whatever) as their _only_ copy of their data? I can't imagine looking my boss/customers in the eye and saying "We're going to have multiple terabytes of mission critical business data, and it's all going to live _only_ on AWS/Google/Cloud-service-de-jour!"

If I lose my AWS Glacier stored data (or Amazon bump the prices intolerably), I'll upload it to a competitor _from my local copies_...

Admittedly, I've only had to deal with storage topping out in the tens of terabytes range, so I've never needed to go beyond a dozen or two consumer-grade drives to keep a pair of rsynced copies locally - but I think that same kind of techniques scale all the way out to building your own Backblaze style storage pod if needed.

In a word: yes.

You're thinking about data that can't be lost, or your customers are screwed. Not all data is like that.

Log files come to mind. They're _nice_ to archive for a long time, but in many businesses, they're certainly not _critical_ to archive for a long time.

Intermediate files, too. You retain the original files in secured storage. But because the intermediate files are large and expensive to re-create, you keep them here in AWS.

think of the poor poor companies!

In beta, your build the tools to use the service with your data, but don't use it for mission critical data until you have an SLA, etc., that you are comfortable with for that purpose.

And if you aren't comfortable even investing development efforts against a beta, don't. Different customers have different risk tolerances, and the fact that an early access product doesn't meet yours doesn't mean it shouldn't be available for those whose risk tolerances it is suitable for.

> But my valuable data?

Surely the whole point of not having an SLA (and indeed the whole point of calling it a "beta") is so that you don't trust it with your valuable data. I'm sure it will have an SLA soon enough.

I don't have a whole lot of worthless data.

I do. It's called test data. I use it when I develop tools to interact with a service before it reaches maturity and before it get an SLA.

Once it has an SLA, I can use my tool to work with valuable data.

Then it sounds like you should wait for the proper release, as this beta test is not for you.

Do you have data you would like to have an extra copy of, but it wouldn't kill you to lose that single copy?

It seems like this is why they have the clause that you quoted. They aren't yet comfortable guaranteeing reliability or backwards compatibility (i.e. what "beta" means). If these things are crucially important to you, there's a pretty good chance you shouldn't be using it for your "valuable data".

It seems most useful as a place for redundant, encrypted backup. You don't really need it to be reliable (or safe) to store an encrypted online version of ~500gb of family photos that you have on an external hard disk.

You just want cheap and fast.

It's probably something that could be deployed in the "nice to have" category: use it as a cache for your offline data to provide quick recovery of things you would previously have needed to go all the way to offline to retrieve. But if something goes wrong, you still have the offline data to recover from.

You shouldn't be trusting your production data to anything in beta. The whole point of open beta testing is to pool the technical risk. So use it, but don't rely on it. If you can't afford to use it in parallel with some existing system, then don't use it.

If your data really is that valuable, any compensation promised by an SLA is likely to be meaningless.

Far better to use multiple redundant solutions, and although Nearline is only beta* it offers us an easy and cheap way to increase storage diversity.

*How long did we all rely on Gmail while it was beta?

No. Also, you shouldn't believe in ANY single backup solution.

Don't place all your eggs in the same basket.