Blog

Sustainable software – automating carbon metrics

Getting reliable estimates of energy use is important for driving sustainability improvements. But it can be challenging. In our second blog on measuring sustainability, we look at how new tools can make it easier to obtain and automate your carbon metrics.

In the first part of this blog, l looked at how reliable estimates of energy use by your software is the basis on which you can produce reasonable, actionable carbon metrics that can drive sustainability improvements.

In this second part I look at how new tools such as the Green Software Foundation (GSF)’s Impact Framework can make this process easier, how we also need to include embedded sustainability impacts – and how we can use the same techniques to measure the impact of software on other areas, such as water use.

Adam Coles: Head of Sustainable Services

Tools for measuring carbon

In part one, we discussed some tools for calculating your carbon footprint, whether from vendors or open-source solutions. These tools are excellent for reporting carbon usage and setting annual reduction targets that align with your net-zero goals.

However, as software professionals, our need for data is immediate. We want to design and build carbon-efficient software right from the start, rather than waiting until the year's end to assess our impact.

This is where the Software Carbon Intensity (SCI) specification becomes invaluable. The SCI is a standard that allows us to measure and report the carbon emissions associated with a measurable part of our software throughout its lifecycle. By integrating SCI measurement into the development process, you can get the high-quality, quantitative feedback needed to make real-time adjustments.

In agile development, we rely on short feedback loops to iterate and improve our code continuously. This iterative process hinges on accurate metrics – for example, improving HTTP request/response times by 50% can be tracked through performance tests. Similarly, the SCI specification helps us to track the carbon intensity of our software in the same way. When our process SCI score declines we can start to identify the reasons, allowing us to propose and implement solutions to get back on track.

Calculating carbon intensity

The basics of the SCI are deceptively simple. The SCI of a software component is measured as:

SCI = C per R

where C is the amount of carbon the software causes to be emitted and R is the ‘functional unit’, you are measuring (eg additional user, API-call, or ML training run). The fact that it is up to you to define R means both that the measurement of a software system will be made up of a number of SCI measurements and that the scope you have for choosing what to measure is incredibly wide.

Because we know what leads to carbon emissions we can expand out C to (O + M), where O is the carbon produced operationally and M is the embodied carbon (ie the carbon emitted during the construction of that hardware) you are responsible for in the hardware you are using to run the software. If we all weren’t using that hardware it wouldn’t be built – so we are responsible for a proportion of it when our software runs, based on the percentage of lifespan and resource you use.

SCI = (O + M) per R

We know from part one of this blog that we can’t usually directly measure the operational carbon of software, so we can replace O with (E * I) where E is the amount of energy consumed and I is the carbon intensity of the grid during that period. So

SCI = ((E * I) + M) per R

You can read more about how this works and how you can break down M further in the official specification.

The SCI (now an ISO Standard) is an incredibly powerful tool for standardised measurement of carbon emissions from software, though with its great power comes great responsibility to define what you want to measure, where you are going to set the boundaries of measurement (eg are you just looking at the emissions of the function you’re calling or every service it depends on, are you counting the emissions of the end-user device that is making the call?).

We are still left, however, with the problem of how to measure that carbon in the first place (see part one of the blog).

This is where the Impact Framework comes in. The IF, another project in development by the GSF is a lightweight, modular application that allows you to build up a set of measurements based on observables (often CPU readings) and known quantities (such as the type of compute instance you have reserved).

A series of plugins can take these data points and, using a combination of empirically derived databases and APIs, give you good estimates for energy, carbon emissions and even impacts beyond that. Native plugins can even calculate the SCI score automatically.

The tool can be run standalone, automated in pipelines or run periodically in production environments to produce near-real-time metrics – precisely the feedback development teams need to take action on sustainability improvements. And the beauty of this framework is that all of your methodology for calculation is stored in a single manifest file that can be shared with the team and the wider world to prove your transparency.

A typical impact framework pipeline

The simplified diagram shared here shows part of a typical impact framework pipeline, highlighting three inputs – the electricity grid carbon intensity, CPU energy use and the CO2 emissions embodied in the hardware and how the SCI plugins combine those inputs into a single SCI score.

All in all, it’s a real boon to development teams who want to standardise and automate their carbon metrics.

Typical impact framework pipeline

Going beyond carbon

At the end of part one of this blog, we understood some of the techniques and tools we can use to estimate the operational carbon impact of our software services. This is vital for us to address the climate crisis by reducing the carbon cost of the services we produce. But it’s not the end of the story.

Modern software services run on hardware and in datacentres that sit at the top of a bewilderingly complex, global pyramid of resource extraction, manufacturing, construction and transport.

A server may contain aluminium, antimony, arsenic, barium, beryllium, cadmium, chromium, cobalt, copper, gallium, gold, iron, lead, manganese, mercury, palladium, platinum, selenium, silver, and zinc – all extracted from different parts of the world, in different ways and manufactured into a variety of components that add up to a single rack component. Oil is used to manufacture cases and fans. Datacentres are constructed from concrete, steel and plastics.

Extracting and consuming these resources has major ecological impacts. More electricity is used in the mining and construction processes, producing more carbon emissions. Massive amounts of water are used both in these supply chains (eg concrete and steel production, chip fabrication). And further large amounts of water are used in most datacentres to cool the environment and keep hardware running efficiently.

We know we live in a time of water stress, particularly in warmer or more arid regions of the world where many datacentres are constructed. Water use by datacentres is starting to impact on local populations, agriculture and wildlife. So, as sustainable development teams, we have to take water usage, both operational and embedded, into account when building our software and choosing our cloud infrastructure.

Operational water use by software

As part of the GSF’s Carbon Hack 24, Opencast decided to look more closely at how we can measure the water use of software. Using the SCI as a model we postulated an “SWI” measure defined as:

SWI = ((E*(I1+I2)) +M) per R

where 

  • E is the energy consumed by software, in kWh
  • I1 is the water used for producing electricity, per kWh of energy in Litre/kWh
  • I2 is the water used for cooling data centres, per kWh of energy in Litre/kWh
  • M is the water used during the creation and destruction of hardware that the software is running on
  • R is the functional unit.

At this point you may be concerned about yet another thing we’re going to have to try and measure! But we already have many of the building blocks we need to calculate the SWI. Remember we can extrapolate most figures from our original observables, or from the energy estimation. And again, the Impact Framework’s flexibility is crucial in being able to take those figures and produce estimates of the water use based on:

  • energy consumed
  • historical data on what energy sources the grid was using when the energy was consumed (different generation sources consume different amounts of water)
  • estimates for the water usage effectiveness (WUE – measured in litres per kWh of energy) of the data centres involved.

We created several plugins to estimate these measures and generate a final SWI figure – and that was it! We now had a pipeline that would tell us, every time it was ran, how much carbon and water we were responsible for every time we called an API end-point.

The Impact Framework can be expanded to cover any type of impact for which you can make good estimations and have good datasets. We’ll hope to use this more as it matures further in the future.

Operational water use by software

Final thoughts

Measuring your sustainability impact is a huge topic and we have only touched the surface in these two parts. We’ve learned that:
  • there are a variety of tools out there which we can use, with caveats, to measure our carbon impact but beware the small print
  • we can estimate energy and carbon use from figures we do have available, like CPU usage
  • we can go beyond carbon to measure the other impacts our software has on people and the planet.

We’re at the early stages of a sustainability step change in software and digital services and these techniques and tools will only get better. We should all look forward to a future of easier, more consistent, sustainability measurement – but right now we can create estimates that are good enough to be both actionable and impactful.

Authors

Adam Coles

Head of Sustainable Services

Related insights

Loading...