If you ask a team whether the current version of their service uses more energy than the version from two years ago, they usually can't tell you. This is odd when you think about it. They can tell you its latency to the millisecond. They can tell you what it costs to run each month. But the energy it spends to do its job is something nobody measures.
It's not that software people don't care about energy. There's a fair amount of research on it. People have compared how much energy different programming languages use [1], and which Java collection classes are cheapest [2]. But nearly all of it measures small pieces of code, once, under a benchmark. That tells you which sorting routine to pick. It doesn't tell you whether the system you're running is getting better or worse.
What an operator actually pays for is the energy the whole system spends to deliver whatever it delivers, over the months and years it's deployed. I think that quantity needs a name, and the best one I've found comes from biology. Call it software metabolism.
A system's metabolic rate is the energy it uses per unit of time while it's deployed and ready to serve. That's just a power, in watts. The more useful number is what you get when you divide the work the system does by the energy it spends doing it. Call that metabolic efficiency. For a web service the work might be requests served. For a batch system it might be jobs finished. Whatever it is, efficiency lets you compare two systems that do the same job, however differently they're built.
Biologists split metabolism into two parts, and the split works for software too. There's the basal rate, which is what you spend just being alive. And there's the active rate, which is what you spend doing things. For software, the basal part is everything a system does to stay a system. It holds memory. It keeps connections open. It sends heartbeats so the rest of the cluster knows it hasn't died. None of that is work anyone asked for, but it all uses energy.
People who know hardware will recognize this as the old split between static and dynamic power, just applied to a whole deployment instead of a chip. It's also why idle servers are so expensive. Barroso and Hölzle pointed out years ago that a server doing almost nothing still draws a large fraction of its peak power [3].
Figure 1 shows how the pieces fit. You draw a boundary around the whole system, runtime and infrastructure included. You measure the rate and divide by what the system delivers. Then you can look at the result in two ways: over time, and across systems of different sizes.
The first is where things get practical. Software tends to grow. Lehman noticed this decades ago [4], and anyone who has worked on a codebase for more than a year has noticed it too. Each release adds a dependency or a framework or some background process that seemed like a good idea at the time. None of these is expensive on its own. But they add up, and nobody is watching the total.
So I'd guess most long-lived systems suffer from what you could call metabolic bloat. The rate climbs across releases faster than the useful work does, and efficiency gets worse. The reason nobody notices is that nobody records the number. If you did, bloat would become an ordinary regression. We already fail builds when latency jumps. There's no reason we couldn't fail them when energy per request jumps.
The second way of looking at it is more speculative, and to me more interesting.
In biology there's a rule called Kleiber's law. An animal's metabolic rate grows with its body mass raised to roughly the three-quarters power. That means an elephant uses much more energy than a mouse in total, but much less per kilogram. Big animals get economies of scale. West, Brown and Enquist later showed this falls out of the way branching networks move resources through a body [5].
Does software have anything like this? As far as I know, nobody has looked. If you wanted to find out, the experiment isn't hard to describe. Pick some measure of size, like lines of code or memory. Measure the metabolic rate of a lot of systems, or of one system across its history. Then see whether energy grows slower or faster than size.
Either answer would tell you something. If bigger systems turn out to be more efficient per unit of size, the way elephants are, that's a nice fact about software. If they turn out to be less efficient, that's a much more useful fact, because it means growth itself is a sustainability problem, and keeping systems small is one of the most direct ways to cut energy.
Once you start thinking of software this way, other ideas from biology start to look useful too. The ratio of basal to active energy, which you could call a system's metabolic profile, varies a lot. A busy model-serving endpoint spends almost all its energy on work. A rarely used internal service on hungry hardware spends almost all of it waiting [3]. Few teams know which kind they have, and it matters, because the two need opposite fixes. You make the first cheaper by making the work cheaper. You make the second cheaper by making it need less to stay awake.
Animals have a trick for that second case, which is to hibernate. When there's nothing to do, they drop their basal rate. The software equivalents are things like scale-to-zero and serverless. There's also a milder version where the system doesn't sleep but does less. Our group has worked on self-adaptive ML systems that switch models at runtime to hold a quality target while using less energy [6], [7].
There's an even broader version of this choice. Warm-blooded animals spend energy keeping their temperature constant no matter what. Cold-blooded ones let their temperature follow the environment. Most always-on services are warm-blooded. Their caches and runtimes stay hot whether or not anyone shows up. Event-driven systems are cold-blooded. Their energy rises and falls with load. Neither is simply better. Staying warm buys you low, predictable latency. Going cold saves energy, but you pay for it each time you have to warm back up. Which is right depends on your load, and having a number for metabolism gives you a way to decide.
I should say what metabolism isn't. It isn't carbon. The same kilowatt-hour can be clean or dirty depending on when and where you draw it, and there's good work on moving jobs to greener hours and regions [8], as well as on where that stops helping [9]. That work changes when you spend energy. Metabolism is about spending less of it. The two fit together.
I should also say where the biology stops working, because borrowed ideas can mislead you if you're not careful. Software has no fixed body, so "size" could mean several things, and they won't all give the same answer. Software doesn't dissipate energy either; hardware does. Assigning a rate to one service running on shared machines is hard, and I suspect it's the hardest part of the whole problem. If you try the experiment above, that's where you'll spend most of your time.
The most interesting mismatch is moral. For an animal, basal metabolism is just the price of being alive. For software, a lot of it is waste. A better design could deliver the same thing for less. That's where the analogy breaks, and it's also where the opportunity is.
If you run a service, you could start small. Measure what it draws when nobody's using it, then what it draws under normal load. That ratio alone will tell you which kind of fix to look for. Do it again after the next few releases and you'll know whether you have bloat. Do it across enough systems and you might find out whether software has its own Kleiber's law.
In the meantime, you might want to check on that cron job nobody remembers writing. It's been awake this whole time.
References
- R. Pereira, M. Couto, F. Ribeiro, R. Rua, J. Cunha, J. P. Fernandes, and J. Saraiva, "Energy efficiency across programming languages: How do energy, time, and memory relate?," in Proc. SLE, 2017, pp. 256–267.
- S. Hasan, Z. King, M. Hafiz, M. Sayagh, B. Adams, and A. Hindle, "Energy profiles of Java collections classes," in Proc. ICSE, 2016, pp. 225–236.
- L. A. Barroso and U. Hölzle, "The case for energy-proportional computing," Computer, vol. 40, no. 12, pp. 33–37, 2007.
- M. M. Lehman, "Laws of software evolution revisited," in Proc. EWSPT, 1996.
- G. B. West, J. H. Brown, and B. J. Enquist, "A general model for the origin of allometric scaling laws in biology," Science, vol. 276, no. 5309, pp. 122–126, 1997.
- S. Kulkarni, A. Marda, and K. Vaidhyanathan, "Towards self-adaptive machine learning-enabled systems through QoS-aware model switching," in Proc. ASE (NIER Track), 2023.
- M. Tedla, S. Kulkarni, and K. Vaidhyanathan, "EcoMLS: A self-adaptation approach for architecting green ML-enabled systems," in Proc. ICSA-C, 2024.
- P. Wiesner, I. Behnke, D. Scheinert, K. Gontarska, and L. Thamsen, "Let's wait awhile: How temporal workload shifting can reduce carbon emissions in the cloud," in Proc. Middleware, 2021.
- T. Sukprasert, A. Souza, N. Bashir, D. Irwin, and P. Shenoy, "On the limitations of carbon-aware temporal and spatial workload shifting in the cloud," in Proc. EuroSys, 2024, pp. 924–941.