Brownout in software engineering is a technique that involves disabling certain features of an application.
Description
editBrownout is used to increase the robustness of an application to computing capacity shortage.[1] If too many users are simultaneously accessing an application hosted online, the underlying computing infrastructure may become overloaded, rendering the application unresponsive. Users are likely to abandon the application and switch to competing alternatives,[2] hence incurring long-term revenue loss. To better deal with such a situation, the application can be given brownout capabilities: The application will disable certain features – e.g., an online shop will no longer display recommendations of related products – to avoid overload. Although reducing features generally has a negative impact on the short-term revenue of the application owner,[3] long-term revenue loss can be avoided.
The technique is inspired by brownouts in power grids, which consists in reducing the power grid's voltage in case electricity demand exceeds production. Some consumers, such as incandescent light bulbs, will dim – hence originating the term – and draw less power, thus helping match demand with production. Similarly, a brownout application helps match its computing capacity requirements to what is available on the target infrastructure.
Brownout complements elasticity. The former can help the application withstand short-term capacity shortage, but does so without changing the capacity available to the application. In contrast, elasticity consists of adding (or removing) capacity to the application, preferably in advance, so as to avoid capacity shortage altogether. The two techniques can be combined; e.g., brownout is triggered when the number of users increases unexpectedly until elasticity can be triggered, the latter usually requiring minutes to show an effect.[4]
Brownout is relatively non-intrusive for the developer, for example, it can be implemented as an advice in aspect-oriented programming. However, surrounding components, such as load-balancers, need to be made brownout-aware to distinguish between cases where an application is running normally and cases where the application maintains a low response time by triggering brownout.[5]
References
edit- ^ Cristian Klein, Martina Maggio, Karl-Erik Årzén, and Francisco Hernández-Rodriguez. 2014. Brownout: building more robust cloud applications. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). ACM, New York, NY, USA, 700–711. doi:10.1145/2568225.2568227.
- ^ Nah, F. F. 2004. A study on tolerable waiting time: How long are Web users willing to wait? Behaviour & Information Technology, 233, 153–163. doi:10.1080/01449290410001669914.
- ^ Daniel Fleder, Kartik Hosanagar, and Andreas Buja. 2010. Recommender systems and their effects on consumers: the fragmentation debate. In Proceedings of the 11th ACM conference on Electronic commerce (EC '10). ACM, New York, NY, USA, 229–230. doi:10.1145/1807342.1807378
- ^ Gabriel A. Moreno, Javier Cámara, David Garlan, and Bradley Schmerl. 2015. Proactive self-adaptation under uncertainty: a probabilistic model checking approach. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). ACM, New York, NY, USA, 1–12. doi:10.1145/2786805.2786853.
- ^ Cristian Klein, Alessandro Vittorio Papadopoulos, Manfred Dellkrantz, Jonas Dürango, Martina Maggio, Karl-Erik Årzén, Francisco Hernández-Rodriguez, and Erik Elmroth. 2014. Improving Cloud Service Resilience Using Brownout-Aware Load-Balancing. In Proceedings of the 2014 IEEE 33rd International Symposium on Reliable Distributed Systems (SRDS '14). IEEE Computer Society, Washington, DC, USA, 31–40. doi:10.1109/SRDS.2014.14.