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
Building the CarbonQL with a customer First approach
I was listening to the recording this week and sharing some initial thoughts around how we could go about prioritizing which user stories to focus on initially. Please feel free to add your comments in the discussion thread.
• From a requirements perspective, Amadeus is going to provide us information on Network utilization, memory utilization, CPU utilization and storage size. This is for a “sample” app architecture that they will be providing.
• Similarly, Aditi Garg mentioned that she would share a customer scenario for which she requires help in calculating carbon emissions.
• I have some traction coming in from an MSFT team who wanted us to be able to provide carbon emissions for an AKS architecture that they are releasing in KubeCon. They said they will enlist the help of CarbonQL to provide them emissions value.
• The other idea I had is to liase with our own internal customers: the case study creators who can provide inputs and feedback on the issues they faced while doing carbon calculations for their case studies.
Armed with these “user” requirements, can we drive the development of the API or SDK (whichever we agree upon). For example, if Amadeus gives us the telemetry that they said they will give for an application that is composed of bare-metal, cloud services and laptops we aim to build a first release that calculates carbon emissions for that app irrespective of the complexity of the underlying services.
Similarly, we can gather requirements from all other customers and create a “Least common Multiple” of these and build the v1 Scope of the CarbonQL project.
Also listening to the recording, I heard that we could exclude end user devices for now, so we will focus on only multi-cloud, bare-metal, networking pieces and we can stitch the output with a couple of datasets.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Building the CarbonQL with a customer First approach
I was listening to the recording this week and sharing some initial thoughts around how we could go about prioritizing which user stories to focus on initially. Please feel free to add your comments in the discussion thread.
• From a requirements perspective, Amadeus is going to provide us information on Network utilization, memory utilization, CPU utilization and storage size. This is for a “sample” app architecture that they will be providing.
• Similarly, Aditi Garg mentioned that she would share a customer scenario for which she requires help in calculating carbon emissions.
• I have some traction coming in from an MSFT team who wanted us to be able to provide carbon emissions for an AKS architecture that they are releasing in KubeCon. They said they will enlist the help of CarbonQL to provide them emissions value.
• The other idea I had is to liase with our own internal customers: the case study creators who can provide inputs and feedback on the issues they faced while doing carbon calculations for their case studies.
Armed with these “user” requirements, can we drive the development of the API or SDK (whichever we agree upon). For example, if Amadeus gives us the telemetry that they said they will give for an application that is composed of bare-metal, cloud services and laptops we aim to build a first release that calculates carbon emissions for that app irrespective of the complexity of the underlying services.
Similarly, we can gather requirements from all other customers and create a “Least common Multiple” of these and build the v1 Scope of the CarbonQL project.
Also listening to the recording, I heard that we could exclude end user devices for now, so we will focus on only multi-cloud, bare-metal, networking pieces and we can stitch the output with a couple of datasets.
Beta Was this translation helpful? Give feedback.
All reactions