Building Green Software by Anne Currie, Sarah Hsu and Sara Bergman, published by O'Reilly is available here under a CC BY-NC-ND Creative Commons license i.e. you can read it and quote it for non commercial purposes as long as you attribute the source (O'Reilly's book) and don't use it to produce derivative works.

You can buy the book from good bookstores including Amazon in all regions (currently on offer in the UK). or read it on the O'Reilly site if you are an O'Reilly subscriber.

Chapter 9  - Measurement

“An experiment is a question which science poses to Nature and a measurement is the recording of Nature's answer.”

― Max Planck, 

Metrics, measurements or monitoring, whatever you choose to call it, software practitioners like numbers and charts that indicate our progress. Perhaps this is due to the intangible nature of our field? Or maybe all types of professionals who dedicate their time to building things are as obsessed with measurements. Whatever the reason, some very commonly asked questions when talking about green software are “how can I measure it?”, “how do I know my impact?”, and “which part of my software has the biggest impact?” In this chapter we will dive deeper into these questions and offer you some options on how to answer them.

In a perfect world, every item would have a neat carbon price attached to it, clearly showing the climate impact of each action we took or each product we purchased. That way we could always make informed choices with regards to climate. But as you have noticed in shops, that is not the case today. However, in this chapter, we will go through what “as close to perfect as you can get” would mean for software. Because we are opinionated people, we will also tell you what we would like to see the industry move towards: the real-time monitoring of carbon emissions. And for good measure, we will also tell you what the “good enough” measures are and when and how you can use them.

As with most things, we are of course not the first people to ponder these issues (thankfully). Therefore, we will also go over the current methodologies that other smart people have already put forth for our consideration. The goal is not to rate them, but to inform you of their strengths and weaknesses so you can know when to use which and for what.

Does calculating your own carbon footprint sound a bit much? Well you are in luck, because not only do we already have standards, there is also tooling available! All the major public clouds have their own tooling and the wider community have also supplied varying degrees of open sourced tooling for you to benefit from.

The goal of this chapter is to make you go from “What is my footprint?” to “I know my footprint, now which action do I start with?”

The Perfect

By now, you know the basic building blocks for what makes software greener and this gives you an understanding of what you need to measure. You have learned in Chapter 2 that energy utilization, embodied carbon in hardware, and the carbon intensity of the grid have a role to play in how green your software is. What would be the perfect way to measure each of these?

Before that we need to talk a little bit about scope. Today’s software is rarely nicely scoped to one single machine over which we have complete control. No, software today spans many machines, abstraction layers, networking and other types of hardware devices, which on top of it all is frequently shared with other software and/or data. In order to measure the emissions of our software, we need to decide the system limitations of our software. For a web application, that might be the virtual machine in a cloud, the networking equipment to send data from said cloud to the end-user device, for example a phone, and said end-user device. It is also useful to consider the temporal boundaries of our software, e.g. how does it behave over time. For our web application, it might consist of active user usage, such as a user clicking on a button, as well as passive usage, such as update installs. We will find that some of these are easier to measure and some are harder or practically impossible due to, for example, limited data access.

The next few sections will introduce how to perfectly measure energy, carbon intensity and embodied emissions. These values can then be used in one (or several) of the standards which are introduced in the section “Examination of the Current Methodologies”. 

Perfect Energy Data

Let’s start with energy, because likely it is the first thing that springs to mind when you think about how software produces emissions. The perfect source of energy data for your software would be in real time and able to scope to the granularity you currently desired. For example, on a service or process level, or why not on a per-line-of-code level? Could you measure this on your own? Yes, but it might be a bit cumbersome.

If your software runs on a device which you have physical access to, then the most reliable way is also the simplest way. Buy a cheap watt hour meter, plug it into the socket between your wall and your hardware and you are golden. If you have not used a watt hour meter before, they are a small measuring device that can measure the electrical power passing through a circuit at a certain time. That electrical circuit can be anything from your entire home or a small hardware device, like your phone. This will always be the best way to measure energy consumption because it will measure exactly what your hardware consumes. There are some caveats to be aware of here:

• Any hardware will consume power when idle, called static power draw. Consider this a baseline energy consumption. If you are interested in absolute numbers for your application, then you will need to measure the baseline consumption and then subtract it from the overall consumption measured when running the application. (This is something we can also make use of when it comes to energy proportionality, but more on that in Chapter 2)

• Always start measuring from Steady State (SS). You might remember from high school electronic classes (if you took those) that whenever an electrical component starts up, you can observe a transient event, often an oscillation, which is a sudden burst of energy. You don’t want to include this in your tests, so start measuring when you can observe SS.

• If your device has a battery, it needs to be fully charged and plugged in when measuring. Otherwise, you will end up measuring the power consumption of charging your battery, which can be interesting, but not what we are going for here.

If you do not have physical access to your device, there are multiple ways to instrument your software or hardware to extract this data from the device as well. How you do this depends on how your system looks and operates. It might be possible to get from your operating systems or from the orchestrating software you use for example.

In general though, this works great in a lab-like environment or for less complex pieces of software. However, doing real-time energy measurements in large scale systems which span many abstraction layers is another matter, as you will quickly realize. It is entirely possible but, for many of us, it might be more worthwhile to leave the development cost of energy instrumentation up to someone else. Like your ISP (Internet Service Provider) or your cloud provider. But even when we leave it up to someone else, the criteria mentioned at the start still holds, ideally this data should be in real-time and provided with sufficient granularity.

One swallow does not a summer make. In the same way, perfect energy does not a perfect carbon metric make. Energy is the first part of the equation, let’s explore the others.

Perfect Carbon Intensity Data

In theory, all energy is created equally. An electron from a solar cell will make your light bulb light up in exactly the same way as an electron from a coal power plant. In practice, the impact on climate and our perfect carbon metric, however, differs widely. We have already covered this in Chapter 2, so I won’t go into further details here. But how can we perfectly measure this?

A simple wattmeter or some code instrumentation won’t do the trick here. Generating a perfect carbon intensity signal takes deeper understanding of the energy grid, as well as data access. Similarly to energy data, however, we would like for this data to be in real time and sufficiently granulated, this time in regards to location and time of day. We want to combine our energy usage data with the way the energy was created, this way we will get the carbon metric for the energy portion of our software.

Most often this carbon intensity data will come from third party providers, either directly from the grid operators themselves or from an organization which aggregates data from multiple grid operators, like WattTime API or Electricity Maps. If you get the data from the grid operators, it will likely be from a public data set of historic carbon intensity, like the data set provided by Our World in Data, not real time data. Organizations like WattTime API and Electricity Maps provide API based access to real-time, historical, and forecast carbon intensity data with high granularity. 

https://github.com/Green-Software-Foundation/community-wg

Even if we get this data from a third party provider, there are several types of signals we can get access to here and they provide us with slightly different types of data. Some examples are:

• LRMER: Long-run marginal emission rates

• SRMER: Short-run marginal emission rates

• AER: Average emission rates

There is a lot we could say here but for now, let us just consider that perfect data here is likely something you cannot instrument on your own. Fear not, software based access to perfect data is still possible for many parts of the world. But wait, you think, what about carbon offsets? Or power purchase agreements? In the next section we will dive deeper into the economic measures of carbon intensity and electricity.

Where Do Market Based Reductions Fit In?

Let’s talk economics for a bit! We promise, only a little bit. Market based reductions, or strategies, are in essence an economic tool to change the carbon footprint of something. We can neutralize emissions and thus claim a lower carbon footprint for our operations. Similarly purchase renewable energy production through an agreement while actually using non-renewable sources to power our operations and claim carbon neutrality. These are inherently economic measures different from eliminating carbon, but they are interesting and well-used, so we want to spend some time talking about them. What does “economic measure” mean in this context? The electrons that we use are always going to be the electrons that we use, due to the nature of the electricity grids, we cannot pick and choose. What we can pick and choose is what we pay for.

Power Purchase Agreements (PPA) are one example of this type of market based measure. A PPA is a long-term contract between a producer and a consumer of energy, typically guaranteeing that the consumer purchases a fixed amount or percentage of the energy production. This can either be at a fixed rate or at a market-based price depending on the contract. A PPA agreement can be set in varying degrees of locality, either from a plant right next to your data center (or other planned consumer of energy) or from a plant in a different country. 

This method is often used as a way to finance new renewable energy plants, as it gives the producer a certainty of being able to sell the energy they eventually produce. This concept is called additionality and it is something that over time encourages the creation of a fossil free grid. PPAs are popular. In 2021 more than 137 companies in 32 different countries purchased them. The tech sector is one of the top consumers of renewable energy through PPAs, with Amazon, Microsoft and Meta being the top-3 consumers in 2021 and Google coming in 6th place. 

Offsetting is another market based measure which happens after the energy market itself. This is again a relationship between a producer of the carbon offset, or a carbon credit, and a consumer of the same. A carbon offset represents a fixed amount of carbon reduction or removal and this carbon offset can be purchased. These transactions are regulated by governments or independent certification bodies on the voluntary carbon market. Both individuals or organizations can purchase carbon offsets on this market to reach their intended carbon offsetting goals. The actual offsetting, e.g. not the selling and buying part, can be done in several ways. Perhaps most familiar to you are reforestation projects or carbon capture initiatives. As you can imagine, due to the nature of this market, some of these offsets can be hard to track and confirm the validity of, which has been and continues to be a reason for criticism of carbon offsets. One measure to combat this is the existence of several global standards that carbon offsets must meet, such as Verified Carbon Standard (VCS) and Gold Standard (GS).

There are more tools we could talk about here, like abatements, neutralization or compensations, but we’ll leave this for additional reading for the interested ones. For now, how do these fit into our perfect measurements?

There are different schools of opinions here, some say market based reductions are fair game and can always be included in carbon reporting. Others say they have questionable effectiveness and should be reported separately. For the sake of measuring software, we think that they muddy the picture for people like us, who want to know the carbon footprint of our software in order to make it smaller. Any potential offsets in the future does not impact the current intensity of the software, which is what we care about.

In a Net Zero strategy, elimination of emissions is critical to reach our targets for 2045. The Science Based Targets initiative (SBTi) Net Zero standard, which is currently used by 4000 corporations, states that most companies will need to set long-term targets to cut 90% of their emissions before 2050. Because market-based reductions make it harder to measure emissions removed from your own software, we consider market-based reductions to have no place in a so-called perfect carbon metric. We should say that this does not mean all market based reductions are bad, or that they should not be used. Only that they complicate the actionability of a carbon metric of software.

Perfect Embodied Carbon Tracing

The final part in our perfect carbon metric is the embodied carbon part. Sadly, another piece of data that is difficult to instrument on our own, simply because you rarely produce hardware on your own and thus have limited insight into the process. What you need from our manufacturers is some kind of start value, e.g a total cost for the manufacturing of the device. The amortization of this spent cost is then something you can have full control over. You can also reason over the cost for recycling or destroying the device at its end-of-life in the same manner.

As we learned in Chapter 2, hardware comes with an already built-in carbon debt, this carbon is already released into the atmosphere and we cannot change this, only be mindful of this fact. If a hardware provider, for example of servers, provides a carbon cost per unit, we can then use this unit of carbon emissions and value how we use it. We can model how the impact on our climate changes if we extend the lifetime of this server by one year, or if we are able to effectivize our code or operations to run twice the workload on the same device.

But what if I don’t own my own hardware? For example if you develop front-end applications or run on a public cloud platform? Does my ISP provide this data for me? 

This data is not very complicated to access if you run your own on-premise data center and deal directly with asset management. But if you do not, then we are again left at the mercy of someone else to provide this data for us. What becomes important then is our, by now very familiar, friend, granularity. We would like to have our service providers give us enough details around embodied carbon that we can understand which actions would reduce the impact.

One example of how to get this data for the public cloud is Cloud Carbon Footprint (CCF). CCF is an open-source project, sponsored by Thoughtworks Inc. Their tool can measure, monitor and reduce your cloud carbon emissions of AWS, Azure and Google Cloud. They have done a life-cycle analysis (LCA) of many of the machines these cloud providers offer, this data is open and free to use.

For client side devices, the situation is tricky. You’d have to be pretty lucky to get your entire user base to provide you with their device age and utilization rates. You also rarely have a service provider you can pose these difficult questions to. In the section “The Good Enough?” of this chapter we will go over some proxies which can be more useful in this case.

The Future Of Perfect Monitoring

Where do we want carbon monitoring of software to go in the future? If you ask us, and since you picked up this book we’re gonna assume you did, it is real-time carbon monitoring.

What do we mean by that? If carbon data became like any other metrics, such as latency and availability, there are a lot of benefits to be had for our industry. For starters, there already are many principles, practices and tooling available already for other types of metrics, which could then be reused. There are also already a lot of people inside the industry who are already familiar with managing those metrics and use them in the most effective way. 

How do we then make carbon data just like another familiar metric? There are two things that we think are key, time-series data and standardization of metrics.

Time-series data

Firstly, we want time-series data. With time-series data, metrics could be easily slotted in with the current industry standard monitoring and alerting tools, such as Prometheus, or Grafana, or your favorite monitoring tool. This will allow us to treat the carbon footprint of our software as another golden signal to care about. It also unlocks scenarios such as alerting on when your carbon SLO is breaching etc. 

Standardization of metrics

Standardization of metrics is another key element. If we make a parallel to what happened with OpenTelemetry, there is now one industry standard for telemetry data, we can see that it has had clear benefits for the sector. It has reduced data collection complexity, increased data quality, enabled easier comparison across systems/vendors, and started to allow people to work on tooling to analyze those data. Of course, we want the same benefits for carbon data.

Having tools with sufficient granularity in time, location, and software components, which could provide real-time (or close to real-time) data would mean that we as software folks could worry a little less about measuring and a little more about reducing. That seems like a fair deal to us. Having a smaller number of people perfect transparent metrics to be consumed by the masses can be a great way to enable more people to reduce their emissions.

Of course, this won’t be possible for all types of software. But for software running on larger platforms like hyperscale clouds or well-known operating systems, this is a good solution which we hope to see the industry move towards.

The Good Enough?

By now, we all understand that “the perfect” might be a little far away sometimes. We don’t always have access to perfect data, nor the ability to gather data continuously, and sometimes we don’t even have access to ANY data. Does that mean we should give up on measuring? No, but we can approach it from a different angle and keep our scientific approach.

Use Of Proxies

Measuring carbon emissions directly is the best way to get to know your carbon emissions (duh). But there are also some proxies which are tied to the carbon emissions that you can use as an indication of whether or not you are trending in the right direction.

One of the best ones is energy, because it is closely related to your carbon footprint. It also has the benefit of being possible to instrument, both on servers and on client-side devices in lab-like environments. One of the best proxies for energy is CPU utilization, it is also easy to instrument which is a plus. If you are self-hosted you might also get this data from your energy provider in real-time, or at the very least at the end of the month with your bill. As you probably understand by now, energy and carbon do not have a 1:1 mapping, but as far as proxies goes, this one is very good.

Cost is another possible one, many green saving actions will also decrease cost. The benefit is that this proxy also speaks the language of your CFO, and you should never underestimate the power of having the CFO on your side. This is not a perfect proxy for a few reasons. One example is that cloud providers do not factor in carbon awareness of your workload into your bill. Another example is that electricity cost does not have to be related to the greenness of the production. But in general, lowering your operations costs will lower your carbon emissions and therefore it is a good-enough proxy.

Hardware is a great proxy for part of your carbon emissions! Producing new hardware comes with a significant carbon cost. Due to energy proportionality running more servers at lower utilization also consumes more energy than fewer servers running at higher utilization. The tricky part here is to consider the system-wide impact. If you are decreasing your hardware footprint in your server hall by sending more computation to the client-side, you may actually increase your emissions. Why? Because you are utilizing both the network and the client-side device more, causing higher energy use there. But used with a little bit of system-wide thinking, hardware usage is a great proxy.

For some scenarios, latency or other performance metrics can also be used. This one has more caveats though as it requires you to consider how your latency or performance should be interpreted. But in general, it can work a little like this. If you decrease the latency by code efficiency or smarter operations (e.g. not by optimistically throwing an extra hardware cache on the problem), you will use less resources on your computer. So far so good but, as we pointed out in Chapter 4: Operational Efficiency, alone this kind of does…nothing (or very little at least). However if you pair this with packing things denser on your hardware, for example by now being able to serve twice as many API requests from the same server, your efficiency went up. This is where the carbon saving comes in. Performance metrics work in the same way. Using less CPU? Great, that means more resources can now have access to the CPU and efficiency goes up.

Consistent Use Of Imperfect Data To Reach Reductions

How scientific is this? Well, it is not as good as our perfect data. But in the real world, things are rarely perfect and we should not let that get in our way of taking climate actions. If you are able to keep a scientific approach in how you use your proxy, or possibly even combine several to paint a broader picture this is an excellent starting point. 

If the use of proxies should result in an as-accurate-as-possible result, it does require you to be quite intimately familiar with your software. Which might be fine, or you might be willing to risk slightly incorrect numbers in order to not let perfect be the enemy of good. Having a little understanding of how your proxy works will go a long way. But ideally, carbon data should be easy to get, which is why we advocate for real-time carbon monitoring as the goal for the future of our industry.

Examination of the Current Methodologies

As mentioned before, we are not the first ones on the mission to figure out our carbon footprint. There are already some methodologies available to help us to do exactly this. Let’s dedicate some time to walk through them together.

I'd like to steal (and possibly misquote) a quote from Dr. Radia Perlman:

Sometimes standards bodies are like sports fans, each only cheering for their own team.

In this book we'll try to be a bit more objective than sports fans and we also encourage you to arm yourself with knowledge first, before judging. Unlike a sports fan, you are also perfectly allowed to have several favorites too.

Greenhouse Gas Protocol (GHG protocol)

We'll start with the Greenhouse gas protocol (GHG protocol), which is perhaps one of the most widely used standards for calculating a carbon footprint of organizations. At least according to themselves, 90% of Fortune 500 companies use this standard.

The GHG protocol is a joint initiative of World Resources Institute (WRI) and World Business Council for Sustainable Development (WBCSD). The work to create the standard was started in the late 1990s and resulted in the first Corporate Standard being published in 2001. Now the GHG Protocol also hosts several other standards, but we’ll stick to reviewing their Corporate Standard in this book. The standard comes with a lot of guidance and help available for those who wish to implement the standard and it is free to use.

The Corporate Standard covers the accounting and reporting of seven greenhouse gasses, the same one as the Kyoto Protocol indicates. The reporting is divided into 3 parts:

• Scope 1

  • All direct emissions from your own corporation. For example the vehicles operated or the fuel burned by plants owned.

• Scope 2 

  • All indirect emissions from purchased energy, such as electricity, steam, heat and cooling.

  • In 2015 the Corporate Standard was extended with a comprehensive Scope 2 Guidance, this guidance codifies two distinct methods for scope 2 accounting:

    • The location-based method. This method means that the average emissions intensity of grids on which energy consumption occurs is used.

    • The market-based method. This method reflects emissions from electricity that companies have purposefully chosen, this can include energy attribute certificates (RECs, GOs, etc.), direct contracts (for both low-carbon, renewable, or fossil fuel generation), supplier specific emission rates, and other default emission factors. 

  • Sounds complicated? Don’t worry, the details do not matter a great deal to us in this context. But very simply put; the key difference between the two methods is that the location-based counts the actual electrons you use, whereas the market-based counts the electrons you have paid for.

• Scope 3 

  • All other indirect emissions that the corporation does not own or control. As you can imagine this becomes a rather large bucket which fits everything from purchased material to waste management to business trips to product use.

Alright, we get it now, but how does it work for software? As it is written right now, GHG protocol is not optimized for software. At least not in the sense that it can give software developers the tools to understand what actions to take to reduce their impact. Let’s look at some examples of what we mean by that.

Say for example that you write software, for which you do not provide the primary hosting. For example a library or an SDK people can download and use, you might then only host the actual downloading capability but the runtime is always on someone else’s hardware. The lion share of the emissions stemming from your software will very likely be in someone else’s (many someone elses’ if you are successful) scope 2 and/or 3 reporting. What? Yes. Scope 2 because your SDK is consuming energy in your customers data center and scope 3 because your software will impact how much or how little hardware they use. Even if you could decrease the energy use of your software, the decrease would primarily be visible in someone else’s scope 2 reporting, not yours. Even if you are building an open-source service, which you do self-host, part of your emissions will still stem from usage of your service in other pieces of software. And the emissions (scope 1,2 and 3) from your self-hosting will also count as your customers scope 3.

Things also get a little harder to follow when we consider different methods of operations. 

• For private cloud applications, the energy usage of your software falls into scope 2, and the embodied carbon of all your servers falls into scope 3.

• For public cloud applications, both the energy usage of your application and the embodied carbon fall into scope 3.

• In scenarios where you are running a hybrid private/public cloud application, part of its emissions will fall into scope 2 and part will fall into scope 3.

• Similarly, for your customer-facing front-end application, energy usage falls into your organization's scope 3, since your customer will purchase the energy to power their device.

This makes actionability tricker for folks like us, who want to understand which of our actions had what effect. 

Even so, many organizations in the tech sector are currently using the GHG protocol. This means your colleagues and the leaders in your organization already speak this lingo, which can be very helpful when we want to use measurements as a tool for change.

Green Software Foundation’s Software Carbon Intensity Specification (SCI)

Next up, the Green Software Foundation's (GSF) Software Carbon Intensity Specification (SCI). The SCI is specifically built for software, it comes with different limitations and abilities compared to the GHG protocol. Much like the GHG protocol, it also comes with guiding documentation to help you implement it.

The first version, the beta version, was released for COP26 in the fall of 2021. It was quickly followed by the version 1 of the SCI for COP27 in 2022. GSF is working to get the standard made into an ISO standard, but as of the printing of this book, it is not there yet. You can follow its progression in the ISO/IEC DIS 21031 page.

The SCI is different from the GHG protocol in that it is not a total for your organization, it is a rate of carbon emissions per functional unit for your software. Reaching a lower number is better, but reaching zero is impossible. 

The SCI consists of 4 key parts:

Energy (E)

The energy consumed by your software.

Carbon intensity (I)

The location-based carbon intensity of the energy grid powering your software.

Market based measures are not allowed in the SCI, only the location-based metrics can be used.

Embodied carbon (M)

The carbon emitted through the creation and disposal of the hardware which your software is running on.

The functional unit (R)

The magic thing that makes this standard a rate. This should be how your software scales. For example, per user per device or per API call.

The parts gets combined into the following mathematical formula:

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

Another key aspect of the SCI is your software boundary. This is something defined by you to delimit your software system in a meaningful way. More is less here, the SCI states that all systems and infrastructure that significantly contributes to your operations should be included inside your software boundary.

Initially we stated that it can never fall to zero. Now that you know the SCI better, you can understand that it is because of three reasons. 1) Unless we make significant scientific progress in the field of hardware, you cannot run software in thin air and thus (M) will never be 0. 2) Since the SCI does not allow for market-based reductions, (I) will always be a number greater than 0. 3) The energy consumed will never be 0 unless the machine is unplugged, at which point it cannot be considered to be a working software system.

The SCI is meant for everyone and all types of software, this makes it different from other reporting standards.

How can this work in practice? Wonderful Tiny Farm has submitted a case study to the GSF which we will use as an example. Their software is a .NET application gathering farm insight data, like sunlight and temperature, on a Raspberry Pi.

• Energy use - E - 0.003 kWh per day

• Carbon intensity - I - 0.713 kg per kWh

• Embodied carbon - M - 55 kg.

  • Assume this device is exclusively used for this purpose and has a life span of 3 years.

• Functional unit R - per Raspberry Pi device

SCI = ((E*I)+M)/R = ((0.003*0.731)+(55/(365*3)) per Raspberry Pi = 0.002139 + 0,05228 per day and per Raspberry Pi = 0,052 kg CO2eq per day and Raspberry Pi.

This number is fun but it doesn’t do much on its own, ergo Wonderful Tiny Farm should not stop here and call it a day. No, instead it should inspire them to take some action. Perhaps this SCI score helped them realize that their embodied carbon cost is higher than their energy cost, thus elongating the lifetime of their Raspberry PI is a better first step than switching energy provider (which can be step 2). 

ISO 14064 Standard

The ISO 14064 standard consists of 3 parts, called ISO 14064-1, ISO 14064-2 and ISO 14064-3, which is perhaps not very catchy but a rather convenient naming scheme. The standard was first published in 2006 and the latest revision was in 2018 and as of the writing of this book it is currently going through its planned 5-year review. The ISO 14064-1 focuses on the reporting of GHG emissions and removals on an organizational level and we wanted to shortly include it to highlight some similarities and differences to other standards we have talked about.

While the ISO 14064-1 is also built on the GHG protocol, the division of emission is a little different. GHG uses scope 1,2 and 3 whereas ISO 14064-1 divides emissions into direct, corresponding to scope 1, and indirect, corresponding to scope 2 and 3, emissions. ISO 14064-1 also supports market-based reductions techniques but unlike the GHG protocol, ISO 14064-1 is not free but access to the documentation comes with a small cost. One benefit of using an ISO standard is that  ISO's Committee on Conformity Assessment (CASCO) has produced a number of standards related to the certification process. Your organization can then be ISO certified by a third-party certification body, which can be great for auditability.

Available tooling

If you don't want to measure yourself or get into the nitty gritty details of implementing a standard, fear not, you are definitely not alone in this feeling and there are options for you too! All major hypercloud providers have their own tools for delivering carbon impact data to you based on your usages. There are also other tools available for those who run client side applications outside of the cloud available. But in order to avoid comparing apples to oranges, we need to inspect these tools at a closer range first.

Hyperscale Cloud Provider Tools

While there is no official definition for which vendor counts as a hyperscaler, Amazon AWS, Microsoft Azure and Google Cloud held a combined 66% market share in 2022, so those are the ones we will focus on in this section. Three of the other large cloud providers, IBM Cloud, Oracle Cloud and Alibaba Cloud, all claim to have a strong focus on sustainability and have objectives for reaching various renewable energy and sustainability goals. This is great to see and we look forward to progress across the sector. But in the context of this chapter, as of now neither of these three have any carbon accounting tools available for us to review.

The three big ones, AWS, Azure and GC also have strong sustainability commitments. They also provide tools for us as consumers of their services to assess our carbon footprint on their platform. Which immediately generates some questions for the curious of us. What do they include? Can we compare them to each other? What are they useful for?

Let’s compare them to each other, shall we?

Amazon AWS

Microsoft Azure

Google Cloud

Granularity

Continent level.

0,001 metric ton of CO2eq

Country and region level.

0,001 metric ton of CO2eq

Country, region and zone level.

0,1 kilogram of CO2eq

Scope 1

Yes.

Yes.

Yes.

Scope 2

Yes.

Follows the market-based GHG Protocol. (Regional)

Yes.

Follows the market-based GHG Protocol. (Regional)

Yes.

Follows the location-based GHG Protocol with hourly emissions factors.

Google also promises to also provide a market-based dashboard for its customers.

Scope 3

No.

(Announced to be added in early 2024)

Yes.

Embedded carbon for the manufacture, packaging, transportation, use, and end-of-life phases of data center equipment.

Embedded carbon of data center buildings may be included as data becomes available.

Yes.

Embedded carbon for the creation of data center equipment and building as well as travel and commute associated with Google data center employees are included.

Allocation type

Not shared.

Microsoft allocates emissions based on each customer's relative Azure usage in a given datacenter region.

Google uses a bottom-up method.

Energy used when running a workload is allocated based on each service’s CPU usage. Energy used when the machine is idle is allocated based on each service’s resource allocation. Overhead energy use is allocated to each machine on an hourly basis, thus trickling down to the first two categories.

Time sensitivity

Monthly aggregate.

3 months data delay.

Monthly aggregate.

14 days data delay.

Monthly aggregate.

Up to 21 days data delay.

PUE

Yes.

Yes.

Yes.

Additional resources

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ccft-estimation.html 

https://aws.amazon.com/blogs/aws/new-customer-carbon-footprint-tool/ 

https://learn.microsoft.com/en-us/industry/sustainability/api-overview 

https://cloud.google.com/carbon-footprint/docs/methodology

https://cloud.google.com/carbon-footprint/docs/data-schema 

Open Source Options For Cloud

Cloud Carbon Footprint is an open-source project, sponsored by Thoughtworks Inc. This tool can measure, monitor and reduce your cloud carbon emissions of public clouds. They currently cover AWS, Azure and Google Cloud. They convert cloud utilization into estimated energy usage and then carbon emissions, producing metrics and carbon savings estimates. The emissions shown by their tool is calculated as follows:

Total CO2e = operational emissions + embodied Emissions

Where:

Operational emissions = (Cloud provider service usage) x (Cloud energy conversion factors [kWh]) x (Cloud provider Power Usage Effectiveness (PUE)) x (grid emissions factors [metric tons CO2e])

And:

Embodied Emissions = estimated metric tons CO2e emissions from the manufacturing of datacenter servers, for compute usage

Another open-source option is Kepler (Kubernetes-based Efficient Power Level Exporter) which is a Cloud Native Computing foundation (CNCF) project from 2023. Kepler can estimate power consumption at the process, container, and Kubernetes pod levels of your software. It does this by reading real-time system metrics for bare metal deployed software (e.g when you are running directly on the server without the abstraction of a virtual machine. For virtual machines, Kepler uses pre-trained ML models to estimate the energy consumption. This data can be exported as Prometheus metrics, which makes it easy to track and monitor this data, pretty close to our dream metrics!

For ease of comparison, here is the tool in the same table as above:

Cloud Carbon Footprint

Kepler

Granularity

0,001 metric ton of CO2eq

NA (Kepler does not convert energy to carbon)

Scope 1

No.

No

Scope 2

Yes. Follows the location-based GHG Protocol 

Yes. (Although you will have to multiply with the carbon intensity of the grid by yourself as Kepler only gives you the energy related stats.)

Scope 3

Yes, only for compute usage type for now due to lack of public data available.

No

Allocation type

This depends slightly on the cloud type, but their model includes compute, GPU, storage, networking and memory based on the billing information.

Kepler uses a bottom-up by reading real-time system metrics.

Time sensitivity

Depends on the delay of billing data from each public cloud provider.

Live.

PUE

Yes, based on public static data from each public cloud provider.

No.

Additional resources

https://www.cloudcarbonfootprint.org/docs/methodology 

Exploring Kepler’s potentials: unveiling cloud application power consumption | CNCF

Client Side Tooling

Public cloud tools are great, but not all software runs there. One glaringly obvious example of this is client side code, like apps or websites. For these scenarios, we are not left in the dark either, there are other tools available, some directly from the major players, others are open source. This is not a complete list by any means, but some examples of tooling to get you started.

For phone apps, both Android Studio and iOS Xcode have options to model energy in the development stage. Turns out, when a resource is limited (like a phone battery), our industry is pretty good at building tools to make you effectively use this resource.

Another tool for mobile apps is Greenspector, which actually runs your software on real mobile phones and measures the energy usage. This is pretty close to our dream of perfect energy data! Of course this will only give you a snapshot, but it can be a number to extrapolate from and something to benchmark against over time.

Green The Web has also gathered a plethora of different tools for different aspects of web development, covering everything from analysis (arguably the most interesting for this chapter) to image compression tools.

If you want to estimate your ML training carbon cost, a set of ML researchers has put together this ML CO2 impact tool. It works for several hyperscale clouds as well as on-prem scenarios and it is open for contributions. 

As you can see, these tools all have their limitations or boundaries, but the massive advantage is that you have to do very little to get quite detailed insights into your energy or carbon usage. Paired with a scientific method and consistent measurements over time, these are all great options to lower your software’s impact.

You Made It!

You made it to the end of the measurements chapter, perhaps it was a lot of new concepts and terminology for you or perhaps this was all old news. Either way, we hope that you now have a better understanding of what you can do to measure your emissions and where you can get help to do the same. Whatever solution you end up using, we hope that you approach your software measurements with curiosity. 

• Why is this number so high? 

• How can I compare it to this other number? 

• What if I tweak this operation, how will my number change? 

Let the measurements be a conversation starter and, once you get the hang of it, your faithful companion on the road to carbon reductions.