Adding an overview of the estimated perimeter in the methodology documentation

[github-benjamin-davy]

Seeing that the Cloud Carbon Footprint methodology will keep on evolving by supporting more and more services and scopes, I'm wondering if it would be interesting to add a visual showing all the components and emission sources (including scopes) of a cloud platform and indicate what’s covered to date by the tool for each provider.

It might help users to understand why the numbers might change over time. As an inspiration, there is the great work from David Mytton and especially this article that could help in that regard.

[davidmytton]

The original for the graphic in my article is at https://github.com/davidmytton/paper-assessing-ghg-protocol-for-public-cloud/blob/master/Fig%201%20-%20Public%20Cloud%20Components.png and I can provide the Word source doc as well if you wanted to use it. Also happy to help creating something from scratch in a more open format that will be easier to keep up to date (exporting to SVG is probably a good idea).

[github-benjamin-davy]

Thanks a lot @davidmytton! In the meantime, I've created a simplified view for the Cloud Carbon Footprint initiative as a starting point, I'll add you as editor if you want to comment (it's a Google Doc).

[davidmytton]

Thanks for sharing - the diagram looks good!

I believe the backup generator would come under Scope 1 emissions and would be quite small because the generators are rarely used. It may be quite difficult to account for those in this methodology because it would require reporting by the cloud vendor when they switched to generator backup. The EPA suggests this could be done on a total hours basis (presumably annually). Microsoft reports diesel backup as less than 1% of total emissions, although they are working to phase it out. It may be out of scope for this methodology though.

PUE would also cover misc power usage in the data center e.g. lighting, but that may be unnecessary to include.

This all covers the primitives (compute, storage, networking) but doesn't have any representation for higher-level services built on top of them e.g. DNS, databases, container orchestration, ML/GPU chips, etc. Representing these on the diagram is more challenging. Were you thinking of showing them linked to this somehow?

[github-benjamin-davy]

Thanks for the feedback @davidmytton, indeed for the generator it shouldn't be much. I've heard from a data center operator that they have to empty the fuel tank regularly to clean it even if the fuel isn't used + there are minimal usage due to maintenance operations to make sure the generator is still able to run so I was wondering. The number from Microsoft is interesting in that regard. I didn't detail all the things that is covered by the PUE but it might be worth indicating indeed.

Regarding higher-level and managed services I'm assuming they all rely on primitives, we could represent them on top, I'll try. These are still a challenge to estimate and what I'm doing right now is guessing the underlying primitive. For example, for databases on AWS it's simple since we have some information about the instance used in the billing (here for AWS RDS) so I'm using compute and storage primitive estimations to cover that service.

For sure there would be non-covered things and maybe we need to go deeper for each provider to detail what we are able to estimate and what we are not yet able to cover. Another example of what would be lacking is something like observability services (e.g. CloudWatch on AWS) where I only have a billing per metric on AWS.

Here an option would be to guess the underlying primitives required for X metrics for example. But it's getting complex and sometimes I'm wondering if maybe a simple monetary ratio (kWh per k$) wouldn't be that bad of a starting point compared to piling up assumptions. Happy to hear your thoughts on all this.

[davidmytton]

Regarding higher-level and managed services I'm assuming they all rely on primitives, we could represent them on top

Yeah - representing them as a single box/component may be best, to keep it clean, rather than trying to add them all individually. Some kind of generic "SaaS" box or similar, perhaps.

Here an option would be to guess the underlying primitives required for X metrics for example. But it's getting complex and sometimes I'm wondering if maybe a simple monetary ratio (kWh per k$) wouldn't be that bad of a starting point compared to piling up assumptions.

If you're able to make an estimate for kWh per $ then that would be a good fallback where there is no service-specific intensity factor. Agreed that it's very difficult to put numbers to such abstract services as observability. This is where more transparency from the cloud vendors is needed.

[github-benjamin-davy]

Thanks for the feedback, I've updated the visual (also on the Google Doc).

[davidmytton]

Looks good.