Why feedback?

Maintaining a desired behavior

In two previous posts (Part 1 and Part 2) we introduced the idea of feedback control. The basic idea is that we can keep a system (any system!) on track, by constantly monitoring its actual behavior, so that we can apply corrective actions to the system’s input, to “nudge” it back on target, if it ever begins to go astray.

This begs the question: Why should we, as programmers, software engineers, and system administrator care? What’s in it for us?

The answer is that feedback is ideal for many of the problems that we are faced with day to day. Think about it – how many typical problems, specifically in enterprise programming, but also elsewhere, amount to maintaining a desired behavior? Examples include:

  • Server Scaling: Grow and shrink the number of active server instances in response to changing web traffic.
  • Order Processing: Manage resources, so that customer orders are being processed at a constant rate, even as the rate of incoming orders changes.
  • Queue Control: Throttle the flow rate of requests appropriately, so that the number of pending requests does not exceed desirable bounds.
  • Workflow Management: Make sure that the flow of work items is constant at all times. Assign workers (or other resources) dynamically, to keep the completion rate of items constant.
  • Temperature Control: Adjust the fan speed in a power supply so that the temperature remains at the desired level. In particular, increase the cooling action, whenever the temperature begins to raise.
  • Supply-Chain Management: Develop a system that keeps inventory levels constant, even as customer demand fluctuates randomly.

In all these examples, we want to keep some quality-of-service metric constant, even as conditions change. (For instance, we want the response time for a customer request to be the same, even as the intensity of web traffic changes in the course of the day.) Moreover, in all these situations, our knowledge about the controlled system is incomplete: how many servers precisely do we need to spin up to handle a spike in traffic? This lack of knowledge makes it difficult to build fully autonomous control algorithms. Feedback control offers a different approach to this problem. For a feedback controller, we do not need to know how many additional servers are required to handle a change in traffic. Instead, we just monitor the quality-of-service metric: if the response time (to incoming requests) deteriorates, add more servers. If that isn’t enough, add more. Once the request rate stabilizes, stop adding more (and begin taking some down).

In other words, feedback control is a way to keep systems on track, even under changing conditions, and without requiring full knowledge of the way these systems work. Another way of saying this is to consider feedback control as a particularly simple way to automatically and dynamically reconfigure a system at runtime.

Feedback control can help with all tasks that require our systems to maintain some form of desired behavior. However, feedback is rather different from algorithmic-deterministic solution approaches, that are more typical for computer systems, and it requires some special skills to get right. We will study how feedback is different from, for instance, rule-based algorithms next. Stay tuned.

tags: , , ,