Replace life span with use duration in Embodied Emissions formula

[AirLoren]

Using life span in embodied emissions formula leads to wrong results because the underlying infrastructure is never used at 100% during its whole life span. Most Cloud providers expect a use of less than 80% of running infrastructure and on premises infrastructures are often used less than 50% of the time during their life span. You'd rather introduce a total use ratio to calculate the effective use duration of the infrastructure during its life span.

The formula would be something like : M = TE (TR/(UREL)) * (RR/TR)

where : TE = Total Embodied Emissions, the sum of LCA emissions for all hardware components. TR = Time Reserved, the length of time the hardware is reserved for use by the software. EL = Expected Lifespan, the anticipated time that the equipment will be installed. RR = Resources Reserved, the number of resources reserved for use by the software. TR = Total Resources, the total number of resources available. UR = Use ratio, the percentage of time the equipment is used during its expected life span

[Henry-WattTime]

The working group appreciates this comment and is reviewing in detail! On the agenda for next week (12/16).

[atg-abhishek]

We would love to include the use-ratio but from conversations it seems that this would be a difficult number to get from data centres.

We might need some more information on how this applies to auto-scaling infrastructure cc @srini1978 (would be great if you can create an issue with this for future tracking)

We will explore if it is possible to get this data and then include it into the SCI.

We could; have a default value for the use-ratio included in the guidelines document that may accompany the SCI

[AirLoren]

I agree that it will be hard to get this ratio from cloud providers because it's a key indicator for their business model and profitability. I think the default value for this use ratio is a good idea to :

• allow organization to fine-tune their results if they're able to get this ratio
• allow to get results even if you are not able to get it
• encourage cloud providers to publish their ratios (for example, if you set the default value at 60% and if SCI becomes a reference in terms of Software Carbon Intensity evaluation, major cloud providers will be pushed to published their higher ratios to show customers that Software Carbon Intensity is lower on their platforms) .

[srini1978]

@atg-abhishek @Henry-WattTime @AirLoren From a practical perspective, I think it would be necessary to define more in detail how do we define TR and RR in the above formula.

For Platform services in the cloud that abstract away the infrastructure and the scaling from application developers, it is nearly impossible to talk in terms of time reserved and resources reserved. In such cases the information can never be estimated as it depends on Usage of the application and hence it depends on the number of users, concurrent users, adoption of the application. All areas are not under the control of SCI and hence cannot be manipulated.

Hence my first thought is that we should change the terminology to Time spent and Resources spent instead of Time reserved and Resources reserved.

The next big challenge I think is how we calculate Time reserved and Resources reserved. For this discussion, let me focus on Time Reserved with an example ( Subconsciously this will also focus on RR - resources reserved()

Let us take an example of a Web application

1) Let us deploy a web application to an Azure App Service which is a Platform as a Service. There are multiple SKUs available for this service and let us suppose I choose a SKU (and hence I will have details on CPU used (vCore), RAM used (MB) and storage used ( GB). This will help me calculate the initial value of "Embodied Emissions" or M.

2) The same platform service could be shared by multiple web applications and as a Platform service, we may not be able to reserve upfront the number of vCores, memory etc for one application or any application .

3) As mentioned above it is difficult to come up with a number for TR and RR. Hence we look at Time spent and Resources spent . One approach that we could use for calculating time spent and resources spent (in the case of cloud providers) is to look at the utilization factors of the infrastructure (CPU %, DTU %, Peak CPU used in month) etc. This would of course be actuals

[srini1978]

@atg-abhishek @Henry-WattTime @AirLoren

Some additional thoughts that can help us gain a foothold on this TR and RR components

1) Our overall calculation principle is that we will be consequential not attributional. Hence elements like TR/RR or TS/RS will end up reducing the value of M. My thought it is ok to assume that the infrastructure is fully used by this software and if portion of the M value gets double counted or triple counted depending on the # of apps hosted, we should still be fine as our uber principle is being consequential.

For example if M value is 100 KgCo2 and the additional multipliers TR/EL ,RR/TR and/or use ratio will anyway end up making M value <= 100 kgCo2 and in my mind we can err on the side of reporting higher value of M. Thoughts ?

2) Another principle that I am using here is that we should try to make SCI calculation as simple to use as possible. Getting into the details of how to calculate TR/RR or TS/RS will end up taking up lot of cycles that could be rather focused on efforts to reduce the energy, hardware or carbon aware quotients

[AirLoren]

@srini1978 I agree all you said except this

For example if M value is 100 KgCo2 and the additional multipliers TR/EL ,RR/TR and/or use ratio will anyway end up making M value <= 100 kgCo2 and in my mind we can err on the side of reporting higher value of M. Thoughts ?

The use ratio (UR) is lower than 1. Then TE (TR/(UREL)) will be higher than TE * (TR/EL). Your statement is true only if we don't introduce the use ratio.

[srini1978]

@AirLoren Thanks for the clarification. Somehow in my mind I thought use ratio was in the numerator. Missed that part.

[AirLoren]

@srini1978 I fully agree that we should keep SCI calculation as simple as possible. If we want to manage all use cases (On prem, Public cloud PaaS, FaaS and IaaS) the formula will be too complex. Then we should accept some tradeoff. In my point of view, FaaS and PaaS impact is quite impossible to evaluate, at this time, because we don't know anything about the infrastructure used by the cloud provider to run these services. For example, I have a small function running when a file is uploaded on Onedrive (4 to 6 times a month). This function runs far less than 1 minute per month but the infrastructure and software continuously checking Onedrive to trigger my function should run every time. This infrastructure is shared accross many client but I have no idea if its negligeable or not.

[srini1978]

@atg-abhishek @AirLoren @Henry-WattTime One possible option to make the calculation simple, atleast in the cloud context is :

1) For a given embodied carbon value of M, let us consider the amortized value /year based on the lifespan of the device. For example if a Dell server has embodied carbon of 1000 Kg and it's expected lifespan is 5 years, then the amortized value /year is 1000kg/5 = 250 KgCo2. 2) For cloud providers, we get a monthly invoice . We could estimate the total cost of running the software prior to deploying the software (planned cost) Vs actual cost of running the software (actuals) from the invoice. Ratio = Actual cost of running software/planned cost. (Assuming that the SKU prices didnt increase or change year over year)

We can assume this ratio to be the same ratio of usage of infrastructure and use this ratio .

From a tracking perspective: the key thing to keep track of is if this ratio keeps getting lesser year over year (tends to 0 but it can never be 0).

Hence M = Amortized value of TE /year * Ratio .

This formula atleast will work for all cloud hosted services - PaaS, FaaS and even IaaS

[Henry-WattTime]

Working Group: currently UR (utilization ratio) is hard (nigh on impossible) to extract from providers. Would like to revisit this in future version of the specification. # #

[AirLoren]

why not setting it to 1 by default to keep it in the formula and allow organizations able to define it to be more precise?

[seanmcilroy29]

WG agreed to move this issue into discussions