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

191–200 of 235 posts

Re: Fuck the Cloud (2009)

#191

Post by sib »

ciupicri wrote: post #159
tremon wrote: post #35

Earlier quoted context omitted.

Our life's savings are not unique, and can be replenished from a different source. Our childhood pictures and personal correspondence are, and generally can not. Besides, banks are subject to rather a lot of external control, through regulation (oh noes!). Here in NL the government actually guarantees your savings (but not investments) should a bank go belly-up. I believe the US did something similar, although I didn…

By the way, as far as I know all the banks from the European Union guarantees savings up to 50,000 euros, some even more. And if you have more money, you can split them between multiple banks.

In the US, deposits are guaranteed up to $250K per ownership type, per customer, per bank. Ownership types include individual ownership, some retirement accounts, joint accounts, trust accounts, etc.

Re: Fuck the Cloud (2009)

#192

Post by TeMPOraL »

superuser2 wrote: post #169
CM30 wrote: post #150

The points in this article also apply really nicely to websites and other services, many of which seem to make the mistake of outsourcing everything to other people's platforms. Oh sure, you may be using 'the cloud' to host your webmail, or your forums, or your chat, or anything else... but what if that goes missing? You're in an even worse situation than the individuals using these services to host their personal fi…

> like Dropbox or the likes... Millions of people would lose most of their files overnight. That's false. Files in Dropbox are also stored locally on all your Dropbox-enabled computers. They would simply stop syncing, and you'd plug in another syncing service. If Dropbox disappears, your Dropbox folder just becomes a regular folder.

Unless they fuck up sync again and all your locally stored Dropbox folders get wiped clean. Happened once. I'm pretty sure Dropbox is more than cautious about it, but it's still a possibility with them, and more so with everyone else.

Re: Fuck the Cloud (2009)

#193

Post by lmm »

dspillett wrote: post #69
nsfyn55 wrote: post #44

Earlier quoted context omitted.

> Until your control panel gets hacked and you lose all your data This is just alarmism. If you really wanted to demonstrate your point you would show me some data. The data would demonstrate that over the millions and millions of users on a number of cloud platforms that their rates of data loss are significantly higher than your "home spun" storage. Then you would take out the outliers and show an honest distributi…

> demonstrate that ... on a number of cloud platforms ... that their rates of data loss are significantly higher than your "home spun" storage You seem to be missing the point. People are not saying "don't use cloud storage at all " They are saying "don't use cloud storage exclusively " You might trust that your cloud providers will never be hacked, that your individual account on them will never be hacked, that they…

Unless you've personally memorized all the data in your head, you're trusting someone or something. Even if you've printed it all out on acid-free paper and stored it in a bank vault, you're trusting the bank, you're trusting your paper supplier, you're trusting the courier who transports it back and forth. If you've stored it on "your" servers you're still trusting your hard drive manufacturer, your RAID firmware, your OS code, your hosting company, your sysadmins.

For most values of "I have x hours and y dollars to safely store z gigabytes", a pure-cloud solution (possibly involving multiple independent cloud providers) has a lower chance of failure than one involving local storage.

Re: Fuck the Cloud (2009)

#194

Post by Domenic_S »

matthewmcg wrote: post #188
Domenic_S wrote: post #89

Earlier quoted context omitted.

Think about the future too though. Facebook strips exif and may have resized/recompressed your images. 20 years from now when we can do more super cool things with that data, the data won't exist in your FB photos. Tangentially related, this is why I shoot RAW. Not because it might give me better pictures today, but because it WILL give me better pictures in 5-10-20 years. You can take a RAW today that was shot 5 yea…

Ideally, you'd want to keep RAW + JPEG. I'd be worried about reading some of the more obscure camera RAW formats in the far future. JPEG seems like a good backup (at the cost of the data loss you mentioned).

Yep, sometimes I convert to DNG for that reason, but that seems like pushing the problem out...

Re: Fuck the Cloud (2009)

#195

Post by ianopolous »

derefr wrote: post #181
bingofuel wrote: post #79

Earlier quoted context omitted.

The tax accountant analogy goes pretty well with this: The accountant is specialized in doing your taxes (aka serving up your data/files) but you still need to keep a copy of your tax records, receipts, and etc.

And so, ideally, I want to be able to tell my accountant to store my archival tax records in my safe-deposit box, not in his office. Compute infrastructure is a commodity—doesn't matter who's paying for it—but all the services you depend on should rely on storage infrastructure you have an SLA agreement with. I don't care about the "distributed computation" promises of Diaspora or Sandstorm.io; I think they're wrongh…

It sounds like what you want is close to the goals of Peergos (https://github.com/ianopolous/Peergos). Disclaimer: I am the team lead. We use IPFS for the storage (and P2P networking and DHT) and are storage provider agnostic, where the provider can't read your data. You can add as many IPFS instances that backup (pin) your files as you like, on whatever storage provider you like. You could grant a company like Facebook, fine grained read or write access to sections of your data that are relevant to them.

Re: Fuck the Cloud (2009)

#196

Post by lmm »

rsync wrote: post #121
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…

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

> 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]

Nonsense. It's very easy to have that kind of setup fail - remove one from the load balancer, take it down for maintenance, whoops we removed the wrong one from the load balancer. I've been in similar-sized companies using dedicated servers or AWS, so I've seen both sides. It's like how people feel safer when driving themselves than when being driven by a professional, even though a professional is overwhelmingly likely to be a better driver - everyone thinks "oh, there's no way I'd make that kind of mistake".

It is very easy to overengineer "high availability" systems - I certainly think things like STONITH and dedicated control planes are more trouble than they're worth, and running a system that you don't understand is a recipe for failure. But I'll take FreeBSD on a basic AWS setup - four EC2 nodes (multiple AZs), and an ELB - over bare metal any day. Physical server maintenance is not where I have a competitive advantage, and would mean more complexity to understand, not less.

Re: Fuck the Cloud (2009)

#197

Post by lmm »

jacquesm wrote: post #122
nsfyn55 wrote: post #71

Earlier quoted context omitted.

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.

Unless you're personally memorizing all the data then you're outsourcing the responsibility somewhere - either you're paying for a service that you hope will be compliant with its specification, or you're paying for hardware that you hope will be compliant with its specification and employees that you hope will be as skilled as they claim to be. There's no way to eliminate the risk entirely, all you can do is take the safest option available. These days that's often the cloud.

Re: Fuck the Cloud (2009)

#198

Post by TeMPOraL »

LinuxBender wrote: post #25
bradleyankrom wrote: post #7

This article is a lot of fun with the Cloud To Butt Chrome plugin installed.

That is by far my favorite plugin. Just don't forget to turn it off before presenting in a meeting...

I sometimes forget about it when using the c-word in a HN comment and later editing it.

And other times I don't forget, I just leave it and continue with a smile :).

Re: Fuck the Cloud (2009)

#199

Post by jimbokun »

derefr wrote: post #181
bingofuel wrote: post #79

Earlier quoted context omitted.

The tax accountant analogy goes pretty well with this: The accountant is specialized in doing your taxes (aka serving up your data/files) but you still need to keep a copy of your tax records, receipts, and etc.

And so, ideally, I want to be able to tell my accountant to store my archival tax records in my safe-deposit box, not in his office. Compute infrastructure is a commodity—doesn't matter who's paying for it—but all the services you depend on should rely on storage infrastructure you have an SLA agreement with. I don't care about the "distributed computation" promises of Diaspora or Sandstorm.io; I think they're wrongh…

If I'm a Facebook engineer, I would never agree to this because there is no possible way to optimize performance in this scenario.

What happens to Facebook when your data provider goes down, or just gets slow? What if they mess up permissions or change their API?

Maybe you're thinking "that's fine, if my provider isn't reliable, my Facebook account becomes unavailable and it's up to me to choose a better provider." But what about all the people who are sharing your feed (or whatever it's called these days, I don't really use Facebook)? Do they query your stuff, and then timeout when it doesn't respond in time? Now other people's stuff is slow to load.

Just seems like an engineering nightmare, to me.

Re: Fuck the Cloud (2009)

#200

Post by TeMPOraL »

wanderingstan wrote: post #29
alphadevx wrote: post #22

Earlier quoted context omitted.

They are much more tightly regulated (legally), and insured, often by governments.

That's an excellent analogy I hadn't thought of. SLA's between companies is perhaps a proxy in the data world, but nothing for individual users. When data will become so important/politicized that there will be regulations about data retention?

There are some regulations already - mostly on the side of keeping some of the data for tax/legal purposes. For decades.

(Makes me wonder how all those fly-by-night cloud startups are handling that.)

Post reply on HN