Extending scope of Carbon Aware SDK

[YaSuenag]

I'd like to propose extending the project scope of the SDK.

When I tried current version of SDK, I’m aware that the SDK is only focusing on gathering CO2 intensity (parameter I for SCI score) for each location, however I think it would not be enough to apply to production systems.

Fig. Carbon Aware SDK components from project proposal (GSF members only)

We should support recording SCI parameters and providing “current” CO2 intensity (I) for on-premise or cloud environment because we assume the SDK would be used to build pipeline, ML input data, and scheduler / router on Karbonates. This means the scope of Carbon Aware Core should include some components of “POSSIBLE GSF PROJECTS” (such as energy consumption, data providers, etc).

Use case 1: Carbon-Aware scheduling

We want to deploy our apps on an environment with lower CO2 intensity (I) if we have multiple choice of location. Therefore, we need “current” CO2 intensity (I) values from reliable sources to determine which location we should deploy. This should include data from data center (on-premise facilities) since some data center has their own mechanisms to provide energy such as solar panel. (this type is not supported , for example, by electricityMap)

Use case 2: Recording Energy Consumption Data

Eventually, we will use SCI score ((E x I) + M) per R) to evaluate whether our apps on data centers (including cloud environments) is carbon friendly. To achieve this, SCI requires the value of energy consumption, marginal carbon intensity, and embodied carbon emission. Though we cannot use them for the first deployment using SDK (as we never know E, R parameters before running application on Server), we should record data (E, I, M) in SDK to support future SCI calculations.

[YaSuenag]

I've sent PR for this discussion in #57 . I think this PR would cover this proposal.

If this proposal and PR is accepted, I want to add plugin implementation for on-premise - it supports measuring energy consumption.

[Sealjay]

This is really cool. I think the related projects we should discuss in the OSS WG, but the extension sounds like a great idea. FYI @dtoakley

[YaSuenag]

My colleague @yuu1127 explaind about this in last OSS WG (11 May, 2022), but we couldn't discuss for details at that time.

I think this proposal affects to entire of the SDK because it will change interfaces. So I want to discuss about this ASAP because other folks start to work the SDK (e.g. WattTime integration).

[Willmish]

I propose we reactivate this thread after v1.0 goes live, as this is an interesting proposition that needs some more thinking about from all of us.