Converting Cloud Metadata into Energy and Calculating Consumption

In this episode of Environment Variables, we dive into a key highlight from Decarbonize Software 2023, featuring Asim Hussain's talk on the Green Software Foundation's newly introduced Impact Framework. This innovative framework aims to model, measure, simulate, and monitor the environmental impacts of software. Asim begins with an insightful overview of the framework's capabilities and objectives. Later, project leads Srinivasan Rakhunathan and Navveen Balani join the discussion to delve deeper into its applications and potential. This episode offers an essential understanding of how the Impact Framework is set to revolutionize the way we assess and mitigate the ecological footprint of software development and use.

Asim Hussain: Send us a manifest file so we can see not only how much is this thing going to cost us and how are you going to architect it, but what are the carbon emissions of your proposed approach? And let me compare versus the other people proposing approaches and not just compare on cost, but compare on carbon as well.

And I thought that was really, every time we talk to people about Impact Framework, people always come up with Another use case.

Hello and welcome to Environment Variables brought to you by the Green Software Foundation. In each episode we discuss the latest news and events surrounding green software. On our show you can expect candid conversations with top experts in their field who have a passion for how to reduce the greenhouse gas emissions of software.

I'm your host Asim Hussain.

Chris Skipper: Hello and welcome to Environment Variables. Today we've got a highlight from the recent decarbonized software 2023 event. We'll be showcasing the talk from Asim Hussain about the recent Impact Framework, which is a framework to model, measure, simulate, and monitor the environmental impacts of software.

That has been introduced by the Green Software Foundation. To begin, Asim will do a brief overview of the framework and later on he will be joined by the project leads Srinivasan Rakhunathan and Navveen Balani. He is introduced by our fabulous director of communications and member relations, Namrata Narayan. So it'll be her voice that you hear first.

So without further ado, here's the introduction to the Impact Framework.

Namrata Narayan: It's the moment we've all been waiting for. Well, one of many. I'm delighted to introduce our chairperson and exec director, Asim Hassan, back to the stage. The GSF believes the most important step in greening software is measurement. An Impact Framework will enable us to measure software across environments and software types. But don't take my word for it. Asim, over to you for a full, brief, and exclusive look.

Asim Hussain: Thank you so much, Namrata. And I was really excited today to see several talks now focused on measurement from Siemens, we just heard from, and from Code University. We're all aligned, and we're all converging to the same point. 2024, I believe, will be the year of measurement. That doesn't surprise me, because when we first launched the foundation, We asked all of our members what their pain points were, and the overwhelming answer was measuring.

And we've been trying to explore all the different avenues of measuring over the last three years of the foundation's existence, and we've made lots of progress. And I mentioned earlier on, we, the stuff, the standards working group launched the software carbon intensity specification, which has reached ISO.

We're very excited about that. It should be in the catalog shortly. We've incubated, incubated various data projects because we knew data for measurement was a problem. And we've drove the creation of, of a number of case studies, software measurement case studies. But now we're in the next evolution to have software measurement be and 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. And we believe Impact Framework is the tooling and SCI is one of the standards.

Today I'm going to explain a little bit about Impact Framework now, then I'll give a demo. I spoke to some of our other co leads on Impact Framework about potential future use cases for the tool last week when I still had some hair. And we'll play that afterwards. So Impact Framework aims to make the environmental impacts of software easier to calculate and share.

Impact Framework allows you to calculate your application's environmental impacts, such as carbon, without writing any code. All you have to do is write a simple manifest file. Sometimes we call it an IMPL. And Impact Framework handles the rest. I want to be very clear. It's called Impact Framework, not Carbon Framework.

Some of the things I'm going to show you today is about measuring carbon, but our goal for the framework is to go beyond carbon, to start measuring all sorts of different environmental impacts. There are three concepts in Impact Framework. There's the manifest file, which contains either raw data or information about where to get the data from to do your measurements.

Then we have models. How do you get from that raw data to, let's say, carbon or water or some other impact? To do that, we need to use models, and we can chain models together to calculate your impacts. Just in a pipeline, just like a Unix pipeline. Then we have Impact Engine itself, which is the CLI tool, the command line interface.

You pass the manifest file to it, and it computes your impacts of your software application. I would say it's saying transparency builds trust. You don't just calculate and share the number, the final number that the Impact Framework gives you. You share the manifest file. You share your workings out. You share.

You share all of your data, all of your assumptions, all of your coefficients so other people can verify it, can challenge it, can compute it themselves, can fork it, can adjust it, can change some of your values and run it again. It's all about being transparent. Only when you share your working out can anyone trust your calculation.

The project is entirely open source and composability is a core design principle. We want you. To be able to create your own models and plug them into the framework or pick from a broad universe of open source models created by others. We've got some to show you right now, which I can do in the demo, but our goal is for there to be thousands of models all working together.

What I'm going to show you today is a result of almost a year's worth of effort. We first started a talk at this project was proposed in December last year as an incubation project, and as it evolved into something incredible. And today we're ready to release the alpha version. Alpha. Means use with extreme caution.

There are bugs. I was trying it for the demo today. I found some more bugs. This is a buggy product. We are looking for early adopters who are comfortable with buggy software, non backward compatible changes. It's moving very fast, but if you are, if this is something that you're interested in, please try it out and please give us some feedback.

But you understand you're on the bleeding edge here. The sense of excitement from everybody involved is something I've rarely seen in this space. It's a bit nerdy. I'm about to show you a bunch of YAML files and get really excited about it. But trust me, these YAML files, I think are going to change the world.

One of the things I say about... My long term goals, and I hope the Foundation's long term goals, to do with sustainability is that we want to do to sustainability what open source did to software. I'm not talking about small, iterative changes. I want to change the game, and I think the Impact Framework will do just that.

You can find more information about Impact Framework at if. greensoftware. foundation. That's if.greensoftware. foundation. IF will also be the main focus of our yearly hackathon, which will be coming in February 24. We'll have all sorts of prizes this time around, including an under 18s prize and prizes for non technical contributions, so watch this space.

So now let's start the demo. So I've got an empty folder here. Well, it's not empty, but first you would create an empty folder where we can do our work. Impact Framework is built in TypeScript, so you can either use NPM or Yarn to initialize a space to work in. So I'm not going to run these commands in the space of interest, but you would probably run Yarn in it to initialize the space.

And then we want to start adding the CLI and the framework itself. So we do Yarn, Add. Run soft slash Impact Framework would bring in the framework itself. And we're also going to be using some models, some of those models I spoke about. So we've built some of our own models and we would install them in using IF models.

All of this, by the way, this is a tutorial at if. github. com. greensoftware. foundation. So you don't have to be furiously writing this out. And we've also got some other models in an unofficial models package as well. So after you've run all of that, what you need to do is you need to create a manifest file.

I mentioned that manifest file earlier on. Now I've already got a manifest file written here, so I'm just going to open it up. Here we go. So, this manifest file is a very simple one. It's going to compute the carbon emissions of a server we have running on Azure. Manifest files can be much more complicated than this.

Compute different software components, compute network, front end servers, user stories, campaigns, whatever you want. But for this demo purpose, we're keeping it very simple. Just one server. Let's walk through the YAML file. I'm just going to show you, let me just make some space here for a second. I'm just going to go through a couple of the aspects, the areas in the YAML file so you can understand it, the manifest file.

I'm going to first go through the initialize. So this is where we load up and globally define all those models that you want to use in your application. I'm going to go through some examples of this. You're going to see what I'm talking about. You would define where you're loading this from because you can, you could create a model.

Which you install. This is not, we expect a universe where there are thousands of models and you're just cherry picking which models you need to use to calculate your emissions. Some are loaded from unofficial models. We're not Microsoft, so it's unofficial for us to maintain the Azure model. But some of these are from our official models.

If it's coming from IF models, we're going to maintain this. We're committing to maintaining this. So this is the path of the module where it's coming from. This is the name of the class you're loading. And this is just how we're going to refer. to this model in the rest of the YAML file. Let me scroll down to another area, which is called a graph.

So this is where we describe all the software components we want to measure. In our case, we just have one server. Uh, cause again, we're keeping it very simple, but you can have dozens, hundreds of software components in it. And it, but it's up to you how you want to group them. Do you want to group all your servers by region?

Do you want to have a front end, a back end networking? Database, however you want to split it up and group it is up to you. We leave that very much up to you. It's just different components. Um, let me dig into my server then. So, this little, we call it a component node. This component node contains all the information required to measure this.

Server. I'm going to start from bottom to top. So I'm first going to start at this node called inputs. These are the inputs. These are the things you've gathered and measured about the server. What we call a key concept in Impact Framework is something called an observation. This is one observation. An observation is just something you've measured about your running system at a given time and for a given duration.

And these are the parameters of your observation. You can actually have multiples of them. We would expect you to have, maybe you grab observations every five minutes throughout the day. So we'd have a large array of observations. I've just got one here. The next thing to really explain is this thing at the pipeline at the top.

I mentioned before that we were all about models and a pipeline of models. The data here is passed in to the first model at the top, and it's just a piece of code. It's just a piece of code. And you pass in that observation and whatever outputs it passes it to this model. And whatever that outputs, it passes it to this model, to this.

And the game we're playing, the game we're playing is we've got this data here, this observation, some data about a virtual machine, and we want to convert this in this use case into carbon. And in order to do that, we chain these models together. They all work and play nicely together to convert all of that data into carbon.

Now to explain this all, the best thing to do is for me just to comment out. Some of the other models, I'm going to go through it one at a time, and I'm just going to run. The command, which is impact engine, you pass in the input file and you pass in an output file and you just let it run. The final thing I'll just measure, talk about while, while that's running is this config section here.

There's a bunch of different places you can configure models. This is one of the places you can configure models. And here. We just have some configuration values, which we're passing into some of those models. And this configuration here is specific to this component. So different components can have different configurations.

There's also a global configuration as well. So you can see here that file has completed, that execution has completed. I'm going to open up the results on this slide here. And excitingly, what we've got at the bottom is it's the same file, but as well as inputs, we now have outputs. And what the Azure importer model does is we've passed it some data.

To, to query and it's going into the Azure Monitor system and it's extracting out information about CP utilization, the memory available, it's 'cause this has all been captured on Azure and we're extracting it as a series of time stamps. What I've said here is, for a one hour period of time, give me 12 five minute buckets of the average CP utilization and, and other data.

And it captures other data as well. And a very important piece of data is what is the instance type of this Azure, the Azure machine that I'm running on. What is the instance type? We know it's Azure because the Azure instance, the Azure importer gave us that data. We know the instance type, but in order to calculate emissions, we need to know what processor is this instance type.

What processor is it? And for this, what we've built is another model called Cloud Instance Metadata. I am going to just run this whilst I talk. So cloud instance metadata is a module we're actually maintaining. There's actually very challenging, there's no real globally maintained database of telling you this instance type is this processor.

Every cloud provider is different, every cloud provider has lots of different rules. So we tried lots of different solutions, but what we ended up with is we're actually maintaining this model ourselves. We're maintaining a database of, we've only got Azure for now, but for Azure. This instance type is this processor and other information about that, and we will, we commit to keep maintaining this for the long term, and hopefully it's all open source, so if you see something missing, please write a pull request and add it yourself.

So you can see now it's complete. I'm going to go into the results. And in the outputs, again, you can see a couple more bits of information have been added. For instance, the physical underlying processor and another very important value, which is the thermal design power. So you can see here, very interestingly, that one instance type, if you actually look at the Azure documentation, it doesn't tell you exactly which underlying processor you're going to use.

Because when you use the instance type, you may get one of these three, one of these underlying processors. So it's quite challenging then to figure out what to do. So we have certain rules and logic which we've Worked with the community to describe and we effectively picked what's called the most energy hungry processor of that list because it's always better to overestimate energy than underestimate energy.

But now we have physical processor, we have thermal design, we have a bit more information from that cloud instance metadata. We still need, we need to convert this into energy to get to carbon. We need to know energy. What are some models that we can use to convert this data into energy? Now a really, uh, popular model that people use all the time is tes.

It was generated by a gentleman called Benjamin Davies, who worked at tes. It was a couple of years ago. It was published, and he figured out a, a, a generalized power curve by analyzing hundreds of servers, different types of servers, and it's quite well used. It's using a lot of our case studies. It's used in a lot of places is, is this tes curve and what Tes Curve needs in order to estimate energy is it needs a C utilization and it needs to know the thermal.

Design power of the processor. Now we have that data, we can run the script and it will effectively do a lookup of both of those bits of data to generate some energy. And, uh, EagleEye, if you would probably see that I also, uh, uncommented sci e. Sci e is just a little helper function that we have to, to copy some data into other, into an energy field, which is useful for the following models.

And you can see now we've calculated energy. So we've basically now, we've got to the point of... We know how much energy for this five minute period we are consuming. And this is in kilowatt hours, 0. 00284 kilowatt hours. This is one of the bugs. I don't, I want to make sure there's one of the bugs we discovered today.

That's slightly off. We will be fixing it tonight, but this is the, now we have energy. Now we have energy. How do we get from energy to carbon? Now, what you need to get from energy to carbon, operational carbon, I should say, is you need to know how clean or dirty was the energy. That is something called grid carbon intensity, and you would need to know every grid has a different measure of grid carbon intensity at different times, and we have several models that we can use in order to calculate grid carbon intensity.

There's a supplier, one, uh, Two electricity maps on Watttime are two of the biggest suppliers of this data. They're both members of the Green Software Foundation. We could be using the Watttime model because we've created one, but just to demonstrate another piece of functionality, what we've done in this case is we've actually just hard coded it.

There are some cases where you want to actually know what the grid carbon intensity every five minutes. There are other cases where you just want to use an annual average. And here's something that's very important. We've put in here 951 grams per kilowatt hour. This isn't hidden away in Appendix 96C of PDF 43.

It's in the YAML file. It's transparent. You don't, when you're being shared this YAML file, if you don't like this, you can go, Well, you know what? I actually want to use the Watttime model to actually get the real time energy or real time carbon intensity. Or actually, I don't agree with your value. I think it's 951.

This is what's so important. Transparency builds trust. We want to share everything, all of your workings out, all of your coefficients, all of your data. That's what you share, not the final number. So now we've run CIO. If we go back to the results, you can see at the bottom, we now have operational carbon.

So we finally got some carbon value. So for this five minute period, it's 2. 7 grams of carbon. And let's scroll down, that's 2. 708. And I think there's, hopefully there's one that's a bit lower to prove that it's working. Hmm. Well, it is working. It just says 2. 7. That's because it's hard to find the peaks right now.

But it's there. 2. 7 grams of carbon per five minute period. But we also want to include embodied carbon. We want to include embodied carbon. We want to include other types of carbon emissions. So, other... Components of the SCI calculation. So obviously being a GSF, we focused on SCI. So now we've also got SCIM, which is, it gives you the embodied carbon.

It's very basic right now. You have to provide a lot of data manually, but we're looking in the future, some of the things we're looking to expand is to, is to make this a bit more automated. So again, it tries to figure out what the embodied carbon is from the instance type and just calculates it more manually.

And SCI then actually calculates a SCI, a SCI score. Thank you. So let me run that again, and then now I have a slight, uh, awkward pause, I'll wait for that to run. And again, it's just that this, the really important, I was trying to, I cannot reiterate it strongly enough, you do not share the final number, you share the manifest file.

Manifest files are executable, there's no need to share the final number, you just share the manifest file and the next person just runs it, and they, and it gets the same data. You can actually hard code the actual data, you don't need to put the Azure, So you can actually put the results of Azure as inputs, and then that would actually be a static file that you could share.

So now that it came through and we can see, here we go, we've got the size score, we've got the embodied carbon per 5 minute period, and we have a size score of 32 grams per hour for that 5 minute period, and a 32. 4 per hour for that 5 minute period, and a 34. 2 per hour for that 5 minute period. So now we've got it.

We converted some raw imports into carbon emissions. Okay. So that is the very final thing I will just mention really quickly is, let me talk about another model that's been built by Intel called IEE, Intel Energy Estimator. Intel Energy Estimator is a drop in replacement for other energy models like TEEDS.

It just has much more accurate energy estimates for Intel policy. It actually has a... Data for each and every Intel chip type. Um, but the, and this is how you would configure it. And the power of IEE is that I can just go into here. And just drop in IEE. Each of these models has standardized interfaces and standardized parameters.

Standards is what creates the ecosystem. By having standardized models, we can plug and play, we can cherry pick, we can tune it and get exactly your calculation pipeline that works for you. So let me run that. Really quickly, and as it's running, I'll just talk a little bit more about how it actually works, because you can see here, it's a little bit different.

I mentioned that Impact Framework is TypeScript, and that means that, um, every model that we've seen so far has been written in TypeScript. They might call out some API, but it's written in TypeScript. You can see here that the IEE was built in Python, and what you can do with Impact Framework is you can actually call out to a CLI tool and do a shell command instead.

So you don't have to write your models in TypeScript. You can actually write your models in any language that you want, as long as you can create a CLI tool, which adheres to a specific open standard that we've created. It will plug and play into the Impact Framework, which is really exciting. That's all for the demo today.

You can find more information again, as I said, at If. greensoftware. foundation. And as a reminder, also in Feb next year, we'll be hosting rCarbonHack again, and Impact Framework will be the focus, so please watch this space. Next up, I spoke to Navveen and Srini, two other co leads of the project, about potential future use cases.

That was last week when I still had hair. Roll the tape, please. So with me today are two of two of the co leads of Impact Framework, Srini and Navveen. Navveen, why don't you give a quick introduction to yourself?

Navveen Balani: Yeah, thank you Asim. Hi everyone, I'm Navveen Balani. I'm a Chief Technologist with Technology Sustainability Innovation Group, working at the intersection of technology and sustainability. I've been involved in the foundation right from its inception and leading various projects in the foundation. Over to you Shimi.

Srinivasan Rakhunathan: Hey, thankNavveenen. Hi everyone, this is Srini. I'm part of Microsoft. I've also been with the foundation since the beginning and really have got an opportunity to do a lot of learning, multiple projects, all open source, so many people, so just love the energy here.

Asim Hussain: I remember the journey of all the projects that both of you have been part of since the very early days, and we've all started working on kind of measurement with the SCI, and you both started looking at... To calculate carbon emissions of software, we needed, we knew we had a data problem and you both went away and started taking the lead on the SCI data project and really started becoming experts in just the data aspects of software.

I won't go into all of the iterations, but we had a couple of iterations there until we landed on Impact Framework. I think everybody's just seen, we've just given a demo of Impact Framework to a lot of people out there in the world. And they've probably seen like how it works, like in a very practical sense.

But I wanted to just have you two here so we can talk a little bit about future thinking. This is what the Impact Framework is right now. What do we think it can be used for in the future? It's a very generic, it's very low level. So I'm going to throw the floor to Navveen probably to start off with.

Maybe just give us some ideas. Like what, what are your, what, what, what inspires you about this? And what do you think about applications for the future?

Navveen Balani: Yeah, so I think the future roadmap, uh, I think would be to extend the back engine framework for measuring the SCI scores for an AI application, uh, both during training as well as inference. And, uh, from a carbon emission measurement, uh, like during the training phase, uh, so we need to capture the server types like, uh, GPU and TPUs, have data for embodied emissions and capture various utilizations like, uh, memory and CPU. Uh, I think next we need to look at how we could integrate with available models or build models that provide the carbon emission calculation based on available data and obtain the SCI score. And also include various other factors like data processing and storage as part of the SCI functional boundary for overall AI training. And for the inference part, I would say, uh, this might be a bit, uh, tricky, uh, based on your deployment model. Uh, for instance, uh, let's say if you're hosting and have a control of the servers, uh, you can follow a similar measurement approach as in training, uh, and using function units, uh, such as number of, uh, inference calls. But if you have a deployment model, And let's say, which involves maybe a generative AI system, like sending prompts to a charge GPT or any LLM models. You basically need to rely on some proxy data such as API latency, maybe a number of iterations to get the right prompt response. Or overall prompt, uh, context and maybe the length and so on. So this is an area of exploration, uh, where we need, uh, open source, uh, communities to collaborate and contribute models, uh, based on various, uh, research and findings. Probably in the end, our goal is to basically look at impact engine framework to realize the SCS specification and make it easier to report SCS code for any software workloads.

Asim Hussain: Would you imagine a future where, as people develop papers and as they develop more advanced algorithms for AI, alongside this research, you deliver a manifest file, an impact manifest file where you're, you're explaining, this is this new type of AI algorithm, and this is the impact that the algorithm might have.

Copy it, fork this file. Play around with the numbers, see how it works for you. Do you see something like that as well in the future?

Navveen Balani: Yeah, definitely. That's a good point. Having all the research. Papers, right? Have this manifest file, right? And which can make the research also more compatible. And this can be a framework, right? Which can be used by any practitioners, right? To, uh, deliver their CS code.

Asim Hussain: Yeah, great. Yeah, we definitely need to apply this to AI. It's a big burgeoning field out there and it's a lot of computes going into that space. Shrini, what about you? What thoughts have you been given to this? What have you given to this area?

Srinivasan Rakhunathan: I think AI is a fantastic concept because both the Impact Framework and AI can learn and build and evolve and emerge together. That's a great synergy opportunity, but also on the, the enterprise side, or even the consumer side where you have multiple devices, multiple environments, multiple cloud providers to hyperscale providers. There is a big opportunity. With Impact Framework, because it truly is an open architecture of bring your own model or bring your own calculation algorithm. And at the very, I think when we spoke about it at the inception, the very concept we wanted, we wanted to do is to make it as granular as possible. So you have building blocks on top and any technology, whether you have Node. js, you have React. js or on the server side, anything that you can. You just have to make sure that the granular component is straightforward so that you can apply it for any kind of architecture, whether it is mobile or desktop or cloud provider. And that's a beauty of the model. And that's the beauty of the architecture I feel so that it can scale to any use cases, whether it is a consumer use case or an enterprise use case.

Asim Hussain: Yeah, I love that term, bring your own model. I think let's put that in all the material. I think that's a really good way of explaining it, isn't it? Bring your own model. Yeah, I remember when we were, like, one of the things, like, both of you have been also to the people who've been really at the cutting edge of actually calculating software.

There's not many people in this world who've actually. Put the time and effort to really dig deep and figure out the emissions of, of, of a piece of software. And I think one of the things that we discovered throughout our entire process is, as you're saying, Srini, everything's a little bit different. One model does not work for everybody, you need to tweak it a little bit for every single use case and every single, yeah, there's a lot of tweaking and can bring your own model to the situation.

Navveen Balani: Yeah, absolutely. I think the other area is how do you make sure that you get more people to do case studies, which we had been doing through manual calculations. And that's where the open source community can bring in user models for all their use cases. And we can learn.

Asim Hussain: Yeah. Oh yeah. There's been so, so many conversations to, to get us to this point where this Impact Framework, it's, yeah. So many things we can talk about. One of the things I've, I, I found quite interesting. I, I was chatting to a large enterprise organ, an airline, a large enterprise organization that's an airline.

And they were describing, and I was explaining Impact Framework to them. And they were quite interested 'cause they were, because they obviously put a lot of RF qs out, a lot of requests for quotes, requests for business. And what, and they also have stringent rules regarding the carbon emissions. They won't have carbon limits on the software that they build.

And what they were proposing is when an organized, when they put an RFQ out and they get a bid back from an organization, they were suggesting as well as a bid, send us a manifest file so we can see not only how much is this thing going to cost us and how are you going to architect it? But what are the carbon emissions of your proposed approach?

And let me compare versus the other people proposing approaches and not just compare on cost. But compare on carbon as well. And I thought that was really, every time we talk to people about Impact Framework, people always come up with another use case, which is what gives me so much excitement about this project, because people are seeing solutions that we didn't think about when we've been talking about this for as long as we've been talking about it.

Navveen Balani: I think this is definitely a good use case, uh, think of this as a calculator, right, which you can first create, right, how much emissions, uh, your infrastructure will take, and maybe that can be integrated with your CI, CD, Terraform, just to know upfront, right, what would be the impact. And if you can make it simplify this whole integration via plugins or calls, right, and make it native to each, uh, programmers, right, the tools that they use, I think we'll achieve what we want to achieve.

Asim Hussain: Awesome. I think we're coming up, coming up to time now. So one of the things I wanted to make sure. That we cover is actually we're going to be running a hackathon. We ran a hackathon last year. It was very successful. It was the Carbon Hack with a Carboner SDK, but the CarbonHack will be coming again.

First quarter of next year. And the main theme of the carbon hat will be measurement and measurement with the Impact Framework. And we're going to be looking for people to build models, that'd be cash prizes. People build models, build impulse, and we're going to have. prizes for best documentation, non technical contributions, all sorts of different prizes.

And I'm going to have an under 18s prize as well, which I'm really excited for. So we've got the Carbon Hack also coming up next year, which is, and the main theme is going to be measurement and Impact Framework. And I'm just so excited to have. Have that on our agenda. I just want to thank again, Navveen and Srini, you both have been just key players in the Green Software Foundation since day one, this project evolved on all the work that you've done from the start.

And I want to thank you and I'm really excited to, really proud and excited to have you here working all of us together on this project.

Srinivasan Rakhunathan: Thanks, Asim.

Navveen Balani: Thank you, Asim, and thanks to the community.

Namrata Narayan: Thank you. Okay, so really excited to finally see Impact Framework. I hope everyone sees why we're so excited and hopeful about the impact this open source tool will have on the industry. We've got a lot of questions, so we're going to try and get through, um, two of them, um, as best as possible. So, as an Annie panel asked, Would Impact Framework be recommended for use on a simple website, or is it better applied to a more robust application? And Neil Clark added to that question and asked if a website is hosted via a CMS hosting partner, like Acquia, abstracted quite far away from the actual server, how can we capture observation data?

Asim Hussain: Yeah, and to the first question, absolutely. Impact Framework is very general purpose. Even right now, I've been talking to you about how to measure software emissions of a server. One of the samples we have in the repository, I believe we still have it, is measuring our website's emissions, which website is built using GitHub Pages, it's a static website.

And obviously it's like a normal website. We haven't actually built the models that are required to measure that. Unfortunately, that's a limiting factor is you need models. You need models that convert network bandwidth to, uh, CO2. We were going to use CO2 JS. We need models that perhaps take data from, uh, Google analytics to help then use other data to figure out, well, what are the, what is the energy consumption on the client side?

So it's all limited by models. That's what we're limited by. But yeah, you can absolutely, uh, measure, measure websites. In fact, we've had the spoiler alert. You can measure anything with it. You can measure physical products. And I think the last question was around, yes. How can you measure when you don't even have access to the server?

Absolutely. That comes up all the time. We're building this thing. You build what's called an adapter model. So for instance, there's a lot of things, even in the service base, you don't have access to, like when you're running like, uh, serverless functions, you don't know the server. You just have some other.

bit of information like gigabyte seconds. Again, it's limited by models. We need models that convert gigabyte seconds to carbon, but we've started to think about how to create those models. And again, as we come on to carbon hack next year, we're really hoping the community comes together and starts filling in those gaps.

This is what I'm talking about. We need thousands of these little models. We want to fill those gaps and build those models. And you can cherry pick them together in order to calculate all sorts of carbon impacts. And other impacts, my dream is to like add water, add other impacts. I want to, we, it's called Impact Framework, not Carbon Framework.

Namrata Narayan: Thanks, Asim. Another question from Cristiano Elias. I hope I did not butcher your name. Is certification support of the results output in the roadmap of Impact Framework?

Asim Hussain: It's not currently in the roadmap of Impact Framework, but it is something that we've discussed. For instance, one of the things that's been, we imagine is the models that you use, perhaps in the future, we will generate some official models. which may be used more in a certification, but essentially if there is any certification, it's a certification of the models.

So you might get a whole bunch of models which are useful for a variety of use cases, only this, this certification agency will only approve this small set of models or for this type of. Computation. We only accept this model pipeline. We imagine it's going to evolve something around that, but we're a little bit early.

We're just alpha today. So we're a little bit early on to have any kind of specific roadmap items on certification. But it's something that we've thought about.

Namrata Narayan: Thank you, Asim. I hope everyone was happy with those answers. We did get a lot of, many more questions, but we will answer them at a later time. So stay tuned, subscribe to our newsletter.

Chris Skipper: So that's all for this episode of Environment Variables. If you liked what you heard, you can actually check out the video version of this on our YouTube channel. Links to that, as well as the Impact Framework, can be found in the show notes below. While you're down there, feel free to click follow so you don't miss out on the very latest in the world of sustainable software here on Environment Variables.

Bye for now!

Asim Hussain: Hey, everyone. Thanks for listening. Just a reminder to follow Environment Variables on Apple Podcasts, Spotify, Google Podcasts, or wherever you get your podcasts. And please do leave a rating and review if you like what we're doing. It helps other people discover the show, and of course, we want more listeners.

To find out more about the Green Software Foundation, please visit greensoftware.foundation. Thanks again, and see you in the next episode.