
Sustainable software – how to close the metrics gap
Measuring the environmental impact of your software is a complicated task. In the first of a two-part blog, we look at how best to obtain estimates of...
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.
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.
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.
All in all, it’s a real boon to development teams who want to standardise and automate their carbon metrics.
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.
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
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:
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.
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.
Loading...