Originally published 16 November 2009.
Green is a great buzzword, but the real-world driver for many “green” efforts is cost. Data center power is expensive. Years ago, Oracle moved a major data center from California to my town Austin, Texas. A key reason: more predictably priced, cheaper power in Texas vs. California. What if Oracle could make the data center half the size and take half the power because its software ran more efficiently?
Your bank, your brokerage, Google, Yahoo, Facebook, Amazon, countless e-commerce sites and more often require surprisingly many servers. Servers have traditionally been power-hungry things favoring reliability and redundancy over cost and power utilization. As we do more on the web, servers do more behind the scenes. The amount of computing power or various subsystem capabilities required varies drastically based on how an application works.
These days, hardware vendors across the IT gamut try to claim their data center and server solutions are more power efficient. The big push for consolidation and server virtualization (the practice by which one physical server functions as several virtual servers which share the hardware of the physical machine) does make some real sense. In addition to using less power, such approaches often simplify deployment, integration, management and administration. It’s usually easier to manage fewer boxes than more, and the interchangeability facilitated by things like virtualization combined with good planning make solutions more flexible and able to more effectively scale on demand.
Ironically, the issue people seem to pay the least attention to is perhaps the most crucial: the efficiency of software. Software orchestrates everything computers do. The more computer processors, memory, hard drives and networks do, the more power they need and the bigger or more plentiful they must be. One needs more servers or more power burning servers the more operations those servers must perform. The software is in charge. When it comes to operations the computer performs, the software is both the CEO and the mid-level tactical managers that can make all the difference in the world. If software can be architected, coded or compiled to be manage more efficiently the operations per unit of work produced goes down. Every operation saved means power saved.
Computers typically perform a lot of overly redundant or otherwise unneeded operations. For example, a lot of data is passed across the network not because it absolutely needs to be, but because it’s easier for a developer to build an app that operates that way or the application to be implemented that way in production. There are applications that use central databases for caches when a local in-memory cache would not only be orders of magnitude faster but also burn less power. Each time data goes across a network it must be processed on each end and often formatted and reformatted multiple times.
A typical web service call (REST, SOAP, etc) – the so-called holy grail of interoperability, modularity and inter-system communication in some communities – is a wonderful enabler, but it does involve parsing (e.g. turning text data into things the computer understands), marshalling (a process by which data is transformed typically to facilitate transport or storage) and often many layers of function calls, security checks and other things. The use of web services is not inherently evil, but far more carbon gets burned to make a web service call to a server across the country or even inches away than it is for the computer to talk to its own memory. It’s also a lot slower.
Don’t get me wrong, I’m a big believer in the “army of ants” approach. However, I see the next big things in power utilization being software driven. We’re going to reach a point where we’ve consolidated all we reasonably can, and at that point it’s going to be a focus on making the software more efficient.
If my code runs in a Hadoop-like (Hadoop is open source software that facilitates computing across many computers) cluster and the framework has tremendous overhead compared to what I’m processing, how much smaller could I make the cluster if I could remove that overhead? What if I process more things at once in the same place? What if I batch them more? What if I can reduce remote calls? What if I explore new languages like Go with multi-core paradigms? What about widely deployed operating systems like Linux, Windows and MacOS become more power efficient. What about widely used apps consuming less power hungry memory? What about security software taking fewer overhead CPU cycles? Can we use multi-core processing more efficiently?
In most cases, performance boosts and power savings go hand-in-hand. Oriented toward developers, here are a few more obvious areas for improvement. Most are pre-existing good software design practices:
– Caching is the first obvious place: (1) more caching of information, (2) less reprocessing of information, (3) more granular caching to facilitate caching where it was not previously done.
– Data locality: Do processing as close to where data resides as possible to reduce transportation costs. Distance is often best measured not in physical distance but in the number of subsystems (both hardware and software) that data must flow through.
– Limit redundant requests: Once you have something retrieved or cached locally, use it intelligently: (1) collect changes locally and commit them to a central remote location such as a database only as often as you need to, (2) use algorithms that can account for changes without synchronizing as often with data on other servers.
– Maximize use of what you have: A system is burning power if it’s just on. Use the system fully without being wasteful: (1) careful use of non-blocking (things that move on instead of having the computer wait for a response from a component) operations in ways that let the computer do other things while it’s waiting; (2) optimize the running and synchronization of multiple processes to balance use, process duration and inter-process communication such that the most work gets done with least waiting or overhead.
– Choose the language, platform and level of optimization based on amount of overall resources consumed: Use higher performance languages or components and more optimizations for sections which account for the most resource utilization (execution time, memory use, etc.). Conversely, use easier to build or cheaper components that account for less overall resource use so that more focus can go to critical sections. (I do this in practice by mixing Ruby, Java and other languages inside the JRuby platform.)
In certain applications, maybe we don’t care about power utilization or much at all about efficiency, but as applications become increasingly large and execute across more servers development costs in some scenarios may become secondary to computing resources. Some goals are simply not attainable unless an application makes efficient use of resources, and that focus on efficiency may pay unexpected dividends.
Developers especially of large-scale or widely deployed applications, if we want to be greener let’s focus on run-times, compilers and the new and the yet-to-be-developed paradigms for distributed massively multi-core computing.
There is a story that Steve Jobs once motivated Apple engineers to make a computer boot faster by explaining how many lifetimes of waiting such a boost might save. Could the global impact of software design be more than we imagine?
[ Edit 14 October 2018: See also: Math Pierces Steve Jobs’ Reality Distortion Field after 35 Years. ]
Eric Tucker 