You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the pattern you'd like to propose
According to Carbon Awareness Principle, carbon intensity (gCO2eq/kWh) varies by location. This pattern influences the choice of region based on the value of carbon intensity. This pattern works in tandem with an already existing pattern. The main difference being that the existing pattern does not impact I (Location-based marginal carbon emissions , gCO2/kWh)
The idea is to not only consider the proximity to the users, but also consider the carbon emissions of the physical location and choose the most balanced/sustainable region for your application workload.
Describe specific emission impact from this pattern
SCI = ((E * I) + M) per R
Choosing a region based on the carbon intensity will impact SCI as follows:
I: By selecting the region having lower carbon intensity
e.g.
Region A is in the closest to users compared to Region B
assuming,
for Region A
E = 3
I = 10
M = 1
R = 1
for Region B
E = 5 (Increased due to longer proximity)
I = 5 ( Decreased due to the region having lower carbon intensity)
M = 2 (Increased due to increase in total number of computing equipment traversed)
R = 1 (Same rate)
SCI for region A = ((3 * 10) + 1) / 1 = 31
SCI for region B = ((5 * 5) + 2) / 1 = 27
Hence, Region B should be preferred even if it isn't the closest to the use.
References to this pattern
New concept to the best of our knowledge
Additional context
e.g. Get carbon intensity of electricity consumed for Europe (Stockholm) Region (display aggregated data on yearly basis)
The text was updated successfully, but these errors were encountered:
I would suggest to add this into the "Choose the region that is closest to users" pattern instead of creating a new one. There is also one additional pattern for background tasks and jobs, that is exactly like this #128 .
I think it makes more sense to broaden these two patterns instead of creating a new one. We already have already a lot of patterns for the cloud topic (also thinking about all the PRs still in the pipe).
Thanks for your response.
This isn't exactly like #128 as the later only talks about running some independent jobs in a different region whereas this talks about the entire application.
However, I agree that it's strongly tied to "Choose the region that is closest to users" and I like the idea of broadening it instead.
I'll use this issue to broaden the existing pattern instead.
Describe the pattern you'd like to propose
According to Carbon Awareness Principle, carbon intensity (gCO2eq/kWh) varies by location. This pattern influences the choice of region based on the value of carbon intensity. This pattern works in tandem with an already existing pattern. The main difference being that the existing pattern does not impact I (Location-based marginal carbon emissions , gCO2/kWh)
The idea is to not only consider the proximity to the users, but also consider the carbon emissions of the physical location and choose the most balanced/sustainable region for your application workload.
Describe specific emission impact from this pattern
SCI = ((E * I) + M) per R
Choosing a region based on the carbon intensity will impact SCI as follows:
e.g.
Region A is in the closest to users compared to Region B
assuming,
for Region A
E = 3
I = 10
M = 1
R = 1
for Region B
E = 5 (Increased due to longer proximity)
I = 5 ( Decreased due to the region having lower carbon intensity)
M = 2 (Increased due to increase in total number of computing equipment traversed)
R = 1 (Same rate)
SCI for region A = ((3 * 10) + 1) / 1 = 31
SCI for region B = ((5 * 5) + 2) / 1 = 27
Hence, Region B should be preferred even if it isn't the closest to the use.
References to this pattern
New concept to the best of our knowledge
Additional context
e.g. Get carbon intensity of electricity consumed for Europe (Stockholm) Region (display aggregated data on yearly basis)
The text was updated successfully, but these errors were encountered: