Calculating software carbon intensity

Discussions regarding carbon emissions with regard to connected devices tend to center around hardware. Rarely is software considered ‘guilty’ of contributing anything to a gadget’s carbon footprint. But this is far from the truth. Even if incremental, the deployment and subsequent usage of software does indeed add to the carbon emissions a device generates. 

In fact, the software industry is responsible for about three percent of global carbon emissions — very close to that associated with the aviation industry. However, while airline carbon emissions are more tangible, software carbon emissions are much less so. 

Consider a laptop. The electricity a laptop needs to turn on and stay on involves some amount of emissions during its generation. This is what is called base carbon emissions. Now consider all the software running on top of the device’s hardware. This immediately contributes to even more energy being used by the gadget, because both battery and RAM usage increases. 

As a result, the software can be said to be emitting emissions via the hardware.

This is why there is growing interest in the industry to attempt to create ‘green software’—or software which emits less carbon. But how is one to know how much carbon a particular piece of software is emitting? As Peter Drucker said, “If you can’t measure it, you can’t improve it.”

This is where the work the Green Software Foundation (GSF) is doing becomes especially relevant. Created by a group of companies in the IT industry — including Microsoft, GitHub and Thoughtworks — the foundation is driven to create a standard with which technologists can be guided to write software that is environment friendly. 

Which brings us to the next question: how can carbon emissions in software be measured in the first place?

Measuring Software Carbon Intensity

To help address this question, the GSF has created a standard called the Software Carbon Intensity (SCI) specification. It defines a methodology for calculating the rate of carbon emissions for a software system. 

Software Boundary

The foundation recommends that calculations should be done by keeping just one component of a software system in mind at a time. Whether the SCI for storage is being calculated or an API, it is important that calculations are done in a way that respects the boundaries of a software system. 

This is important because calculations need to be made for every component of a software system before the SCI of an entire system can be determined. Consider another example where we’re creating a backend API which returns the list of products (a product API), and, for now, we are running this API locally — it hasn’t yet been deployed. Now, before we can calculate the carbon emissions of this particular product API, we first need to look at the laptop on which it is running. It might be idle, but an idle machine requires energy to run — we need to calculate them if we’re going to get an accurate view of everything that’s going on.. Once we’ve done that and applied a standard formula, we can calculate an idle machine’s emissions (SCI).  Then we can deploy the product API on top of it and measure the SCI again. It’s evident that the difference between the two will provide the carbon intensity of the product API. It’s important that when you make repeat calculations you consider any changes — such as the machine on which the API is running — into account.

There are many examples of software boundaries. The Green Software Foundation provides some examples on its website: 

• Compute resources

• Storage

• Networking equipment

• Memory

• Monitoring

• Idle machines

• Logging

• Scanning

• Build and deploy pipelines

• Testing

• Training ML models

• Operations

• Backup

• Resources to support redundancy

• Resources to support failover

Functional Unit (R)

But the question we need to ask ourselves is this: will it be the same in all cases? What if the number of products added to the laptop is increased? Or, alternatively, what if the number of API calls being made are increased? The carbon intensity will differ even when the same software boundary has been chosen because the intensity of carbon emission will differ according to the units of energy used.

And what this, in turn, depends on is scalability. This is not too different from the scenario in which technologists concern themselves with challenges around scaling a piece of software in the DevOps world. 

In the language of SCI specifications, the smallest unit at the level of which carbon intensity matters is called a functional unit. Take, for example, a product API. If I have to calculate its SCI, as a first step I will take its smallest functional unit. The SCI standard mandates that we calculate, improve, recalculate and keep on improving for lower carbon emissions. It doesn’t matter when the eventual recalculation is scheduled, what must remain constant is R, the functional unit. 

As said earlier, energy is calculated by comparing how much power is used when running an API versus how much power is being used when not running it. In certain situations, this is simple — when there is a voltmeter readily available, what needs to be done is to simply calculate the energy spent. But what about when clouds are involved?

All four major cloud providers have designated a place on their websites where software developers can see the energy that your services are consuming. However, what if you’re not working with one of these cloud providers and you don’t know the details of energy consumed by your work load, then how can you know how much energy you are consuming?

The SCI Equation

The equation of SCI is:

SCI = (E*I) + M per R

Let’s understand it. We have already seen R, let’s go to E now.

Energy consumption (E)

Every cloud provider can provide specifications of the hardware being used. And every hardware provider will be able to provide details about the energy their product’s RAM (for example) typically uses. Taking that data, it’s possible to calculate the CO2EQ (carbon dioxide quivalent) for 1 kilowatt/hour of energy.   

Location-Based Marginal Carbon Intensity (I)

One more question may arise: if I know how much energy my software is using, how do I convert that to its carbon equivalent? There isn’t a single universal formula to calculate this, but every region does have its own standard. In Australia, for example, there is a standard for how much carbon is produced for every kw/h of energy used. In the formula for calculating SCI, this is known as Location-Based Marginal Carbon Intensity — often written as ‘I’. When taken with ‘E’, ‘I’ with ‘E’ is called ‘O’, that is, operational emissions— how much carbon is being generated to perform a certain operation. 

Embodied carbon (M)

Embodied carbon (otherwise referred to as “Embedded Carbon”) is the amount of carbon produced during the creation and disposal of a hardware device.

When software runs on a device, a fraction of its total embodied emissions is allocated to the software. This is the value of M that you need to calculate in the SCI equation.

This fraction consists of both a time-share and a resource-share. The length of time your software runs on the device determines the time-share. The percentage of the device reserved just for your application during the time-share determines your resource-share. Unlike our earlier calculations, we don’t get energy consumption which we need to later convert to CO2EQ, here, it’s made easy for us, we directly get CO2EQ.  

Conclusion

Carbon emissions often fail to be taken as seriously as other considerations in software development. However, it absolutely must be considered in day-to-day software development practices; building in the capacity to measure and monitor carbon impact into our CI/CD pipelines could be a good place to start and will set us up to move forward. We all have responsibilities towards the environment — whatever work we do and wherever we do it. Thinking carefully about SCI can be a huge step towards making software more environmentally friendly.