3 ms·

>> Computer systems in the wild are stochastic > Try telling a client who wants 100% uptime that! A client who asks for 100% uptime will end up disappointed.

>> Computer systems in the wild are stochastic > Try telling a client who wants 100% uptime that! A client who asks for 100% uptime will end up disappointed. > We attempt to remove an entire class of issues related to deployment environment by changing our platform engagement paradigm to one that is less procedural/'stochastic' to something that is more atomic/reliable. I'm afraid I don't get the difference. You've argued that configuration drift is a major problem with configuration management tools, but I don't see how any solution based around deploying full system images couldn't also apply to stepped upgrades applied by CM. Allowing config changes to be made directly to production servers instead of going via the deployment tool is the problem there, not anything fundamental to which deployment style has been used. With puppet configuration (for instance) in version control, it's not a problem to test against a known, versioned, identifiable and auditable environment. As long as you're not applying config changes to live servers, the switchover to a new environment is equally atomic either way. Given that the trade-off is building, storing and deploying full system images, I don't think there's a fundamental advantage to full-system deployment that can't be matched by a thought-out application of conventional configuration management.

contingencies 13y ago
A client who asks for 100% uptime will end up disappointed. Sure. [...] I don't think there's a fundamental advantage to full-system deployment that can't be matched by a thought-out application of conventional configuration management. OK, on the face of it, this is a fair line of reasoning. If we assume, however, that we are looking for ... replication (say, for the purposes of regression testing, etc.) then we really do need to know that the entity in question is the same as the last time it was .. err .. generated/instantiated. With the process you propose, there is clearly higher risk here. That is a paradigm weakness.

contingencies 13y ago

A client who asks for 100% uptime will end up disappointed. Sure. [...] I don't think there's a fundamental advantage to full-system deployment that can't be matched by a thought-out application of conventional configuration management. OK, on the face of it, this is a fair line of reasoning. If we assume, however, that we are looking for ... replication (say, for the purposes of regression testing, etc.) then we really do need to know that the entity in question is the same as the last time it was .. err .. generated/instantiated. With the process you propose, there is clearly higher risk here. That is a paradigm weakness.