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]
Usage in phased deprecation
editA related use of the brownout concept in software engineering is the deliberate introduction of temporary outages to a system, API or feature that is being phased out. This is sometimes also called a "scream test" when it is used to discover unknown dependents of a system or API.[6][7]
The intention is to allow detection of downstream consumers of an API or service who may otherwise have missed deprecation announcements or to uncover hidden side-effects of the deprecation that may have been overlooked. The intention is that developers of dependent systems will notice their own system failures caused by the upstream brownout. Such brownouts are typically pre-announced scheduled outages[8][9] or probabilistic in nature (such as artificially failing a percentage of requests).
As a brownout is only a temporary or partial outage, it provides downstream consumers of an API or service time to remove any discovered dependencies on the deprecated API before it is fully retired. For consumers that have already prepared for the deprecation, a brownout provides valuable testing that the final removal of the service won't cause any unexpected problems.
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.
- ^ Pete Apple (April 25, 2025). "Microsoft uses a scream test to silence its unused servers".
- ^ Christian Wickham (February 26, 2019). "The Scream Test".
- ^ "Github Services Brownout". November 5, 2018.
- ^ "Notice of Permissions Changes to repo.spring.io, January 2023". December 14, 2022.
