Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename and large update to spec #72

Merged
merged 2 commits into from
Aug 10, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 7 additions & 53 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,62 +1,16 @@
# carbonQL
# Impact Engine Framework

Modern applications are composed of many smaller pieces of software (components) running on many different environments, for example, private cloud, public cloud, bare-metal, virtualized, containerized, mobile, laptops, and desktops.
Every environment requires a different way of measurement, and there is no single solution you can use to calculate the carbon emissions for all environments.
The friction to measuring software emissions isn't that we need to know how, it's that we run software on many things and each thing has several different ways to measure.

## Solution

Therefore, the intent of this project is to build a framework codenamed *carbonQL* that you can use to extend and measure software emissions for every runtime environment. If your application runs on bare-metal servers in the private cloud, virtualized servers in the public cloud, mobile, desktop, and laptop end-user devices, the carbonQL framework gives you data for all of them.

The carbonQL is:

-**Opinionated**: It’s the expertise in software measurement codified into software. Rather than giving you options, it gives you answers.

-**Ubiquitous**: Whatever the environment, bare metal, virtualized, mobile, IoT, carbon QL project will always be able to give you numbers.

-**Declarative**: You express your intentions, needs, and context, and carbonQL selects the correct measurement methodology. For example, if you are calculating a SCI score, the carbonQL framework will return you data that meets the requirements of the SCI. Likewise, if you are calculating for GHG reporting, it will return you information that meets the requirements of GHG reporting.

-**Free**: carbonQL is open source and comes linked with public data sources that are free to use. Using the library doesn't cost anything; however, the free sources might be limited.

-**Extendable**: The framework can be enhanced to leverage more advanced commercial or private models, for example, real-time electricity carbon intensity feeds.


**Audience**

-Software monitoring products looking to add carbon as a software measurement metric.
[Impact Engine Framework](https://greensoftwarefoundation.atlassian.net/wiki/spaces/~612dd45e45cd76006a84071a/pages/17072136/Opensource+Impact+Engine+Framework) is an [Incubation](https://oc.greensoftware.foundation/project-lifecycle.html#incubation) project from the [Open Source Working Group](https://greensoftwarefoundation.atlassian.net/wiki/spaces/~612dd45e45cd76006a84071a/pages/852049/Open+Source+Working+Group) in the [Green Software Foundation](https://greensoftware.foundation/).

-Software optimization tools looking to represent optimizations in terms of carbon reductions.

-Developer tooling. Developer and Dev/Ops focussed products looking to add carbon measurement.
-Sustainability professionals who are interested in calculating the carbon emissions for reporting.

-Organizations looking to measure-for-action the carbon emissions reduction from migrating a software application from on-prem to the cloud.


## Integration with SCI Open Data

At the backend carbonQL project is planned to be integrated with multiple datasets that can be used to provide carbon emissions values. These datasets could be public or private as well.

As per SCI specifications, carbon emissions values are required for the 4 different components of the SCI equation E, I, M and R. There are reference emission value datasets like Climatiq, Boazvita, Cloud carbon co-efficients that need to be leveraged to provide values for these SCI components. We refer to these emission value datasets as SCI open data and there is a curated list of datasets available as part of the [SCI guidance project](https://sci-guide.greensoftware.foundation/)


## Architecture of the Solution

The carbonQL acts like a facade, it might call out to other APIs, CSV files, DBs, the underlying model can be of any format and in any location.

![CarbonQL_architecture](https://user-images.githubusercontent.com/10396742/219698334-eb98bcfd-f968-400a-9ffd-b0aeaee8823f.JPG)
**IEF** is a framework to **M**odel, **M**easure, si**M**ulate and **M**onitor the environmental impacts of software

Modern applications are composed of many smaller pieces of software (components) running on many different environments, for example, private cloud, public cloud, bare-metal, virtualized, containerized, mobile, laptops, and desktops.

It provides a common interface to all the various models, makes opinionated decisions about which model to use and how its results should be transformed into the format you need for your calculations. In the above diagram we can see that the carbonQL is intended to connect to various backend carbon datasets like Climatiq, Cloud carbon co-efficients to bring back emissions data given the usage.
Every environment requires a different model of measurement, and there is no single solution you can use to calculate the environmental impacts for all components on all environments.

The interface definition would be generic i.e irrespective of the underlying data sources (hereafter referred to as models) being used , the method names across all the data models would be the same. This would provide uniformity to the callers or users to use the framework. For example some of the methods we have envisioned in the interface include :
- Create
- Historical
- Snapshot
- Stream
- Dispose
The friction to measuring software emissions isn't that we need to know how, it's that we run software on many things and each thing has several different ways to measure.

Also to ensure that we provide uniformity , we will try to keep the method signatures uniform across the different functions. We would try to use specific datatypes only when it is required but try to build methods that accept arrays and dictionary objects that can help the method to be scalable across different programming languages.
Read the [specification and design docs](docs/Impact%20Engine%20Framework.md) to begin.



19 changes: 19 additions & 0 deletions docs/Background.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
---
author: Asim Hussain (@jawache)
abstract: Discussion of the history and evolution of this project in the GSF.
---
# Background

This project has evolved over the two years of the GSF's existence.

During the development of the [SCI](grnsft.org/sci), we acknowledged that the biggest blocker to adoption was data regarding the emissions of software components on different platforms and runtimes.

We then launched the sci-data project to help create the data sets required to calculate an SCI score.

After some investigation, the original sci-data team quickly realized that there were several existing data sources, and many more were in development, free open source or private commercial. The future challenge wouldn't be to source them, it would be knowing which data set to use for which use case, how data sets differed in their methodology and interface and when to use one over the other, the pros/cons, and trade-offs.

The project evolved into the [sci-guide](https://sci-guide.greensoftware.foundation/) to document existing data sets, providing guidance for when to use one over another and how to use it to create your own software measurement reports.

Finally, we had enough information, and SCI use cases started to be written. This was a milestone moment.

But now we are in the next evolution, to have software measurement be a mainstream activity. For this to be an industry with thousands of professionals working to decarbonize software, for businesses to grow and thrive in a commercial software measurement ecosystem, we need to formalize software measurement into a discipline with standards and tooling. The SCI Specification is the standard, and the [Impact Engine Framework](Impact%20Engine%20Framework.md) is the tooling.
Loading