Start by building a common library of standardized interfaces to carbon models

[jawache]

EDIT: The conversation has evolved to creating a standardized set of interfaces to carbon models related to calculating software emissions, see this discussion: #26 (comment)

Hey @srini1978 @navveenb and @Oleg-Zhymolokhov my mind has been racing since Navveen showed me the sci-ontology code last week. I've seen it before but something clicked in my head when viewing it in the context of carbon-ql. May I present this idea in mondays CarbonQL call? I'm not sure if this is a new project OR we official merge the carbon-ql and sci-ontology (and other projects) into one.

A reactive framework which combines the intentions of the sci-ontology, carbon-ql and sci-reporting and sci-case studies project and adds real-time monitoring.

• sci-ontology defines a software boundary, the core services, components and relationships of an application using an SDK like language.
• carbon-ql and the sci-guide/data project aim to make it easier for practitioners to choose the appropriate models and data sources for different contexts.
• sci-casesudies and sci-reporting aims to make the reporting of carbon emissions consistent and understandable, verifiable.
• On top of all of it are newer conversations around the real-time monitoring of carbon emissions vs. static yearly regulatory reporting.

The Reactive Carbon framework is the glue that combined/solves all of the above.

Setup

let App = new App();

App.configure({
    // Configure data sources
})

App
.tick(60) // every 60 seconds

Single Component / Static / SCI

We pass PARAMS and TELEMETRY into the MODEL and it returns us CARBON data.

App
.tick(60) // every 60 seconds
 // .<component>(NAME, PARAMS, TELEMETRY, MODEL)
.vm("web-server",
    {vendor: "gcp", region: "uswest", skew:"ec2standard"},
    [{instances:40, cpu:.33, mem:.25}],
    Boavista.VM);

// Calculate a single SCI score
App.sci({R: (x) => {return x / 60}})

Change Params

We can change some params and see the impact it will have on the final score using the model we are currently using.

App
.tick(60) // every 60 seconds
 // .<component>(NAME, PARAMS, TELEMETRY, MODEL)
.vm("web-server",
    {vendor: "azure", region: "uswest", skew:"ec2standard"}, // ← Changed the vendor
    [{instances:40, cpu:.33, mem:.25}],
    Boavista.VM);

// Calculate a single SCI score
App.sci({R: (x) => {return x / 60}}) // ← Score updates reflecting the change in params

Change the model

We can try out different models and see how this updates the end score, e.g. swap out Boavistas model for Climatiq, or CloudCarbonFootprint, or perhaps Azure, AWS, GCP publish their own models, and maybe the GSF publishes some Generic or Standardised Models.

We can recommend certain models for certain use cases, component types, users can take our recommendations or use their own.

App
.tick(60) // every 60 seconds
 // .<component>(NAME, PARAMS, TELEMETRY, MODEL)
.vm("web-server",
    {vendor: "gcp", region: "uswest", skew:"ec2standard"},
    [{instances:40, cpu:.33, mem:.25}],
    Clamatiq.VM); // ← Try out different models

// Calculate a single SCI score
App.sci({R: (x) => {return x / 60}}) // ← See how the calculated numbers change.

Change the telemetry, play around, simulate.

App
.tick(60) // every 60 seconds
 // .<component>(NAME, PARAMS, TELEMETRY, MODEL)
.vm("web-server",
    {vendor: "gcp", region: "uswest", skew:"ec2standard"},
    [{instances:20, cpu:.66, mem:.25}],// ← What would happen if we doubled utilization and halved number of instances?
    Boavista.VM);

// Calculate a single SCI score
App.sci({R: (x) => {return x / 60}})

Single Component / Static / GHG

We can define the type of calculation we are performing. NOTE: We might need to ask the user to input more telemetry, or perhaps certain models can only do SCI or GHG some thinking needs to be done here.

App
.tick(60) // every 60 seconds
 // .<component>(NAME, PARAMS, TELEMETRY, MODEL)
.vm("web-server",
    {vendor: "gcp", region: "uswest", skew:"ec2standard"},
    [{instances:40, cpu:.33, mem:.25}],
    Boavista.VM);

// Calculate a GHG value
App.ghg() // returns scope 1, 2 (L+M), 3 // ← Can output different formats, GHG or SCI or something else entirely.

Single Component / Historical / SCI

We could pass in an series of values for telemetry and the framework ,could return an array, useful for historical timeseries of carbon scores.

This could be interesting to experiment with carbon aware computing, take existing telemetry, show how the carbon score changes as you choose different times for scaling servers up and down.

App
.tick(60) // every 1 min
 // .<component>(NAME, PARAMS, MODEL, TELEMETRY)
.vm("web-server",
    {vendor: "gcp", region: "uswest", skew:"ec2standard"},
    [{instances:40, cpu:.33, mem:.25}, ← Array of historical telemetry values
    {instances:41, cpu:.10, mem:.26},
    {instances:42, cpu:.23, mem:.27},
    {instances:34, cpu:.45, mem:.28}],
    Boavista.VM)

App.sci()← Returns an array of historical SCI values, a timeseries

Single Component / Real-Time / SCI

If the input telemetry is a real-time stream of data, then the calculation can be real-time as well. Real-time carbon monitoring of applications!

App
.tick(60) // every 1 mins
 // .<workload>(NAME, PARAMS, MODEL, TELEMETRY)
.vm("web-server",
    {vendor: "gcp", region: "uswest", skew:"ec2standard"},
    TelemetryStream("web-server"), ← A connector that feeds in a real-time stream of telemetry
    Boavista.VM)

App.sci().subscribe() // returns a value every 60 seconds

Multiple Component / Real-Time / SCI

As we define multiple components, the carbon framework also define the software boundary, the code below tells us:

• What software boundary they are using to calculate.
• The exact models they are using to calculate different components.
• We (can) know the telemetry they are using to plug into those models.

The code below can be:

• A description of the software boundary.
• An SCI report, rather than a markdown file with free text, it's a piece of human readable code which you can verify, re-run (if it has static data embedded)
• Used to figure out some what-if scenarios, change models, move vendors, change workload types, re-architect your app and re-run to see the carbon impacts.

App ← This defines our software boundary
    .db("sql-server",  {vendor: "gcp", region: "uswest"}, GSF.GenericSQL, TelemetryStream("web-server"))
    .db("mongodb-server",  {vendor: "mongodb", region: "uswest"}, Mongo.MongoDBServer, TelemetryStream("mongodb-server"))
    .vms("web-server",  {vendor: "gcp", region: "uswest"}, Google.VM, TelemetryStream("web-server"))
    .vms("cache-servers",  {vendor: "azure", region: "uswest"}, GSF.GenericVM, TelemetryStream("cache-server"))
    .service("batch-server",  {vendor: "azure", region: "uswest"}, Azure.AKS, TelemetryStream("batch-server"))
    .service("scale-server", {vendor: "azure", region: "uswest"}, Azure.Functions, TelemetryStream("scale-server"))    
    .networking("dc-dc", {vendor: "azure", region: "uswest"}, GSF.GenericNetwork, TelemetryStream("dc-dc"))
    .networking("dc-user", {region: "US"}, GSF.GenericNetwork, TelemetryStream("dc-user"))    
    .frontend("desktop",{}, GSF.GenericDesktop, TelemetryStream("desktop"))
    .frontend("mobile",{}, GSF.GenericMobile, TelemetryStream("mobile"))
    .frontend("tablet",{}, GSF.GenericTablet, TelemetryStream("tablet"))

App.sci().subscribe()

[cronky]

So if I understand this proposal correctly this is about near real time SCI measurement of the application?

One question I'd ask about this is what cost this increased precision comes at? I.e. are we using more compute and storage to calculate minute by minute rather than hourly (I'd assume yes but by how much and is that marginal / pays itself back?). And if this assessment is only being used for reporting purposes is it overkill? I understand the value of it more if the plan is to take action (load/demand shift etc if over a certain SCI value?)

[jawache]

Thanks @cronky, I think you could pick what you want. This could be real-time if you want, or simple scalar values for something more static, it's up to you. I can't imagine the emissions from monitoring an application in such a way to be significant, I'd imagine it's negligible compared to the emissions of the app you are monitoring with the adv that the increased transparency is going to lead to improvements in efficiency.

The thing I think I'm realizing it's it's more about modelling your application.

1- Code up how your application is structured, what are the different software components and some core params that describe it.
2- For each component decide the model you are going to use to calculate the emissions for that component.
3- Hook up the telemetry that model needs in order to calculate emissions.
4- See what number it spits out

Voila you have a model that describes your application, once you have that model you can do some interesting things.

1- Perhaps feed in some historical values, see how the emissions changes over time for a period of time in the past.
2- Swap our some params, see how say changing cloud providers changes the emissions of your application.
3- Connect to real-time telemetry and understand how your applications emissions change based on changed you made recently, be able to link things you just did to changes in emissions.

The conversations evolved somewhat in todays meeting and we're now discussing creating a model library with standardised interfaces, see: #26 (comment)

[cronky]

Thanks @jawache - one thought that has also sprung to mind is could you parse Terraform or other IaC to determine the model of cloud applications (rather than having to spell out the model separately). Could you also somehow discover the model of other applications? I am just trying to think of ways to lower the barrier of entry - rather than having to define the model manually.

[jawache]

Good point @cronky.

Here we want to model what you application is consuming and not just what you are launching if that makes sense, your terraform will never include the mobile app that consumed your API or allow you to model the network traffic.

But I definitely think there could be something built to transform a terraform IaC into a model like this, it would just need to read the file and instantiate the code dynamically.

Part of me thinks if this becomes mature enough for the Carbon Hack 23, if we just created this low level library, then participants of the hackathon might create something to parse IaC and automatically create this model to calculate the emissions.

[jawache]

Feedback from CarbonQL meeting today:

• Through discussion we realized the core thing being proposed is the standardization of the interface for models, so standardizing the function signature for the functions that we call to translate data/telemetry into carbon/energy/embodied.

• E.g. maybe the signature is Model(Name: <String>, Params: <Dict>, Telemetry: <Array<Dict>>): <Energy, Embodied, Carbon>

• This will allow us to normalize interfaces to say Boavista.VM or Climatiq.VM or even managed services like say Azure.Functions.

• Perhaps step one is to define a standardized interface to models and then build a library of model interfaces which can be uses for CarbonQL or any other solution that wanted to easily use a model.

• By standardizing the interface you can swap out models easily, making them interopable and comparable.

• Propose that the first step to building the carbon-ql project is building that model library, we can start with the ones we know well - Boavista, Climatiq, CloudCarbonFootprint and then generic ones for networking and databases.

• Pierre-Luc: A common interface to existing models is actually closer to what he assumed the CarbonQL project was in the first place.

• Pierre+Yannick: The Amadeus infra is pretty unique and abstracted from the Azure model so much that they would need to create an Amadeus model just to reflect how they use infra, e.g. Amadeus.Containers

[srini1978]

Agree on the first steps in building the carbon-ql project will be to building the model library. We can discuss this in next week's call @Oleg-Zhymolokhov @jawache

[srini1978]

Inputs from @jawache
First set of use cases can be used based on Intel's models. This is going to be governed by NDA.
This is going to be irrespective of the underlying infrastructure - on premise or cloud.

Interface could still be public while the backend datasets from Intel is going to be private.

Normalization needs to be done on top of the output from Intel data. The normalization should be done to ensure the ability to compare.

The ability to compare a model from manufacturer with a model from a researcher maybe like Etsy or Boazvita is going to be complex.

--Naveeen
Different approaches can be used depending on the usage.

-- Yasseen
Use case is around AKS. Expectation is that the SCI formula should be used by the tool. From Asim - model would be Azure private dataset or some existing models like CCF and telemetry would be either directly streamed or provided offline.

-- Symon
How can carbon QL help the AKS team in terms of reducing carbon emissions? We plan to create a library of models that can help us get the different value components like E, I, M .

-- Yasseen

1. Intent is to be able to compare 2 infrastructural configurations of AKS and 2) Reporting

Outcome that is expected.
Ability to visualize the impact of the change without making a change.

-- Gadhu
ESG team look at data for e.g invoices , # of hardware like laptops and multiply it with emission factor to get the carbon value.

Output will be a framework for building models. Will greatly benefit consultancies who are in the business of reporting emissions for their customers.

[srini1978]

Scope of the design document

1. Toolkit to build - SDK rather than an API. Situation similar to Tensorflow or nuget package. This could be extendable by any user as per their requirement.
2. Potential to integrate the SCI ontology project and carbon QL project.
3. Framework that would be used to build other projects and hence will not be required to scope anything specific to a use case - for e.g cloud, Boazvita, CCF. The intent is to abstract out all the underlying infrastructural and telemetry details.
4. Will be sharing an empty pull request for all the contributors to pitch in with their comments.