Live data from Hacker News

Fuck the Cloud (2009)

ascii.textfiles.com

121–130 of 235 posts

Re: Fuck the Cloud (2009)

#121
post #34

>Don’t blow anything into the Cloud that you don’t have a personal copy of. I don't understand this logic. Amazon's S3 offers service level agreements with failure rates that at one point implied the statistical likelihood of losing an object to be once in "thousands of years". When dealing with any sort of stable storage this is simply something I cannot offer. I couldn't produce a set up locally with the resources…

"TL;DR I hear this argument all the time. The cloud isn't perfect but its a hell of a lot closer to anything I could achieve. "not invented here" syndrome won't save your data."

I think there is an easy rebuttal that should be considered...

First, the "nines" rating of any service or resiliency is just gibberish. Go find the statistical likelihood of money market funds "breaking the buck" or of CDS blowing up - both in 2007/2008. Those had a lot of nines too and a lot of very smart , well qualified people attesting to those nines (in venues even more serious than IT).

A highly complex system becomes incomprehensible, even to the people that built it. Those nines mean nothing.

Second, you absolutely can build something more stable and predictable than Amazon precisely because you're the one that built it - which means that it is more comprehensible and fails more predictably and gracefully.

I don't care who does the calculation and how many nines they come up with - if you load FreeBSD on two bare metal servers and put them in two different datacenters and run them with any kind of conservative and cautious sysadminning you'll have a better solution. Yes, it will be more expensive.[1][2]

The standard closure to a comment like this is to refer to Talebs Black Swan and Antifragile books ... which you certainly should read ... but even more important is "Normal Accidents" by Charles Perrow[3] which I hope will convince you to stop looking for complex things that never fail, and instead look for simple things that fail gracefully.

[1] ... but we have a HN-Readers discount - just ask!

[2] You know who we are.

[3] https://en.wikipedia.org/wiki/Normal_Accidents

Re: Fuck the Cloud (2009)

#122
post #71

Earlier quoted context omitted.

He's saying that the article does not apply for S3 and other paid services.

Yeah I guess I can see that. But then again I would never give important data to a 3rd party without some sort of contractual arrangement.

How will a contract save your ass if your data is lost? You can't outsource your responsibility.

Re: Fuck the Cloud (2009)

#123
post #43

Earlier quoted context omitted.

S3 seems great today, and is undoubtedly more technically reliable than any home solution, but history is littered with companies that closed down on very short notice leaving their users' data deleted or inaccessible. Not to mention that billing disputes or legal action could also affect your ability to get data from them. (Jason Scott is speaking from experience here, as one of the people called in to do emergency…

> history is littered with companies that closed down on very short notice leaving their users' data deleted or inaccessible That's absurdly unlikely to happen with S3.

"That's absurdly unlikely to happen with S3."

How absurd was it that money market funds would fall below $1 during the recent unpleasantness ? It was so unthinkable that major parts of our entire global economy were predicated upon it never happening.

It happened.

Money markets are even more "serious business" than Amazon, or even all of tech is, and had even more big brains attesting to their inability to fail. They failed.

Re: Fuck the Cloud (2009)

#124

There is no alternative approach presented here. I can only assume that the author has never had to scale a piece of software to server hundreds of thousands of concurrent users.

The implied alternative is "something you run, control, buy, administrate, and understand." Don't overthink this. You need it to scale to one (1) concurrent user.

Go buy an external hard drive. Start saving important things locally, and also automate backups to the external drive. You now have two copies of everything you can't afford to lose.

Re: Fuck the Cloud (2009)

#125

Earlier quoted context omitted.

I was just talking to my pals at Digital Equipment Corporation and Sun Microsystems about how stable the technology industry is. Then, I read an article in Google Reader discussing how we don't even have to worry about arbitrary and capricious market behavior from our cloud partners, since we all have long term contracts and are protected against upward price swings from our cloud partners or material changes to the…

I see the sarc tag, but if you had a long-term contract with Reader it'd probably have been a different story.

Maybe. When you subscribe to Google Apps, you get access to applications that aren't necessarily part of your SLA.

The point isn't that these services are bad. Just that you need to be strategic about how you use them.

Re: Fuck the Cloud (2009)

#126
post #121
post #34

>Don’t blow anything into the Cloud that you don’t have a personal copy of. I don't understand this logic. Amazon's S3 offers service level agreements with failure rates that at one point implied the statistical likelihood of losing an object to be once in "thousands of years". When dealing with any sort of stable storage this is simply something I cannot offer. I couldn't produce a set up locally with the resources…

"TL;DR I hear this argument all the time. The cloud isn't perfect but its a hell of a lot closer to anything I could achieve. "not invented here" syndrome won't save your data." I think there is an easy rebuttal that should be considered... First, the "nines" rating of any service or resiliency is just gibberish. Go find the statistical likelihood of money market funds "breaking the buck" or of CDS blowing up - both…

>Second, you absolutely can build something more stable and predictable than Amazon precisely because you're the one that built it - which means that it is more comprehensible and fails more predictably and gracefully.

This is from you and this is from the wikipedia article on NIH(not invented here) syndrome ...

>Not invented here (NIH) is the philosophical principle of not using third party solutions to a problem because of their external origins. False pride often drives an enterprise to use less-than-perfect invention in order to save face by ignoring, boycotting, or otherwise refusing to use or incorporate obviously superior solutions by others.

I am not saying don't have a copy, I am saying the if you have several copies the safe one is in the cloud.

Re: Fuck the Cloud (2009)

#127

Earlier quoted context omitted.

Read this and then consider if you ever want to write something like it. https://www.facebook.com/orainwikihosting/

Once again. I only entertain statistical arguments. This anecdotal nonsense is for the birds. Any given service can fail at any time. This is known kaleesi. You can poop out case after case of some shit wiki platform losing your bird watching posts and it won't make a lick of difference. You need to show me that its better with the magic of statistics. Should be easy peasy show me that you have lost less data(proport…

I really hope you have the guts to point clear-switch.com customers and prospects to this thread and that you will take their response to heart. Really, you're absolutely incredible, I've yet to see a person responsible for other people's data with such a block-headed attitude to hard won industry experience.

Re: Fuck the Cloud (2009)

#128
post #34

>Don’t blow anything into the Cloud that you don’t have a personal copy of. I don't understand this logic. Amazon's S3 offers service level agreements with failure rates that at one point implied the statistical likelihood of losing an object to be once in "thousands of years". When dealing with any sort of stable storage this is simply something I cannot offer. I couldn't produce a set up locally with the resources…

What if you make a mistake a manually delete something in the cloud? What if a program has a bug in it and something gets deleted? If your data is precious, you need multiple copies of it, no matter where they live.

Re: Fuck the Cloud (2009)

#129

Earlier quoted context omitted.

Do you keep your money in a shoe box under your bed or stuffed in your mattress? I'd hope no, but then that begs the question "where do you keep it?" I'd assume not in a bank because any bank can fail at any moment and they are only insured by an instutition as flaky at the United States Treasury department. Governments collapse all the time just ask the Soviet Union. Right? The failure probabilities are relative. An…

I keep my money spread out across multiple accounts with multiple banks up to the insured limit. Because yes, banks can fail. > You indicate that storing customer data in the cloud is "playing fast and loose" but I'd argue the opposite. Not having a cloud backup is what is "fast and loose" Basic reading comprehension failure, that is not what GP is arguing. He's arguing that if your live data lives in the cloud your…

>I keep my money spread out across multiple accounts with multiple banks up to the insured limit.

Insured by who? Not governments. Governments collapse all the time. The only safe place to keep it is in your own custom bank at home that you built yourself.

Re: Fuck the Cloud (2009)

#130
post #86

Earlier quoted context omitted.

Maybe ask the people of Greece if they "trust the banks". Shit happens, a local copy of your stuff does no harm at all in the same way as some cash on the hip is cool in case your card stops working.

Do you keep your money in a shoe box under your bed or stuffed in your mattress? I'd hope no, but then that begs the question "where do you keep it?" I'd assume not in a bank because any bank can fail at any moment and they are only insured by an instutition as flaky at the United States Treasury department. Governments collapse all the time just ask the Soviet Union. Right? The failure probabilities are relative. An…

I'd assume not in a bank because any bank can fail at any moment and they are only insured by an instutition as flaky at the United States Treasury department. Governments collapse all the time just ask the Soviet Union. Right?

If you bank fails, you will be made whole with money from the FDIC. Money is fungible. Any money will do.

Data is not similarly fungible. There's no IT FDIC to replace your lost data with other data that's identical.

Post reply on HN