Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fuck the Cloud (2009)

ascii.textfiles.com

Post reply on HN
Print view View original

101–110 of 235 posts

Re: Fuck the Cloud (2009)

#101

Post by pfortuny »

nsfyn55 wrote: 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…

The problem with the "once in "thousands of years"." argument is that you never know when that once happens and it may well be... tomorrow and never more in the next couple of thousands of years.

That is what happened (once again) to John Meriwether and Long-Term Capital Management... A "once every 10.000 years event" which took place... today.

Re: Fuck the Cloud (2009)

#102

Post by jacquesm »

Domenic_S wrote: post #84
jacquesm wrote: post #39

Earlier quoted context omitted.

Until your control panel gets hacked and you lose all your data. See: codespaces.com (assuming it wasn't an inside job or a dumb mistake, but even then the same rules apply). So no, DON'T BLOW ANYTHING INTO THE CLOUD THAT YOU DON'T HAVE A COPY OF. It has nothing to do with 'not invented here', it has everything to do with your inability to outsource your responsibilities. The degree to which people rely on others to…

The 3-2-1 rule is a rule for a reason. 3 copies 2 formats 1 copy off-site The cloud is a great place for that 1 off-site copy.

Assuming the rest of your data isn't in the cloud, yes. Otherwise reverse the situation. But you got it perfectly.

Re: Fuck the Cloud (2009)

#103

Post by erikpukinskis »

I understand why people are upset about the word. It's misused.

But I remember what it was like before "the cloud"... You had to provision machines one by one, often via email or phone. It took hours or days. Billing was usually done by the day. It sucked.

Now you can just send a POST request to a machine and in a few seconds you have access to a new instance. You can send 1000 requests and get access to 1000 instances. And then you can send some more requests and only get charged for a few minutes of time. When this transition happened, we called it "the cloud" because it's a big undifferentiated mass of computers. We could've called it "the soup" but we didn't.

That's what it has always meant to me. I don't understand why people want to eradicate the word just because it's misused. People misuse the word "internet" all the time, but I don't think we should strike it from our vocabulary.

Re: Fuck the Cloud (2009)

#104

Post by jacquesm »

nsfyn55 wrote: post #56
pjc50 wrote: 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…

Yeah but once again this problem is statistical in nature. Admittedly the cloud isn't perfect but the question remains. Does the "Counter Party" risk outweigh the chances that my home spun solution would fail? Since the likelihood of failure on my part is orders of magnitude higher then the "counter party" risk would have to be huge, like really enormous. e.g Amazon would constantly have to be on the brink of imminen…

The idea here, and you seem to miss this point entirely is that for your company to fail then both systems would have to fail simultaneously. That is why you have back-ups. Any one system can fail, but for two systems (both the original and the back-up) to fail catastrophically at the same time is statistically very unlikely, and with a back-up here I am just talking about a secondary system that just pulls the data in on a regular basis. Tarsnap or a simple script that stores the data in a set of directories, anything is better than nothing if you lose all your data. Rebuilding will still take time, but at least there is something to rebuild with.

For any one system to fail is perfectly possible and in fact should be expected to happen at some point and that's why you design against that.

You also make sure that it is not the same people that have access to both systems so that if your sysadmin walks onto the floor with a bad hairday your back-ups will still be there. And this is also why you test your back-ups to make sure they actually work.

Re: Fuck the Cloud (2009)

#105

Post by fixermark »

jacquesm wrote: post #94
fixermark wrote: post #63

Earlier quoted context omitted.

What's the relative risk that my specific control panel will get hacked and I, specifically, will lose all my data, vs. the risk that data on my local store will be compromised by a virus on my computer encrypting my whole hard drive and refusing to let go until I send XYZ bitcoins to a specific address? There's risks and then there's risks. As always, you can spend some time and money to mitigate some risk, and deci…

There's risks and there's bankruptcy. If you feel like gambling then be my guest. What's the risk of your house catching fire? Are you insured? What are the risks of getting burgled? Your car stolen, a car accident? Are you insured? What are the risks of having a bad health issue happen to you? Are you insured? I'll bet that you don't know the answers to any of those questions, and yet, you are probably insured again…

I see what you mean; I read "DON'T BLOW ANYTHING INTO THE CLOUD THAT YOU DON'T HAVE A COPY OF" and thought of only my personal data (because if it's user data, it's originating from the cloud and I'm not blowing it into the cloud; if anything, I'm pulling it out of the cloud).

Though if we unbox that a bit... How do we balance the risk of loss due to your cloud being owned vs. loss due to the risk of your users' PII being violated if someone attacks your in-house (ostensibly in-house reliability and security-managed) copies? Better make sure you're spending the money on security best-practices on all your copies, not just the "live" ones.

Side-note: What are your thoughts on two separate cloud providers as providing sufficient insurance? Say, having your data live in Google Cloud and at rest in Amazon S3?

Re: Fuck the Cloud (2009)

#106

Post by srean »

nsfyn55 wrote: 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…

> I don't understand this logic.

Curious if Upton Sinclair would have anything to do with it.

Lets put it this way, I know enough not to store data on the cloud(s) exclusively.

Re: Fuck the Cloud (2009)

#107

Post by nsfyn55 »

grayclhn wrote: post #98
nsfyn55 wrote: post #56

Earlier quoted context omitted.

Yeah but once again this problem is statistical in nature. Admittedly the cloud isn't perfect but the question remains. Does the "Counter Party" risk outweigh the chances that my home spun solution would fail? Since the likelihood of failure on my part is orders of magnitude higher then the "counter party" risk would have to be huge, like really enormous. e.g Amazon would constantly have to be on the brink of imminen…

Bank shutdowns are not orderly because banks are important; they're orderly because banks are heavily regulated. If Amazon has an orderly shutdown, it would be because of the selflessness of its owners and managers, which is a pretty fickle thing to bet on.

I certainly think this level of regulation is on the horizon given the number of businesses who use S3 as an authoritative repository. If Amazon needed to shutdown S3 even today I can see the government asserting a heavy hand in it.

Re: Fuck the Cloud (2009)

#108

Post by sneak »

ksk wrote: post #81

It's rather interesting that HN mods allow posts with this kind of language but the moment you are even mildly critical of a comment or commenter, you get a warning about language. I guess the thinking is we look the other way as long as its not hosted on the ycombinator domain.

What the fuck are you talking about?

Re: Fuck the Cloud (2009)

#109

Post by jellicle »

nsfyn55 wrote: 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…

Well, unless Amazon blocks your access to your account. Have you accounted for that in your failure rate calculations?

Ask Bernie Sanders about the cloud and the implications of losing access to it at the whim of the cloud provider.

Re: Fuck the Cloud (2009)

#110

Post by jacquesm »

fixermark wrote: post #105
jacquesm wrote: post #94

Earlier quoted context omitted.

There's risks and there's bankruptcy. If you feel like gambling then be my guest. What's the risk of your house catching fire? Are you insured? What are the risks of getting burgled? Your car stolen, a car accident? Are you insured? What are the risks of having a bad health issue happen to you? Are you insured? I'll bet that you don't know the answers to any of those questions, and yet, you are probably insured again…

I see what you mean; I read "DON'T BLOW ANYTHING INTO THE CLOUD THAT YOU DON'T HAVE A COPY OF" and thought of only my personal data (because if it's user data, it's originating from the cloud and I'm not blowing it into the cloud; if anything, I'm pulling it out of the cloud). Though if we unbox that a bit... How do we balance the risk of loss due to your cloud being owned vs. loss due to the risk of your users' PII…

That was Jason's use case that he had in mind, but for plenty of people the situation is the exact opposite but the principle remains.

Having two cloud providers would work assuming they don't share any critical infra-structure and assuming that it is not the same set of employees that have access to both systems. Also helps if you have a totally separate set of credentials for the back-up system and if that back-up system can only be unlocked by very senior people (preferably execs) after a catastrophe of suitable magnitude hits.

Whether you store your primary in the cloud or your back-up in the cloud the story is the same: have a copy somewhere else.

Finally: the only real back-up is one that is off-line. So from that (ok, ultra-paranoid) viewpoint it would be best if you actually went to an off-line medium to store your data in such a way that nobody can wipe it all out without physically destroying all copies.

All this of course after suitably weighing the importance of the data.

Post reply on HN