> You realise just saying things are easy doesn't mean anything right?
See the disclaimer about familiarity with things. It means that it was easy for me, a pretty average individual in many respects, after investing a bit of time into learning self hosting in general. I'd argue that it can be the same way for many of the technically inclined folk on HN as well, if they care to explore it.
> That everything you listed their is a dependency waiting to fail. That they are products run by companies who can change their licensing, pricing and privacy policies. They can be bought out by other companies and release new versions that add/remove features that break your setup.
Disagreed.
Here's a list of dependencies in such an example setup:
- Ubuntu or Debian, have been free since their inception, easy to switch out for anything
- Docker or Podman or containerd, have been free since their inception, easy to switch out for anything OCI compatible
- Docker Compose or Docker Swarm or Hashicorp Nomad or Kubernetes, have been free since their inception, switching them out possible, would need to rewrite the deployment descriptor (possible in an automated fashion with tools like Kompose)
- PostgreSQL or MySQL or MariaDB, have been free since their inception, more problematic if data needs to be migrated, but can just re-import your files through the UI if that ever needs to be done (have done that during upgrades)
- Nginx or Apache or Caddy or Traefik, have been free since their inception, switching out would mean rewriting the config, doable
- Nextcloud or ownCloud, have been free since their inception, switching out would be similar to the DB migration, just reimport the data (have also done so)
Many of those are open source, so even if licenses change, you can just keep using the older versions if need be. All of those are also updated by people who have more resources to ensure that everything runs securely, more so than your app would, unless you don't expose it to the outside world, but that's a different discussion to have.
And no, they cannot release new versions that break any of my stuff, since i can run old versions in perpetuity should i so choose. They might release new versions and nothing will change. They might remove old versions but i'll still have them in my registry or even local Docker installs. The whole Docker Hub might burn down for all i care and i'll still have the old versions. That concern would only be valid in the case of auto updating software, such as snaps in Ubuntu, which is why there was a lot of backlash when they released it. So, currently i decide when i'll install updates to my own software (though it's also nice to enable automatic updates for system software, as opposed to "user" software).
> You also conveniently left out the part of buying hardware and installing and configuring OSs and software to run everything and making sure you have the necessary backups and redundancies to maintain a near flawless uptime on par with any cloud service.
My current home servers run on refurbished 200GEs, consumer motherboards, consumer value RAM, passive cooling, a bunch of 1 TB Seagate Barracudas (because i like having up to date backups) and on the whole seem more cost effective than any of the cloud hosting that you could get out there, both in regards to storage, as well as long term costs of renting services. That also extends to storage plans for things like Dropbox, Google Drive, or most of the SaaS apps out there. Plus, i believe that my personal information also has an inherent cost to it, so if you add that into the equation as well, a homelab makes even more sense.
As for setup, it's not as bad or scary as many make it out to be. You can have an install of Ubuntu or Debian up and running in 15-30 minutes, something that you might have to do once in 5 years, before an immense amount of freedom opens up to you. Granted, the additional configuration on top of that for me is a few dozen lines of shell scripts, since most of my software is in container clusters nowadays, each stack having a YAML file or two, which are all that i'll need - this also makes migrating over to new nodes immensely easy and gives me a nice way to manage my data and resources.
Saying that you need near flawless uptime is false and perhaps moving goal posts at this point. That said, most of my services have an uptime of around 99% (at least according to Zabbix) which is good enough for me and should anything ever break, i have the power to find out why that is and what to do to fix it, instead of having to sit around and twiddle my thumbs while someone at AWS fixes their darn SaaS even though the status page still shows green, whilst there's a post on the front page on HN in the mean time (yes, that happened).
> Your bloated scope of recording all sorts of data does not fit the intended goal. That the app will sunset is merely your opinion that is inherently bias to building everything from scratch. It is not viable for nearly everyone other than those belonging to niche enthusiasts communities.
HN in of itself is a bit of a niche community, but i'll stand up to your point of view nonetheless, the argument against self hosting and more and more reliance upon "Service as a Software Substitute" (SaaSS) is harmful and encourages you to give away your freedoms. Just look at what Richard Stallman wrote on the matter here: https://www.gnu.org/philosophy/who-does-that-server-really-s...
Now, perhaps this is a debatable argument, but i'd also end up with a huge hammer that works for all sorts of nails (the aforementioned notes, documents, pictures, other files), whereas you'd end up with 10 smaller hammers for different purposes, which would be an incredible burden to keep working because of their brittleness - Python versions, package updates and security fixes, Ruby versions, Node versions etc. Now, of course, you might learn more by writing bunches of apps, but you should still have a plan in place to deal with the risks. If you're just using a bunch of different apps that someone else has written, however, you get the worst of both worlds - not really learning anything (even if you manage to solve your problem) AND not having control over what happens to the app or what's going on behind the scenes.
Now, i'm not advocating for going full Stallman, but if you try self hosting, you'll see that it's not as bad as one might think, or at least i feel like most would end up with that conclusion in some capacity, unless they'd try setting up a Kubernetes cluster on day 1.
That said, when passionate people with differing opinions run into each other, flame wars can errupt, especially online, so i'll cease this discussion on my part. I hope that my point of view is clear however and that everyone can consider both my and your arguments and decide what works best for them, or share their thoughts or potential oversights on either of our parts!
See the disclaimer about familiarity with things. It means that it was easy for me, a pretty average individual in many respects, after investing a bit of time into learning self hosting in general. I'd argue that it can be the same way for many of the technically inclined folk on HN as well, if they care to explore it.
> That everything you listed their is a dependency waiting to fail. That they are products run by companies who can change their licensing, pricing and privacy policies. They can be bought out by other companies and release new versions that add/remove features that break your setup.
Disagreed.
Here's a list of dependencies in such an example setup:
Many of those are open source, so even if licenses change, you can just keep using the older versions if need be. All of those are also updated by people who have more resources to ensure that everything runs securely, more so than your app would, unless you don't expose it to the outside world, but that's a different discussion to have.And no, they cannot release new versions that break any of my stuff, since i can run old versions in perpetuity should i so choose. They might release new versions and nothing will change. They might remove old versions but i'll still have them in my registry or even local Docker installs. The whole Docker Hub might burn down for all i care and i'll still have the old versions. That concern would only be valid in the case of auto updating software, such as snaps in Ubuntu, which is why there was a lot of backlash when they released it. So, currently i decide when i'll install updates to my own software (though it's also nice to enable automatic updates for system software, as opposed to "user" software).
> You also conveniently left out the part of buying hardware and installing and configuring OSs and software to run everything and making sure you have the necessary backups and redundancies to maintain a near flawless uptime on par with any cloud service.
My current home servers run on refurbished 200GEs, consumer motherboards, consumer value RAM, passive cooling, a bunch of 1 TB Seagate Barracudas (because i like having up to date backups) and on the whole seem more cost effective than any of the cloud hosting that you could get out there, both in regards to storage, as well as long term costs of renting services. That also extends to storage plans for things like Dropbox, Google Drive, or most of the SaaS apps out there. Plus, i believe that my personal information also has an inherent cost to it, so if you add that into the equation as well, a homelab makes even more sense.
As for setup, it's not as bad or scary as many make it out to be. You can have an install of Ubuntu or Debian up and running in 15-30 minutes, something that you might have to do once in 5 years, before an immense amount of freedom opens up to you. Granted, the additional configuration on top of that for me is a few dozen lines of shell scripts, since most of my software is in container clusters nowadays, each stack having a YAML file or two, which are all that i'll need - this also makes migrating over to new nodes immensely easy and gives me a nice way to manage my data and resources.
Saying that you need near flawless uptime is false and perhaps moving goal posts at this point. That said, most of my services have an uptime of around 99% (at least according to Zabbix) which is good enough for me and should anything ever break, i have the power to find out why that is and what to do to fix it, instead of having to sit around and twiddle my thumbs while someone at AWS fixes their darn SaaS even though the status page still shows green, whilst there's a post on the front page on HN in the mean time (yes, that happened).
> Your bloated scope of recording all sorts of data does not fit the intended goal. That the app will sunset is merely your opinion that is inherently bias to building everything from scratch. It is not viable for nearly everyone other than those belonging to niche enthusiasts communities.
HN in of itself is a bit of a niche community, but i'll stand up to your point of view nonetheless, the argument against self hosting and more and more reliance upon "Service as a Software Substitute" (SaaSS) is harmful and encourages you to give away your freedoms. Just look at what Richard Stallman wrote on the matter here: https://www.gnu.org/philosophy/who-does-that-server-really-s...
Now, perhaps this is a debatable argument, but i'd also end up with a huge hammer that works for all sorts of nails (the aforementioned notes, documents, pictures, other files), whereas you'd end up with 10 smaller hammers for different purposes, which would be an incredible burden to keep working because of their brittleness - Python versions, package updates and security fixes, Ruby versions, Node versions etc. Now, of course, you might learn more by writing bunches of apps, but you should still have a plan in place to deal with the risks. If you're just using a bunch of different apps that someone else has written, however, you get the worst of both worlds - not really learning anything (even if you manage to solve your problem) AND not having control over what happens to the app or what's going on behind the scenes.
Now, i'm not advocating for going full Stallman, but if you try self hosting, you'll see that it's not as bad as one might think, or at least i feel like most would end up with that conclusion in some capacity, unless they'd try setting up a Kubernetes cluster on day 1.
That said, when passionate people with differing opinions run into each other, flame wars can errupt, especially online, so i'll cease this discussion on my part. I hope that my point of view is clear however and that everyone can consider both my and your arguments and decide what works best for them, or share their thoughts or potential oversights on either of our parts!