search

SAS-DHRH / dhcc-toolkit

Digital Humanities and the Climate Toolkit (draft), Digital Humanities Climate Coalition (DHCC)
https://www.cdcs.ed.ac.uk/digital-humanities-climate-coalition
12 stars 8 forks source link

"On demand infrastructure" —> Minimal energy infrastructure #29

Closed sbutler-gh closed 4 months ago

sbutler-gh commented 1 year ago

From: https://sas-dhrh.github.io/dhcc-toolkit/toolkit/minimal-computing.html

Minimal maintenance.

  • Why are you still running it?
  • On demand infrastructure.
  • Creating cost models
  • Infrastructure is declared - a knowledge system to load the YAML file into to get your emissions costs back would be great - instead of the calculators.
  • Get the ICT service catalogue to update with emissions/costs.

On demand infrastructure seems to be a subset of minimal energy/computing infrastructure — instead of things running all the time, they run when requested.

However, there are other ways of thinking about this too. Should something be available on demand all the time? Is there a difference if, for example, an "on demand" infrastructure is only available during sunlight hours? Such as solar.lowtechmagazine.com. It the site was built around a serverless infrastructure, it perhaps could qualify as "on demand infrastructure." It takes a step further and more fundamental however — it is only available for requests to serve its page content when the sun is shining in Barcelona, and it can serve those requests using solar energy.

"Minimal energy infrastructure" could be different for different use cases and contexts — serving pages on a website, batch processing, data analysis, watching videos, etc It probably starts with "what is the thing we are trying to do", and then try to minimize the energy intensity of infrastructure around that thing — including, opinionated decisions about when/how requests and processing and computing is possible, in contrast to "always online."

As another example, Andrew Godwin — creator of Takahe, a Fediverse/Mastodon server that can host multiple domains on a single server, with minimal complexity and JS (makes use of #HTMX!) — noted that "ActivityPub has enough retrying built in, that you could go down for 12 hours a day [by tunneling to a local run server]." So a social media server in a federated network, that could work as expected and federate content across servers, without needing to work more than 12 hours a day (say from 10am to 10pm — or extending that, from 7am - 11pm) — which could reduce the energy usage and data transmission involved in that social media server by up to 50%, compared to a server that is always running (which is probably the default config?)

Of course, that also means that content posted at 9:59pm may not reach other networks until 10:30am the next day — and likewise, that's part of the tradeoff, which likewise allows us to cut the energy and data usage involved in half.

drjwbaker commented 4 months ago

Thanks @sbutler-gh --- I've integrated some thoughts, and added a link to this issue as a pointer towards ongoing work.