Software In a Sustainable World
The technical director at Google Cloud discusses the harmful impact of software on the planet and how steps can be taken to mitigate this.
This year marks 75 years since the first digital software was written. It's become a new and widespread human discipline, daily touching most people on the planet through the work of some 27 million software developers, plus millions more associated people.
Like all vibrant disciplines, making and running software is sustained by reflection and the remediation of old practices. There is one practice in particular that has become harmful for both the discipline of technology development and for the planet. It's software's role in adding to atmospheric carbon. Here's how we begin to change that.
How We Got Here
Let's begin by thinking about how software contributes to atmospheric carbon, a key element of global warming: The computers on which programs run consume a lot of electricity, the generation of which, according to the US EPA, electricity and heating is the single greatest source of global greenhouse gas emissions. It is therefore critical to focus on where and how the software is being executed on technology platforms, to minimize the amount of atmospheric carbon we create.
There are steps that can be taken immediately, such as using more energy-efficient data centers, or choosing computing partners that champion renewable energy sources (more on that below.) Beyond single actions, though, our industry needs to focus on its systemic behavior and wasteful practices. Small changes now will have a massive impact over time.
We need to rediscover our roots when physical technology constraints made every byte precious. The practice of writing software initially had constraints due to high technology costs, particularly in processing power and memory. Both Steve Wozniak at Apple and Paul Allen at Microsoft, along with many others, were renowned for how much their code could do with limited resources. Then, decades of advances in hardware gave a sense that computing resources, first on servers, then on networks, hosting centers, and clouds, was abundant.
This illusion of abundance made it less necessary to budget memory and computing, even cost, just as the demand for software - on phones, tablets, cars, and myriad other devices besides computers - exploded. We focus on availability and reliability, for example error budgets are defined by practices of Site Reliability Engineering (SRE), in the interest of maintaining productive uptime.
The result was computing languages that used more processing -- architectures that didn't adapt to changing needs -- and increased hardware resources, with little eye to the amount or type of electricity they'd consume.
The Discipline of Solving the Problem
How do we walk this back? We return to budgeting, with a focus on carbon.
A software discipline of Minimal Carbon Engineering, like other budgeting disciplines, looks at virtually every aspect of software production and deployment, with an eye to minimizing the carbon consumed. It can be seen as something like what SRE has been for errors, or Continuous Integration/Continuous Deployment for continuous process improvement, only this time focused on metrics of carbon consumption.
This may be as small as using purpose-built semiconductors for artificial intelligence, compared to generic chips, or as large as the choice of hyperscale cloud providers and regions. It involves revising practices, such as reducing the amount of data meshed and copied in repetitive exercises, reducing the number of "idle" resources (which still use carbon), automating some code, and archiving little-used data, and balancing less energy-intense languages, like C, over languages like Python, which tend to use more.
The idea is not to eliminate but understand and make sustainable decisions in the use of technology in appropriate places. In every case, these are choices up to individuals and teams, using easily determined metrics on the amount of carbon expended. They touch on roles in the process including, but not limited to, product managers, architects, software development engineers, data engineers, and data scientists.
Personal and Corporate Action
There are important personal choices in Minimal Carbon Engineering, too. Last year I tracked my carbon budget in switching to a cloud-connected Chromebook with an eco-screen and compared it to the carbon used by a desktop with a normal screen. With that simple step, I saved 3,500 kilograms of carbon, the equivalent of driving 8,000 miles in the lifetime of the products I use.
That was one act, by one person, that might be replicated by millions of individuals. When these behaviors move to the cloud, the differences are stunning. In the case of Google Cloud, our AI-optimized data centers are twice as energy efficient as the industry average, effecting seven times the computing power from the same amount of energy, compared with five years ago. We've matched our electricity consumption with 100% renewable energy since 2017. Most importantly, we're on track to operate solely off renewable energy by 2030.
There's room for individual choice within the cloud to improve net outcome even more. For example, using tools to weigh price, latency, and carbon output, developers work not only in code, but its consequences. Building in modern frameworks like Kubernetes enables greater portability to lower-carbon environments, while employing automated production services can shut down code when it's not needed.
As with all budget disciplines, net expenditures need to be put in one place and counted using tools like carbon footprint. As the budget discipline of Minimal Carbon Engineering takes hold, we can expect to see more and better tools for counting and auditing carbon expenditure. This is an increasingly important feature for regulators, governments, and industries everywhere, along with engaging an increasingly environmentally conscious workforce. Better data, in turn, can mean further improvement, something like a sustainable CI/CD approach to lowering carbon production.
Seventy-five years on, software's importance to the world is continuing to grow. As the world grows more aware of the issues surrounding software and carbon, the discipline of building for minimal carbon is a critical, and hopeful, feature of our future industry.
About the Author
You May Also Like