How is it technical debt? How else do you handle software rollout and rollback, or canarying? Do you have a VM for every single version of your software?
Uhhh... backups?! Not all companies release daily, weekly, and sometimes not even monthly. Stage the rollout, do your testing, get your evidence, get your plan, perform the release.
q3k, I can't reply to you at this depth. But yes. You're saying a "full backup / restore" but it's not the entire system.
Let's say you have an app, in a folder, that reads config files from 3 other locations on the machine. It talks to two databases. You back up two databases and 4 total folders. That's your backup. It's simple and straight forward to me.
(you have to wait until you can reply after a certain depth - this is HN's anti-flamewar system kicking in)
I understand you can restore from backups, but this doesn't seem simple to me - especially when you deal with situations where there's more than just one person deploying to production.
In comparison, my rollbacks are performed the same way rollouts/rollforwards are - by editing a single line in Git (ie. changing the OCI image string) and running `kubecfg update`. No need to access backups, no need for special procedures.
I look at it this way. I think it's simpler to do this kind of backup in case things go wrong (which, honestly, is not that often. Twice in 5 years that I can think of off the top of my head) than it is to set up kubernetes, manage kubernetes, and convert our applications to work correctly in kubernetes. All of that is required so that your single line edit becomes a possibility. That's a lot of work to enable that workflow versus copying 5 directories to one location, zipping it, slapping a version tag on the zip file, storing it in a couple of places.
I think it’s flawed to think that you can safely have multiple versions of the same app running (or even installed) simultaneously in the same “universe.” Whether you use jails, VMs, containers, or whatever you should not count on “I didn’t change anything between these two versions that would corrupt the other instance” to help you.
In a real sense, yes. Once it's deployed, it incurs costs, like a debt.
Reminds me of:
> My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.