3 ms·
> Debian plus an automation system like Puppet, Chef, etc works extremely well. Eh, it does until it doesn't. Sooner or later you run into pitfalls around the
by cactus2093 6y ago
> Debian plus an automation system like Puppet, Chef, etc works extremely well.
Eh, it does until it doesn't. Sooner or later you run into pitfalls around the leaky abstraction of pretending your state is truly idempotent and path-independent. E.g. spinning up a new instance works fine, but the existing instances that need to uninstall a previous version to upgrade to the newer one end up breaking. Or vice-versa, existing servers work fine but then when you need to launch a new one your realize the config no longer works on a clean install and you hadn't noticed it for weeks.
Container-based systems certainly have their own problems, but it is really nice having a model where you don't allow long-lived implicit state and cruft to accumulate on your application servers in the same way.
- dsr_ 6y agoIf I don't understand what I'm doing, it doesn't matter what tools I'm using to fail to accomplish it.
- oblio 6y agoAh, the myth of the perfect programmer. Everyone makes mistakes, and state resets such as VMs or containers are one of the easiest ways to revert these mistakes.
- dsr_ 6y agoEveryone makes mistakes, and having real testing infrastructure is the best way to catch it. Many mistakes are made against databases; maybe you can roll back, maybe you can't -- either way, it's cheaper in testing than production.
- oblio 6y agoThere are also state inconsistencies on servers. Configuration files are not updated correctly (maybe even with a silent failure), binaries are not updated correctly, temporary files left over interfere with the update, cached files do the same, etc. There are many reasons why resetting the environment on deployment is a solid and cost effective solution to many issues.