Accurate. If the conversation revolves around cutting the absolute cloud budget, perverse incentives kick in and people will start naively "cutting" costs witho

Accurate. If the conversation revolves around cutting the absolute cloud budget, perverse incentives kick in and people will start naively "cutting" costs without thought. Producing value always has a cost. In a functional organization with a competent business plan, higher input costs should mean higher production and more revenue! Decoupling costs and production is simply impossible and defies the laws of physics. If you're a truck driver and you get a new job demanding double the miles, you expect to pay double the gas price - this is common sense in most industries. It would be absurd to take a job and insist that you can do it on half the fuel, then proceed to not do it but instead spend time holding meetings to speculate on how you could double the efficiency of diesel engines. If you're irrationally scared of absolute costs, you'll make decisions that reduce everything: throughput, latency, functionality, customer engagement, and reliability. Cut costs without any design intent = cut value. And often at the expense of additional engineering complexity to compensate for the enforced austerity. And from the business perspective, you've backed yourself into a corner where the system is so locked-down from being micromanaged by bean counters that it couldn't possibly handle the exponential growth you've promised to investors. Looking at absolute costs always seems to lead to this lose-lose situation. This is the path of a failed product. The better approach, suggested by this article, is focus on the efficiency of your infrastructure. Whether you're processing data or serving web requests or whatever, frame the question in terms of operating cost per unit of value delivered. Then the engineering team has three jobs a) track output and cloud costs somewhere and regularly compare them, b) make each unit more efficient, either through code improvements or architectural changes and c) scale the infrastructure up and down according to demand, such that costs scale predictably with load. This leads to a situation where the entire team is prepared for and welcomes a sudden increase in costs as that translates directly to customer activity. You can get back to the business of creating and selling value... rather than enforcing an arbitrary budget restriction on your main feedstock for production.