Fuck the Cloud (2009) • Hacker News Board

Re: Fuck the Cloud (2009)

#231

Post by omarchowdhury » Wed, Dec 23, 2015, 8:55 AM UTC

nsfyn55 wrote: post #129

jacquesm wrote: post #117

Earlier quoted context omitted.

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.

And that money is worthless if the issuing government collapses. There is no ultimate security.

Re: Fuck the Cloud (2009)

#232

Post by ajross » Wed, Dec 23, 2015, 4:44 PM UTC

jacquesm wrote: post #172

ajross wrote: post #167

Earlier quoted context omitted.

No argument at all about the last sentence, but you should have skipped the first four lines as wildly premature optimization. The vast majority of the world would be much better served by (to appropriate your jargon) a 2-1-1 rule, because it's a straightforward treatment for a straightforward problem that is easily implemented. Yes, "format skew" and double-failure of backup solutions does indeed happen, but at a mu…

I think the 'three copies' rule refers to cyclic backups, not necessarily three copies of the one piece of data. This protects against data corruption that is not detected immediately. Another common way of doing this (and one that I prefer) is one where you rotate out a backup medium with ever larger intervals. So one gets set aside per week, then one gets set aside per month and so on. That gives you a series of sn…

Oh sure, there's lots to say about the design and effective use of a backup regime. I agree with all that stuff.

But if you're going to condense it to a "rule" that will help people not well-versed in the field, that rule can only be "MAKE BACKUPS!", because at least 90% of the data loss scenarios in the real world happen because simple backups weren't made.

Don't make it more complicated than it is, because someone will stop to do it "right" and then lose data because they didn't just make a copy on a USB stick.

Re: Fuck the Cloud (2009)

#233

Post by ixtli » Wed, Dec 23, 2015, 5:11 PM UTC

AnimalMuppet wrote: post #230

ixtli wrote: post #228

Earlier quoted context omitted.

I'm not sure how this is relevant to what I said. While it is certainly the case that one can catch more flies with honey, I think we'd all rather be people who digest the message instead of disregarding it because we don't like how it was delivered to us. This isn't about textfile's delivery, but that it's useless bordering on childish to take a response from an author and respond simply with "I don't like your tone…

> I think we'd all rather be people who digest the message instead of disregarding it because we don't like how it was delivered to us. That would be good, yes. We should all try to be like that. However, HN has guidelines as well, and I'm pretty sure that textfile's post violated some of them. And the way HN maintains it's status as the kind of place where we care about the message is partly by discouraging statemen…

Please correct me if I'm wrong, but the guidelines only seem to state:

> Be civil. Don't say things you wouldn't say in a face-to-face conversation. Avoid gratuitous negativity.

I guess this is the point where we'd be arguing about taste, but it seems to me that while textfile's comment was clearly negative, it was well constructed and well thought out. Not to mention it was in the _exact_ same tone as the article he'd written years ago that the conversation was about. In this case we should be very careful not to immediately jump on people being upset or negative. It's a powerful tool that, in this case, is being used wisely. I think a bruised sensibility here and there is a worthwhile risk in the name of maintaining a network like HN that accepts dissent and spirited disagreement.

As a slight tangent, in reading the guidelines I found that more than an attempt to tone-police, they are an attempt to lower the noise:signal ratio. The reason I feel that this discussion is important is because it's the reply, not textfile's response, that adds noise to the discussion even if you feel targeted by the authors response.

Re: Fuck the Cloud (2009)

#234

Post by erikpukinskis » Wed, Dec 23, 2015, 6:48 PM UTC

whichfawkes wrote: post #185

erikpukinskis wrote: post #103

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 instanc…

Agreed. When I read the title, I was thinking "Oh, so you'd prefer to pay for dedicated servers? What a pain!". Though, I don't think the author is upset about the word . He's just warning against services that fall within his definition of "cloud" - which is pretty fair. Losing your stuff is no good, and there's always cruddy services out there.

Yeah, I guess you're right. Weirdly he's not talking about the cloud at all, he's just talking about storing things on someone else's servers. So I guess he's one of those people misusing the word cloud.

Re: Fuck the Cloud (2009)

#235

Post by iofj » Fri, Dec 25, 2015, 5:59 AM UTC

BookmarkSaver wrote: post #227

iofj wrote: post #222

Earlier quoted context omitted.

I think the original point I made stands. Hosting on Amazon's platform essentially means I risk my revenue on Amazon's uptime. Actually using their infrastructure like S3 means I don't just risk my revenue but actually get locked in. Amazon is not willing to do the same, according to their total crap SLA. That tells me a lot. And to top it all of, Amazon is famous for "eating" businesses of their customers : use thei…

Again, you are tunneling... I used Amazon as an example. If you actually read what I'm saying, about how Cloud businesses in general depend on meeting their guarantees and not screwing over businesses, how their superior quality is because of scale and specialization, how they are reliable because one failure would doom them and they haven't failed yet, you could see that this has nothing to do with Amazon at all. Yo…

It's funny how you put just the opposite argument of common sense forward and present it as an axiom. The more customers a company has, the worse they treat them. Called comcast recently ? The less choice customers have the worse they're treated. How's your electricity company ? But when you can easily switch ... surely that's better right ? Hmm companies with lots of customers that can easily switch. Have you called Bank Of America recently ? And frankly, they're one of the better ones.

Amazon has superior quality ? They have at best average quality as a vps provider, unless you accept their products that cause lock-in. At which point you're at their mercy, and they have even less reason to treat you well. Amazon doesn't match, say, digital ocean (especially not in the transparency in billing department. WTF). There are other reasons to pick amazon of course, but quality, not one of them. Price ... not one of them. Service ? Not one of them. Stability ? Not one of them. Geographical reach ? At the moment Amazon does better (not that it matters unless you're in Asia).

One failure would doom them ? Just from memory I know two big amazon cloud failures that you could not protect from with availability zones, the ones in a single datacenter, they don't even publish.

The fact that they refuse to publish single cluster failures is probably another aspect of that superior quality you mentioned.

Also, you can get fucked on an ongoing basis just by getting scheduled on a machine. I guess that's part of their superior quality (a lot of VPS providers of course have this problem, others are better at it).