Code and Climate Change. Blog about software development in ClimateTech
The Green Software Foundation (GSF) is a non-profit organization under the Linux Foundation that aims to reduce the climate impact of running software. With multiple projects under its belt, GSF is driving the conversation about sustainable software practices. One of the things I’ve heard most about is Carbon Aware Computing, which entails developing software that understands its carbon emissions and adjusts its behavior according to the electricity grid it’s currently running on.
The overarching principle of carbon-aware computing is that you should do more when the electricity is greener, and less when it is not. This is most often accomplished in three ways:
While if your infrastructure provider allows you to do these things easily, such as Cloudflare’s Green Compute, you should absolutely take advantage of it.
However, if you don’t have such tools available, you can still achieve a fair chunk of these benefits by going through your infrastructure once without needing to make your software carbon-aware. Let’s take a look.
While the composition of power grids do vary quite a bit between the worst and the best (Wyoming and Sweden have approximately a 10x difference in CO2 per kWh), the day-to-day or month-to-month differences are much smaller than that.
That means picking a region with a good renewable-heavy grid gets you a long way without needing to shift around location of your compute jobs. Some cloud providers such as GCP even has tools to help you find the best regions based on the carbon emissions.
Time-shifting is an interesting concept. It makes sense because the grid production of renewables compared to the general demand for electricity varies from hour to hour. Many grids however have a daily pattern that can take on the following shapes:
You can look at electricitymap.org to spot the trends that are relevant to your grid. If you do that, you should be able to get most of the advantage of time-shifting by scheduling your jobs during the time when your grid composition is more favourable, rather than needing to schedule it dynamically.
Some of you might be looking at the grid pictures above and (correctly) noticing that there’s a 2x difference between some of my graphs, and wonder what I’m smoking. Reducing your carbon emissions by 50% seems like a huge win.
That wouldn’t be an accurate number though, because actual cloud emissions don’t come from the electricity usage - they come from embodied emissions. Embodied emissions refer to the emissions associated with the production and disposal of servers.
For consumer laptops, embodied emissions make up 75-85% of total emissions, and the general pattern is the same for servers.
Carbon-aware computing only focuses on the electricity use of your servers, and not the production, lifetime and disposal, where a majority of the emissions come from.
This means that in most cases, looking at optimizing how well we use the physical hardware before we have to replace it, is a better use of our time than trying to switch load around.
Cloud data centers typically replace servers every 4-5 years, making it essential to use them as efficiently as possible. Reducing the number of physical servers and utilizing rented servers at as close 100% capacity can significantly lower the environmental impact. Plus it often leads to better use of resources, resulting in cost savings.
So what is the right thing to focus on? If you’re not actively building infrastructure for others to run jobs on, here’s where I think you’ll get the most bang for your buck, in regards to optimizing your computing carbon emissions: