A while back, I wrote up some notes on the use of feedback control in auto-scaling server instances in a data center. Afterwards, a reader contacted me to ask whether the article didn’t “boil down to ‘pick your auto-scaling metrics wisely’?”
That’s exactly right!
Feedback control indeed “boils down” to picking the appropriate metric when making decisions. The whole idea behind feedback control is to base actions on the actual behavior (the “output”) of the system, and not merely on its operating conditions (the “input”). Conceptually, that’s all there is to it.
This is nevertheless a big deal, for two reasons:
- We can tolerate a greater deal of uncertainty, while still maintaining a straightforward control algorithm: all we need to know about the system is how to steer it back when it begins to go astray. (To stay with the data-center example: we do not need to know how many servers are required at each level of traffic. All we need to know is that adding servers reduces response time.) That’s the prime advantage of using feedback control.
- However, we change the dynamics of the system in doing so. As a rule, there will be a delay between the moment that the operating conditions change (e.g. the traffic spikes) and the time that the system’s performance begins to degrade. This puts us at risk of initiating control actions too late—for instance, adding servers when the traffic spike has already subsided. More generally, one must make sure that the (inevitable) delays in a feedback loop don’t throw off the timing for the control actions completely: if that happens, the system will never settle to a steady state, but swing wildly from one extreme (for example, no servers) to the other (way too many servers). This is were all the theory, rules, and magic of control theory come in, in order to prevent this from happening.
So, while the concept of feedback control is simple (“base your decisions on actual behavior, not on circumstance”), the ramifications can be pretty extensive.