Lower Carbon HW as a sustainability action for SW

[eshachoukse]

One can also make software sustainable by running it on lower carbon-intensive hardware. This not only applies to running on CPUs rather than GPUs/right sizing, but also on older hardware. For example, nodes that have been in use for ~3-4 years already have offset their embedded/embodied carbon, and the hardware can now be considered zero/low carbon. If the software is made compatible with older HW, we can thus have fewer emissions, with longer HW lifetimes. Do we want to capture this in the spec?

[atg-abhishek]

Thank you @eshachoukse for raising this - I'm definitely in support of this idea. In fact, I'm wondering if from your work, you've seen places where non-backward compatibility due to software upgrades has warranted discarding "old" hardware and if there is some data that we could share that strengthens the case for this?

[jawache]

I think these are two separate points:

1. Using lower spec-ed hardware (rightsizing) should already be taken into consideration as lower spec-ed machines have lower embodied carbon footprints, their M is already smaller.

2. Using machines for longer is an interesting direction. I totally agree with the approach, I've argued and spoken about it in the past. The question I ask myself is if we included this in the spec in WILL it in fact encourage devs to build software that runs on older devices or will it just be something you include, but then ignore because there is nothing you can do about it?

For example in DCs rack space itself has a value and you want to maximise profitability per square foot. There is an inflection point at which keeping an old server you can't charge as much for, is less profitable than buying a new server you can charge a lot more for. So even if software could use older server, will DC's fill themselves with older, less profitable servers?

Where I think this really comes into it's own is with end user devices, laptops/mobile-phones/tablets. I think you could argue that if modern apps ran on older devices, most people would keep their older devices. I for one really do not need a more powerful camera, I'm good. Although after writing that I just realised I was forced to change my phone recently because the OS stopped being updated on it, which meant many of my apps stopped working on it. So perhaps it's more a question of encouraging OS providers to support older hardware, maybe that's the root cause of device obsolescence rather than app developers.

[atg-abhishek]

I think the tradeoff in this case that OS providers would make is that it fragments security updates that they have to make, so they just prefer to retire out old versions completely, and have everyone move in lockstep ahead. And this becomes difficult to reconcile. I think the point that then needs to be made for them is that environmental considerations need to be elevated to the same level as other considerations, in this case, business, functional, security, so that such a cop-out might be avoided?

[srini1978]

1. Using lower spec-ed hardware (rightsizing) should already be taken into consideration as lower spec-ed machines have lower embodied carbon footprints, their M is already smaller.

@jawache Can we get SCI open data to publish some data around the consideration that lower spec data has lower embodied footprints. They can probably pick a few cloud SKUs and showcase this . For example can we get them to show this from here -https://github.com/cloud-carbon-footprint/cloud-carbon-coefficients/blob/main/output/coefficients-azure-embodied.csv where we can see that D1v2 series machines have lower embodied carbon values than D11 v2 or some example like this.

We can include this recommendation or data point in our section on M within the formula

[mrchrisadams]

Hi folks this comment here by @jawache :

Using machines for longer is an interesting direction. I totally agree with the approach, I've argued and spoken about it in the past. The question I ask myself is if we included this in the spec in WILL it in fact encourage devs to build software that runs on older devices or will it just be something you include, but then ignore because there is nothing you can do about it?

I think there's absolutely a case for including this, and I can point to a few examples of this where it might make sense to capture in the SCI too.

• In the US companies like Lancium offer compute on clusters of ex-Facebook servers, deployed onsite where renewable energy is used. There are European variants of this idea too.

• Sesame sells these servers after they have had one useful life too.

• Datacentrelight in Switzerland even go as far as repurposing entire buildings to run as datacentres as well as using pre-used servers.

All of these would have an impact on the embedded carbon, especially if the emissions are typically amortised after the first 3-5 years in an "first" life, and also create an incentive to use "second-life" servers, assuming they're not massively less efficient - they might have an effective embedded carbon of close to zero, as it's already been accounted for.*

We know that making servers is extremely energy intensive, so an incentive to extend their useful life, would be worth capturing.

* I'm saying close to zero, as I think it's usually amortised over the 3-5 year period, so from year 5 you might consider the embedded carbon already accounted for, as it's attributed to the first owner / buyer. I don't know how to do this in marginal terms, sorry.

[mrchrisadams]

Oh yeah - this paper from the ACM Computing Within Limits conference last year has actual data provide an evidence base for decisions to include things, at the end user side too, not just the datacentre side listed above.

Stipulated Smartphones for Students: The Requirements of Modern Technology for Academia

In this paper, we examine how well online learning platforms function on older browser software and device hardware. We then perform an analysis over several years of data from a learning management system used at the authors’ university campus. We find that software and hardware become obsolete within roughly a four-year period, meaning students are likely to be required to purchase a new smartphone or laptop during their college careers. In reality, these “obsolete” devices are just as capable as they were when they were new. We advocate for a student-focused solution and examine possible future lines of research in this area.

Worth a read 👍

[atg-abhishek]

Thanks for sharing these resources @mrchrisadams - the paper in particular might be worth sharing on Slack as well :)

[jawache]

A mental game I use that's been useful to me is to imagine two apps, one incredibly efficient one very inefficient. We want the efficient app to score better and if the goal is to bias action towards making apps more energy efficient, more hardware efficient and more carbon aware then the only way to reduce the score is if one of those things were to happen. If all a company has to do to reduce the score of their incredibly inefficient application is to migrate it to a DC that runs older hardware. Is that an outcome that we want? Or do we want the company to invest the time and effort to make their application efficient. It's the same bucket of argument as do we allow neutralisations and offsets? If we allowed neutralisations then you could reduce your score by making no real investment in the software and just migrating your workloads to a carbon neutral DC. The group decided that was not something we wanted to do. If we drew a line at neutralisations, I think we have to draw the line here as well. If you are a DC and you use old hardware I do think you should consider them zero carbon from an offset perspective, i.e. no need to buy carbon offsets to offset the embodied carbon, consider it zero carbon from the outset. Generally though we do need to encourage hardware to be used for longer but this feels more like something we can explore as part of the new procurement checklist/policy/certification that's being discussed. So if your software product runs on hardware older than X years old then it gets a green tick. If it runs on a carbon neutral DC with 24/7 hourly matching, green tick etc... that feels like a better place to put this kind of lever since it's really about spending money well, will have more impact than trying to jam it into the SCI equation I think. *Sent with Shift <https://tryshift.com/?utm_source=SentWithShift&utm_campaign=Sent+with+Shift+Signature&utm_medium=Email+Signature&utm_content=General+Email+Group>*

…

On Wed, 16 Mar 2022, 18:05 Chris Adams, ***@***.***> wrote: Hi folks this comment here by @jawache <https://github.com/jawache> : Using machines for longer is an interesting direction. I totally agree with the approach, I've argued and spoken about it in the past. The question I ask myself is if we included this in the spec in WILL it in fact encourage devs to build software that runs on older devices or will it just be something you include, but then ignore because there is nothing you can do about it? I think there's absolutely a case for including this, and I can point to a few examples of this where it might make sense to capture in the SCI too. - In the US companies like Lancium <https://lancium.com> offer compute on clusters of ex-Facebook servers, deployed onsite where renewable energy is used. There are European variants of this idea too. - Sesame sells these servers after they have had one useful life too <https://www.itrenew.com/sesame>. - Datacentrelight in Switzerland <https://ungleich.ch/en-us/cms/blog/2019/06/28/how-run-really-green-datacenter/> even go as far as repurposing entire buildings to run as datacentres as well as using pre-used servers. All of these would have an impact on the embedded carbon, especially if the emissions are typically amortised after the first 3-5 years in an "first" life, and also create an incentive to use "second-life" servers, assuming they're not massively less efficient - they might have an effective embedded carbon of close to zero, as it's already been accounted for.* We know that making servers is extremely energy intensive, so an incentive to extend their useful life, would be worth capturing. * I'm saying close to zero, as I think it's usually amortised over the 3-5 year period, so from year 5 you might consider the embedded carbon already accounted for, as it's attributed to the first owner / buyer. I don't know how to do this in marginal terms, sorry. — Reply to this email directly, view it on GitHub <#237 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG3D443SDTVSACVHWGVQITVAIPFJANCNFSM5P6UKO7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <Green-Software-Foundation/software_carbon_intensity/repo-discussions/237/comments/2374923 @github.com>

[atg-abhishek]

@jawache so this is interesting - do you think it will create a parallel market where DCs with older hardware might offer that as an attractive option to lure people since they've already offset the embodied carbon because of an extended lifespan?