Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Having the ability to back stuff up via a network is great.

Most of the time when we say "Cloud Services", though, it means exactly one specific vendor. If an app is designed to integrate with Dropbox and GitHub, I can't necessarily substitute an alternative, or run my own replacement instance. If a cloud-based solution becomes unavailable because the company is bought out, shut down, drops old API support, or simply because I've stepped onto an airplane, I'm stuck. The cloud is both a convenience and an accident waiting to happen.

My NAS at home has never sent me an email thanking me for participating in an Incredible Journey and disappeared.



I'm not talking about backing stuff up. I'm talking about not keeping data of business value on single points of failure in the first place. Those hardware failures weren't resolved in 3-4 hours by restoring backups, they were resolved by fetching and setting up things from systems of record. Version control. Artifactory. Runbooks in a Wiki.

If this data is useful, why am I bogarting it? I should be sharing it, as soon as possible. If some ears are too sensitive to see rough drafts, we can use obscurity or permissions to control premature messaging.

It's the same argument as Bus Numbers, or for DVCS, or feature branches. I don't want days or weeks worth of work hanging out on some engineer's system, which can get wet or take a tumble down the stairs on the way to a meeting or stay home for a week while down with the flu.

Backups are for people with a bus number of 1 (ie, mismanaged teams or personal projects).




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: