4 ms·

You seem to push towards classic database replication and backups, which is cumbersome at the very least, pain in the ass to manage, easily misunderstood by non

by szszrk 3y ago

You seem to push towards classic database replication and backups, which is cumbersome at the very least, pain in the ass to manage, easily misunderstood by non-DBA people and often the most expensive part of a solution. Your "replication over the network" remark makes little sense to me - adding this kind of replication doesn't make this system any slower or more fragile. The restore action may be fragile, but the system itself works the same as without it. > So now you've got to manage two apps, not one? I thought this was simpler? It does make it simpler - there are zero changes to codebase. The "other app" is an addon/a sidecar, which is an extremely common practice. Compare that to creating your own replicated database in a classical sense. Also not all people deploy their own creations. There are plenty of self-hosters who don't code the system they deploy, or don't have that ability/will to be it's developers as well. > wouldn't you want to use Serverless? Since that's literally zero servers? How is serverless zero servers? Serverless is (usually proprietary) solution to shared servers, not zero servers. It's also only simple if you don't care where and how your code runs and is secured. If you do care, serverless isn't simple any more. You seem to also ignore that selfhosting exists and is big. That low cost hosting exists and is surprisingly popular. That many systems don't need multiple instances spread across multiple datacenters, when their RTO and RPO are really low and actual successful disaster recovery scenario is just a bash script that will run for a minute or two. While you are right to point that this solution is not exactly backups (IMO it sits between HA and DR solutions while combining flaws and advantages of both), your other criticism feels very personal.

throwaway892238 3y ago
One of the fundamental problems of distributed systems is the network. Adding a computing component over a network adds all kinds of complexity. Adding data on top of that adds complexity in managing data. If the purpose is to simplify, then you would want to remove the components that add complexity, but here instead of removing them, we've simply changed them, and removed some of their useful functionality. Complexity remains but in a different shape. My criticisms are personal, in that it feels like the page is trying to be willfully deceptive, and that's annoying.
- szszrk 3y ago
  In all honesty, it does not add any computing component over the network. App works as it used to work without it. If upload fails or network is gone the app works in exactly the same way with no interruptions. No changes to business logic, no changes in code needed to work around that. The only impact is your copy is not up to date. That's kind of the whole point.

by szszrk 3y ago

throwaway892238 3y ago

One of the fundamental problems of distributed systems is the network. Adding a computing component over a network adds all kinds of complexity. Adding data on top of that adds complexity in managing data. If the purpose is to simplify, then you would want to remove the components that add complexity, but here instead of removing them, we've simply changed them, and removed some of their useful functionality. Complexity remains but in a different shape. My criticisms are personal, in that it feels like the page is trying to be willfully deceptive, and that's annoying.

szszrk 3y ago
In all honesty, it does not add any computing component over the network. App works as it used to work without it. If upload fails or network is gone the app works in exactly the same way with no interruptions. No changes to business logic, no changes in code needed to work around that. The only impact is your copy is not up to date. That's kind of the whole point.