Cost as a proxy for carbon – the inconvenient truth: Part 2
In the first part of this series, we outlined many of the reasons why cost cannot really be considered a suitable proxy for carbon emissions and how some cost optimisations can disincentivise you from making sustainability related optimisations. Here, we will outline some additional concerns and a better approach to calculating your emissions.
Additional Challenges
Using Cost as a proxy for emissions also does not help you to easily measure the impact of optimisations such as code improvements or changes to architectures. For example, you may redevelop an API to change the amount of data it returns, which also optimises a query against your data store. The infrastructure to support this is unchanged, but the resources required to serve the API are reduced. Simply using cost as the measure here will not reflect this optimisation.
If not cost, what can I use?
If we look at the Green Software Foundation’s emerging Software Carbon Intensity (SCI) standard for calculating emissions `SCI = (E*I)+M per R`, we can see that there are actually numerous data points required to begin to accurately calculate emissions. This includes the grid energy mix at the time, the actual resource utilisation, such as CPU or memory, the projected available lifetime of the hardware, the amount of the hardware available to the service and more. By comparison, the relatively simple cost calculation does not allow for many of the required data points to be taken into consideration.
The challenge here however is in getting the right data from the cloud vendors. This is a non-trivial exercise, but one we have experience with!
So where can you use cost as a proxy?
To supplement emissions data provided by the hyperscalers, to allow you to calculate the emissions at a per service level. We have done this, and been fully transparent, as the emissions data currently provided by the vendor in question was not available at a granular enough level to allow us to attribute emissions directly to the service in question. We used the billing data to identify the percentage of the bill attributable to the service for each the cloud services in scope. We then used this to allocate the emissions from the total for the cloud platform. We are aware that this approach has its limitations, however we have now developed an approach and methodology for the customer that can be updated as better data is made available. They now have a value that they can measure on an ongoing basis and work to improve alongside their other KPIs.
The final point I will make here is that incoming regulatory requirements for organisations to report on their Carbon emissions, across all scopes. Cost as a proxy will not support this, and so it is critical that this approach is not relied on by organisations. Speak to your Account Manager or cloud vendor and ensure that you are pressuring them to provide better emissions and sustainability related data that you can use to meet your reporting requirements, before the regulations come into force!
So, the next time you hear someone say that you can use cost as a proxy for carbon be aware that they may not be in position of the complete picture. If you are optimising your workloads based on cost data, then you are optimising for cost, and this is not a bad thing. However, any sustainability benefits will be incidental, and nearly impossible to measure without appropriate data.
If you would like to speak to someone about any of the points raised here, or for assistance in either Cloud Cost Optimisation or Sustainable Cloud then please reach out!