←back to thread

264 points davidgomes | 2 comments | | HN request time: 0.001s | source
Show context
Apreche ◴[] No.41875117[source]
Because upgrading is a lot of work, and is higher risk than upgrading other software.
replies(2): >>41875174 #>>41877335 #
kevin_thibedeau ◴[] No.41875174[source]
Seems like a massive design fail if they can't maintain backwards compatability and provide a safe, low friction upgrade process.
replies(3): >>41875459 #>>41876082 #>>41881658 #
1. aseipp ◴[] No.41881658[source]
Related, but Sandstorm is an app-hosting platform/solution that's very different in design than other solutions like Docker, and one of the reasons is that it's actually designed from the ground up for easy and effective use on homelab-style setups, because among other things (not limited to this, and 100% from memory):

1. Sandstorm apps need to always come back cleanly from a raw SIGKILL at any moment.

2. Sandstorm apps must be able to always upgrade ANY previous version of stored data, with no intervention, automatically, when newer versions are deployed.

These are tough technical constraints and have huge implications on the whole design. For example, the client/protocol layer needs to possibly be multi-version aware for clean rollouts, client connection failover needs to be built in, etc. But the reality is if you do not have these two constraints, your software will never really work in a turnkey forget-about-it-way way where someone just runs an instance and then actually forgets about it, and it can be safe and secure. This kind of stuff is imperative to every actual computer user who isn't a programming nerd.

This is why slapping Docker on a lot of existing pieces of software like databases doesn't really work in the grand scheme. Yes, it gets you started faster, which people value to a high degree. But it often lacks or has the same problems as other solutions on day 2, day 3, ... etc. So, you need to solve all the same problems anyway just in a different form (or externalize them onto some other solution.)

Realistically, the solutions have to be designed in from the ground up. That's very difficult to do but necessary.

Someone else mentioned in here that SQL Server always 100% works when upgraded in place from an old version. That's also my (limited, homelab-ish) experience and a good reason to like it.

replies(1): >>41881837 #
2. kentonv ◴[] No.41881837[source]
Huh, I never really thought of that as a unique property of Sandstorm, but you're absolutely right, this is essential to any software intended to be operated by a non-technical end user, and Sandstorm is aggressive about it (e.g. apps are always shut down by abrupt SIGKILL and whenever someone requested that we add some sort of clean shutdown notification, I refused).

Ironically, Sandstorm itself is still stuck running on Mongo version 2.6 (a decade old!) because Mongo can't necessarily be updated in an unattended way. Of course, we could never ask every Sandstorm user to do some manual process to upgrade it.

Meanwhile, newer versions of the Mongo Node.js client library don't support such old Mongo, which means Sandstorm cannot actually update that package nor any of the packages that depend on it anymore. And this is why Sandstorm is now stuck in time and no longer receiving updates. :(

It was clearly a big mistake for Sandstorm to use Mongo. We chose it because we built the UI on Meteor, which was really only designed to work wing Mongo. In retrospect I wish we'd used SQLite, whose backwards-compatibility guarantee has now reached twenty years.