Energy Is Becoming a Software Constraint

For most of the industry's history, electricity was somebody else's problem. You provisioned capacity, the provider handled the rest, and the only number engineers watched was the invoice. That abstraction is thinning. Data centre siting is now driven by grid access, training runs are scheduled around power availability, and the cost curve of inference has a very physical floor.

Why this reaches application teams

Three ways, in increasing order of immediacy. First, pricing: compute-heavy features carry a cost that no longer falls as reliably as it once did, which changes what is worth automating. Second, capacity: availability of specific accelerator types varies by region and season, which affects deployment planning. Third, reporting: emissions disclosure requirements increasingly ask for numbers that only engineering can produce.

The efficiency levers that actually matter

• Do less work. Caching a result, routing to a smaller model, and rejecting redundant requests beat every micro-optimisation. The greenest computation is the one you skipped.
• Batch aggressively. Accelerator utilisation is dominated by batching; a poorly batched service can waste most of its capacity while appearing busy.
• Shift what can be shifted. Non-urgent jobs such as reindexing, training, and report generation can run when power is cheaper and cleaner, and almost nobody schedules them deliberately.
• Right-size storage tiers. Data that has not been read in a year is a recurring energy cost with no user benefit.

Measure something, even if it is imperfect

Precise carbon accounting for a distributed application is genuinely hard, and waiting for precision is how teams end up measuring nothing. Start with proxies you already have: accelerator hours by service, compute hours by environment, storage volume by tier, and egress. Track them per unit of product value, such as per active user or per completed task. The direction of that ratio tells you more than an absolute figure with a large error bar.

Non-production environments are frequently a third of compute spend and produce nothing. That is usually the first place a serious efficiency programme finds its wins.

The reframing worth adopting

Efficiency has historically been sold to engineering teams as cost control, which makes it a finance concern that gets deprioritised. Framed as a capacity constraint, it becomes an engineering concern with a deadline, because the workloads you want to run next year will compete for resources that are not expanding as quickly as demand.

Teams that build the habit now will find the constraint manageable. Teams that treat it as an accounting exercise will meet it as a limit.