3 ms·

There is a tension between delivery speed and operational safety. The faster you deploy new service code, the faster you can take down your service because of

by cle 7y ago

There is a tension between delivery speed and operational safety. The faster you deploy new service code, the faster you can take down your service because of a bug that slipped past your automated tests. This is why one-box deployments and traffic shifting and feature flags exist (which are increasingly config-driven). And if you have multiple instances of your service running (e.g. regional endpoints), and you care about availability, then you'll be deploying sequentially to each endpoint and watching for anomalies before moving to the next endpoint. There is still immense value in dynamic config in these scenarios.

lmm 7y ago
> There is a tension between delivery speed and operational safety. The faster you deploy new service code, the faster you can take down your service because of a bug that slipped past your automated tests. 100% agreed - but people miss that this applies just as much to deploying a "config change" as it does to a code change. Particularly if you're talking about feature flags, a config change and a code change are effectively equivalent - so you should apply the same standard to both. (What that standard should be is still a tradeoff) > This is why one-box deployments and traffic shifting and feature flags exist (which are increasingly config-driven). > And if you have multiple instances of your service running (e.g. regional endpoints), and you care about availability, then you'll be deploying sequentially to each endpoint and watching for anomalies before moving to the next endpoint. I would agree that feature flags are config-like - and view them as the same antipattern. Traffic shifting and sequential deployment are great ideas, but they work great when deploying a code change. Make the change, gradually deploy the new version, roll back if needed. What does dynamic config gain you in that scenario? Only more possibilities to make mistakes, IME (e.g. the new version looked great on the "canary" node, but actually that instance had a different config from the other nodes).
- HelloNurse 7y ago
  Not all software is "your service" that you can "take down" to install changes; there are cases in which there are multiple deployments with essentially independent and different configuration data that cannot be part of program code. A popular example: the Git client, which stores layered configuration files for repositories, users and installations including, for instance, local file names (such as diff tools) and user identities. Git also serves as an example of how the line between configuration files and data can be blurred: it's customary to put in Git repositories .gitignore and other similar additional configuration files because it's useful and the software only cares about their presence, not their management.
- deleted 7y ago
  [deleted]

by cle 7y ago

lmm 7y ago

> There is a tension between delivery speed and operational safety. The faster you deploy new service code, the faster you can take down your service because of a bug that slipped past your automated tests. 100% agreed - but people miss that this applies just as much to deploying a "config change" as it does to a code change. Particularly if you're talking about feature flags, a config change and a code change are effectively equivalent - so you should apply the same standard to both. (What that standard should be is still a tradeoff) > This is why one-box deployments and traffic shifting and feature flags exist (which are increasingly config-driven). > And if you have multiple instances of your service running (e.g. regional endpoints), and you care about availability, then you'll be deploying sequentially to each endpoint and watching for anomalies before moving to the next endpoint. I would agree that feature flags are config-like - and view them as the same antipattern. Traffic shifting and sequential deployment are great ideas, but they work great when deploying a code change. Make the change, gradually deploy the new version, roll back if needed. What does dynamic config gain you in that scenario? Only more possibilities to make mistakes, IME (e.g. the new version looked great on the "canary" node, but actually that instance had a different config from the other nodes).

HelloNurse 7y ago
Not all software is "your service" that you can "take down" to install changes; there are cases in which there are multiple deployments with essentially independent and different configuration data that cannot be part of program code. A popular example: the Git client, which stores layered configuration files for repositories, users and installations including, for instance, local file names (such as diff tools) and user identities. Git also serves as an example of how the line between configuration files and data can be blurred: it's customary to put in Git repositories .gitignore and other similar additional configuration files because it's useful and the software only cares about their presence, not their management.
deleted 7y ago
[deleted]