3 ms·
The feature flag service was doing double duty as both the “marketing experimentation A/B testing” platform and the “feature rollout” platform. Not defending th
by yojo 5y ago
The feature flag service was doing double duty as both the “marketing experimentation A/B testing” platform and the “feature rollout” platform. Not defending the service boundaries, but it had enough meat by itself that there was a full time team working on it.
I also think the intent of the service was to be used for temporary experiments and rollouts, with the assumption that everything in the system could safely turn off. If these assumptions held you might not want to allow a bug in the flag service to take down auth. Indeed, the outages we did have from feature flag service going down would have been worse outages if it was crashing all of auth and unaffected clients couldn’t log in.
In practice long running tech debt resulted in unexercised code paths that might be years out of date.
- nicoburns 5y ago> The feature flag service was doing double duty as both the “marketing experimentation A/B testing” platform and the “feature rollout” platform. Not defending the service boundaries, but it had enough meat by itself that there was a full time team working on it. Ah, we're small enough that we don't have a marketing team and we don't have capacity to do A/B testing either!
- yojo 5y agoAh yeah. The right answer to this question looks very different depending on how old/mature your codebase is and how big your eng team is. My example is from a ~1200 person eng org with a ten year old codebase.