With all the different technologies, methodologies, and platforms available to software engineers, we all still share one thing: the planet. All of the software we write emits carbon in some way and by 2040, software is expected to account for 14% of all global emissions. It is important to understand the impact our own systems and software have on our planet and how we can best minimize their emissions.
Before diving into the measurement and setting Service Level Objectives (SLOs), let’s go over some background information on carbon and how we quantify it. The first thing to know is that “carbon” typically refers to Carbon Dioxide Equivalent (CO2e/CO2eq). All greenhouse gasses (GHGs) impact the planet in different intensities. For example, methane is much more potent than carbon dioxide, but its effects last about 10-12 years compared to centuries for carbon dioxide. CO2eq is a way of normalizing all GHGs. Carbon is emitted in order to create energy and our energy grids have a mixture of energy sources that they use to meet current demands. When the sun isn’t shining or the wind isn’t blowing, other forms of energy like coal and gas are used to supplement and meet the energy demand. This fluctuating carbon emissions value is known as Carbon Intensity and it is measured by how much carbon it takes to generate one kilowatt hour of electricity at any given time. Additionally, carbon is broken down into three different scopes to classify who or what is responsible for those emissions:
Scope 1: Direct emissions from operations owned or controlled by the reporting organization, such as on-site fuel combustion of fleet vehicles.
Scope 2: Indirect emissions related to emission generation of purchased energy, such as heat and electricity.
Scope 3: Other indirect emissions from all the other activities you are engaged in. Includes all emissions from an organization's supply chain, business travel for employees, and the electricity customers may consume when using your product.
Source: Green Software Foundation
The Green Software Foundation has recently introduced a specification for measuring your own software carbon intensity called SCI. The equation itself contains four parts: Energy, Carbon Intensity, Embodied Carbon, and the Functional Unit of your system. Using these four inputs, you can accurately calculate your software’s carbon intensity. Let’s look at an example:
SCI Example
Scenario: One Azure VM running at 50% average load for 24 hours in West Europe region
Energy
To calculate the energy consumed by a machine, you need to calculate the power consumption of the CPUs, GPUs, and Memory. To simplify this scenario, I am going to use an Azure VM type of D8as v4. According to the Azure documentation, this VM type uses an AMD EPYC 7452 processor which is specified as having 155W thermal design power (TDP). Running this processor at 50% load for 24 hours consumes 1,860 watts hours, or 1.86 kWh (TDP * Load * Hours). The D8as v4 virtual machine has 1 CPU, no GPU processors, and 32 GB of memory. As a rule of thumb, 8GB of RAM consumes about 3W of power so the memory power consumption would be 12W. In this scenario we can ignore the GPU requirements as the D8as v4 machine does not have GPUs. Now we can multiply our CPU energy consumption by the number of CPUs (1) to get 1.86kWh
1.87kWh = (1 CPUs * 1.86 kWh) + 12 W memory power + (0 GPU cores * 0 GPU power)
Carbon Intensity
For this scenario, we have placed our virtual machine in the Azure West Europe region which is located in the Netherlands. According to data from Electricity Maps, the energy grid in the Netherlands fluctuates mostly between wind, solar, and gas. Looking at a 24 hour representation of carbon intensity for this region shows how the intensity can change based on demand, weather, and availability. In this example, we see an average of 265 gCO2/kWh over the 24 hour period.
Embodied Carbon
Scope 3 carbon is something referred to as embodied carbon as it is the carbon required to create, install, and decommission your machine. This value is typically a constant that won’t be impacted by the usage and is different from the operational carbon associated with energy consumption and carbon intensity. The open source project Cloud Carbon Footprint is a great source for embodied carbon data for public clouds machines. Based on their calculations, an Azure D8as v4 machine has 1560.4 kgCO2eq of embodied carbon. If we assume that a machine will last for 5 years, that means each year accounts for 312.08 kgCO2eq and every 24 hours is 855 gCO2eq.
Functional Unit
Each software system is different and scales in different ways. Some systems grow by number of users or number of devices while others may scale by storage amounts. For this example, our system scales by number of requests so we will set a rate of 10 requests per second, or 864,000 requests per 24 hours.
Once these 4 values are determined, we can plug them into the SCI equation to get a result of:
0.00156 = ((1.87 * 265) + 855) / 864,000
We have now created a Service Level Indicator (SLI) for our software carbon intensity of 1.56 emissions rate per 1,000 requests. This SLI can now be plugged into SLO calculations based on your own business scenarios.
Now that you have set your SLO you need to be able to impact the metric and drive down your software carbon emissions. Every action you can take to reduce software emissions will fit into one of these three areas: Use less hardware, use less energy, and use energy more intelligently. By reducing the amount of hardware, you reduce the amount of embodied carbon and energy your system emits. Increased utilization, reducing the total number of machines, and extending the lifetime of your existing machines are all actions that will help here. Switching to lower power CPUs, finding efficiencies in your code, or using GPUs as much as possible will drive down your energy usage. Using energy more intelligently is often called being carbon-aware, where your system is able to change its behavior based on the amount of carbon in the energy grid. A good example of this is delaying batch jobs until greener periods or moving your virtual machines to regions that have more renewable energy.
In the end, reliability of a system is about balancing the operational and technical choices and priorities for that system. Over time, those choices impact the planet in some way. We need to incorporate a systems-level thinking approach that looks at our infrastructure and code not just as an isolated system, but as part of a larger ecosystem of the planet. The largest coal-powered machine in the world is the Internet and we need to take action now to mitigate the worst of the effects. A habitable planet is the ultimate reliability problem and taking accountability for the impact our systems and software have is a great first step.
