Hacker News Reader

Hacker News

Comment by j_s | Hacker News Reader

Parent Full thread

j_s

We also reserve the right to suspend or end the Services at any time at our discretion and without notice.

https://www.dropbox.com/terms

View on HN

So I guess the conclusion is that no mainstream cloud service is to be relied on.

Well, these big services probably close down as often as an end user sees their hard drive fail.

This is not about a company closing down. Its about a company deciding to close their services for a user, arbitrarily, at their own discretion. Files you upload can be permanent deleted, at any time, at the whim of the service provider or any of their employees. You have no rights and no appeals.

The difference is that a user doesn't feel like just using his computer normally gives him any backup. But if his folder is inside Dropbox, he might be lulled into a sense of comfort since he thinks of Dropbox as a kind of backup[1]. So if he uses Dropbox instead of just using his plain old computer (hard drive), then he might start to get more careless than when he didn't feel that he had a safety net.

[1] Though personally I would disagree.

https://owncloud.org/

Can't your hosting provider terminate your contract?

Use multiple services and replicate between them.

May as well use MaidSafe or Freenet

I always thought Tor hidden services make a great way to host your own cloud. Not only can you host on your own hardware without messing with dns, isp reps, and router settings, but you get privacy features for free.

IMO, I think local hosting is the primary usecase the Tor project should be advertizing.

Hidden services are not a primary concern of the Tor Project, or a primary use of the Tor network. They are a novel way of using a system designed for anonymous and censorship-resistant communications.

Does no one have their own physical box any more?

Doesn't solve the problem. The essential nature of the problem is that your data can disappear under circumstances that you can't control, be it because the server died, problems with the host, they're going away entirely, they decide they don't like you anymore. To fix all permutations of this problem, you have to replicate, host the data in multiple physical places.

It introduces another problem, managing the replication and testing to make sure it's working, but if the data you're trying to protect is important enough, you devote the resources.

Looked at in this light, hosting your own physical box is less useful than using two separate online services. You still have the management and testing overhead either way, but with your own physical box you also have to maintain and manage that resource too. That only makes sense if you have existing infrastructure you can plug into, and sometimes it doesn't even make sense then.

Or vice versa... all the solutions you mentioned are liabilities if given enough thought. The cost of hosting in multiple places coupled with the very real possibility of other circumstances not in your control are enough to make the argument to host your own stuff a viable solution. The cognitive overhead of learning the api, writing tools to automate processes, testing and so on are not free in either time or money.

I don't think a clear cut winner emerges in all cases. Cloud vs. DIY is situationally dependent and requires a great deal of deliberation. I think the pendulum will swing between cloud and DIY for a long time... With proponents of each making awesome cases to use either one.

When it comes to risk, honestly, most people and companies are their own worst enemies, much much more inclined to hose themselves than, say, Linode or Amazon would.

The cost of using multiple solutions should be negligible compared to the cost of losing the information. If it isn't, then store it wherever, and if you lose it, so what.

A competent developer should not have to spend a lot of time learning an api, automating the process or testing the automation. If you don't have a competent developer, you should just use COTS. If you have a developer that complains about the time these tasks take, you don't have a developer, you have a technical handyman. In which case you can't engineer anything and should just use COTS, because that's all he'll realistically be able to handle anyway. If the developer is you and you can't afford to waste your time engineering your infrastructure, then yours is not a technology company and again should just use COTS.

Your operating profits should support the cost of your engineering, including the salary of a competent developer, this will typically dwarf your hosting costs. If they don't then you don't have a real business and need to spend more time figuring out how you're going to make money and less time on the technology.

If you're storing and using big data, and currently using a cloud provider, then your roadmap should include a plan for eventual self-hosting, as that's one of the few areas where self-hosting still makes sense, as costs can diverge very quickly. It's not big data unless building your own Backblaze storage pod is a viable option.

For all other applications, self-hosting can quickly become a boondoggle, unless you have competent systems administration, the cost of which will again dwarf your hosting costs. If you do not have competent systems administration, and you are owning and managing systems, then your business is a disaster waiting to happen. If the hard drives fill up on your home-built server, you will have downtime until you can figure it out and fix it. You will not have your hosting company's skilled customer support team, which handles the common cases that trip people up all the time, at your disposal.

Any time you touch the machine do do anything other than deployments, you run the risk of breaking something important. If your development is not competent either, then you run the risk of having your hygienic development process dirtied by, say, someone working directly on the production server. The problems caused by this are insidious and can take up time and attention that is better used pushing your business forward.

> Doesn't solve the problem.

My post was a reply to:

> Can't your hosting provider terminate your contract?

It does solve that problem exactly.

I didn't propose a single box as a complete backup solution.

I worked for a company that had hundreds of boxes held hostage after a colo attempted to dramatically raise prices mid contract. The company eventually sent a bunch of employees with vans over a weekend to the city the colo was in to physically move the machines and reconstitute ~20 racks in a different colo.

Does no one have their own boxes on their own site any more?

Getting serious power / ac / battery switch-over / TB/s internet is a lot of work, hence datacenters. If you're under thousands of boxes, it's not cost effective.

Unless you also have your own physical network infrastructure connecting all the things it needs to connect to, and also control all those endpoints, having your own physical server doesn't solve the problem, it just pushes it around a bit.

Realistically, you can't rely on anything. You should always have independent redundancy for stuff that's really important.

The conclusion should be that unless you're paying for an SLA, you aren't going to get an SLA.

Reply on news.ycombinator.com