Efficiency trades off against resiliency
While I generally agree that the pattern this article describes is real (there&#x27;s some degree of tradeoff between robustness and efficiency), I&#x27;ve frequently seen engineers fall back on that logic rather than <i>actually thinking</i> about the specific problem they&#x27;re facing, and spending five minutes trying to come up with a creative solution.<p>For example, talking about the CPU utilization of a web service, your service can perform a mix of time-critical work (serving queries) and background tasks (indexing, etc). If a server is running at 100% CPU but 30% of that is spent performing background work, the amount of slack available for a sudden surge in demand is 30%, and I suspect it&#x27;s almost never the case that a large service sees an unexpected 30% load increase in less time than it takes to boot another machine, so such a system could be both efficient and robust with few downsides.<p>Implementing that system isn&#x27;t as easy as just throwing more Kubernetes nodes at your problem, especially given that the ecosystem of tooling isn&#x27;t designed to make it easy. For example, it would be really nice if load balancers used realtime performance metrics to balance traffic at a millisecond level.<p>Perhaps the real lesson is that &quot;many of the easiest ways to achieve robustness involve sacrificing large amounts of performance&quot;, but I reject the idea that we should use that as an excuse to accept terrible performance, with all the monetary and environmental impacts it brings.