Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] For discussion later - Real-Time Infrastructure Accounting for embodied carbon #62

Open
Tracked by #61 ...
mrchrisadams opened this issue Aug 27, 2024 · 2 comments
Assignees
Labels
question Further information is requested

Comments

@mrchrisadams
Copy link

Question

Meta published some really interesting new research, addressing a real problem with accounting for embodied carbon right now in digital services:

Current carbon accounting and reporting practices for Scope 3 emissions are static. For data center servers and components, in particular, this means that the entirety of the embodied emissions from the upstream supply chain, manufacturing, and logistics is attributed in the year of purchase. Benefits from circularity are not realized in our Scope 3 footprint until future purchases of new servers or components are deferred. This does not provide actionable information to our operational teams in real-time on how varying the usage or the expected life of the acquired servers can impact Meta’s Scope 3 emissions.

Meta's response is referred to as RETINAS: Real-Time Infrastructure Accounting for Sustainability. Details below:

This initiative has led to the development of a new internal metric— real-time server fleet utilization effectiveness —that enables us to take action to reduce the emissions associated with the embodied carbon of our data center servers and components. Embodied carbon contributes to Meta’s upstream Scope 3 emissions, and includes the emissions associated with the full lifecycle of the manufacturing, assembly, and transportation of servers and materials in our physical infrastructure.

Basically it allows amortising the impact of hardware over a given number of years, based on your chosen strategy for retaining them. This is somewhat like how some cloud giants changed their depreciation strategy for servers, to recognise a longer life, and spread the cost over more years, but doing it dynamically, and with carbon.

More below:

https://engineering.fb.com/2024/08/26/data-infrastructure/retinas-real-time-infrastructure-accounting-for-sustainability/

Would any of these ideas be relevant to future work in this WG?

Issue dependency with other WGs

No response

@mrchrisadams mrchrisadams added the question Further information is requested label Aug 27, 2024
@seanmcilroy29 seanmcilroy29 mentioned this issue Aug 27, 2024
11 tasks
@mrchrisadams
Copy link
Author

mrchrisadams commented Aug 27, 2024

For Tim Smolcic, this paper is the one I know exploring payback period for energy saving vs embodied energy in networking:

https://www.sciencedirect.com/science/article/abs/pii/S0306261916000180?via%3Dihub

There are some charts like this in the paper showing the sweet spots (or opposite of sweet spots - I guess)

image001

There's also some work from Green Coding in Berlin exploring the same question:

https://www.green-coding.io/blog/when-to-replace-a-machine/

@seanmcilroy29 seanmcilroy29 mentioned this issue Sep 24, 2024
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants
@mrchrisadams @adrianco @PindyBhullar and others