Asim Hussain is joined by guests Srini Rakhunathan and Navveen Balani, the technical leads on the Impact Framework. They delve into how this innovative tool effectively models, measures, simulates, and monitors the environmental impacts of software across various platforms. The conversation explores the framework's unique ability to handle diverse environments, from cloud systems to mobile devices, with an emphasis on the practicality and necessity of measuring software emissions accurately. Highlights include intriguing insights into integrating the Impact Framework with SCI Open Data and the future of green software development. This episode is packed with valuable information and thought-provoking discussions that offer a glimpse into the future of sustainable software.

TRANSCRIPT BELOW:
That simplification that you can just download the code. You need to know a little bit of Node.js or Yarn or how to use it to just be able to run it. As long as you are able to do that, you're pretty much up and ready. Maybe we can even set up a timer, Asim, how long it takes for someone to run it. I bet it will not be more than five minutes.

Asim Hussain: 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. 

Welcome back to Environment Variables, the podcast that covers just about everything to do with sustainable software development. I'm your host, Asim Hussain. I'm the executive director of the Green Software Foundation here to navigate you through the evolving landscape of green software. In today's episode, we've got a special segment lined up to you, joining us are Srini Rakhunathan and Navveen Balani, the brilliant minds leading the project on a much anticipated Impact Framework from the Green Software Foundation. They're here to give us an insider's view of this revolutionary tool designed to model, measure, and simulate and monitor the environmental impacts of software. From cloud environments to your mobile devices, the Impact Framework is set to redefine how we understand and reduce the carbon footprint of our digital world. Before we dive in, let me introduce my esteemed guests and colleagues for this episode of Environment Variables. Navveen, how about, let's start off with you, please.

Navveen Balani: Yeah, thank you, Asim. Hello, everyone. I'm Navveen Balani. I'm Managing Director and Chief Technologist with Technology Sustainability Innovation Group at Accenture working on the intersection of technology and sustainability, and an active member of Green Software Foundation from its inception. Happy to be here and be part of this podcast.

Asim Hussain: Thank you, Navveen. And we also have Srini. Srini, do you want to give an introduction to yourself?

Srinivasan Rakhunathan: Definitely. Thanks, Asim. And wonderful to see you again, Navveen. I'm Srini. I'm part of Microsoft's cloud sustainability team, and I am a senior program manager. I work on sustainable hardware, and as part of Green Software Foundation, I got an opportunity to work on sustainable software with this amazing team.

So glad to be part of this call and happy to help.

Asim Hussain: Before we dive in, just a reminder that everything we talk about will be linked in the show notes below the episode. So I've got a couple of questions that maybe we can go through, but I actually thought, we were having a chat before that, I actually thought it might be interesting for everybody to understand the journey of Impact Framework, because that might actually help people understand what it even is.

I struggle to even explain. I think that's one of the, one of the things I want to chat to you all about is like, how do you even talk about Impact Framework to others? Because I, it can be so many different things to so many different people. It's a little bit challenging. But, yeah. I thought it might be interesting to talk about, you know, the early days, like years and years ago. And I remember, this is how I remember it. So I remember it as: we were all working on the Software Carbon Intensity Specification together, getting really deep and diving into a lot of that stuff, and then we knew we needed to start actually using the SCI and writing case studies. Srini, I believe you were the first person in the entire world to have written a case study on the SCI.

You did it with the MST, FTE shop on sample one. And that was a wonderful moment. I remember that. And then a little bit later, Navveen, you wrote like a very detailed one with kind of a larger case study with, I think, an Accenture use case. Yeah. I don't know. Let's just start off there. Like, what did you guys like, do you remember much about that time?

Like, what were you thinking? Like, what was, what were the challenges I'd say that you had when you were implementing and trying to write some of those case studies, do you remember? You were the first people in the world, almost, who would like actually bother to measure software.

Srinivasan Rakhunathan: You know, it almost seems like, you know, you were on a journey for which you didn't know where to start or where to end. And that's how I used to think when I did that case study, because there was no reference material. There was no guidance. There was no, you know, right or wrong, right? We had multiple discussions with this forum and the extended forum pouring over the calculations again, again, and again, to even figure out whether we are doing the right thing or the wrong thing. So yeah, very, um, anecdotal, Asim, that you're talking about how we started off. I remember there was this SCI data project, SCI guide project. We knew that we were looking for something, but in parallel, we were building these case studies, it's almost seems magical today that we are at this place today. 

Asim Hussain: That's true. I remember one moment, you just, we were getting really deep into trying to figure out the carbon emissions of networking. That was one of the things I remember that we're getting really deep into trying to figure that out. And we were, you were looking at energy expenditure of bits across a network and trying to estimate the carbon intensity and of the embodied carbon that was being used when you're transmitting data.

And I think eventually we just landed on using a coefficient of like gigabytes per, you know, carbon per gigabyte that we got from some source. I remember like that, there was all of trying to figure all of that out. Yeah, we'd had, you're right, there was all those, like, hard won lessons that we've kind of also forgotten about these days as well. Navveen, what do you remember about when you were writing your case study? What was the hardest challenge that you had when you wrote your case study?

Navveen Balani: So I think going back, I think the fundamental challenge that we faced was around data and particularly around whether the data is authentic enough, right, for measurement. Now that's a, that is a problem to solve at that point of time. So, what we did was, why not go with approximations, coefficients, so at least unblock us from a data perspective. And once we have the data sorted out, I think next was around energy calculations, measurements. And since we are all deploying on cloud, right, most of the applications are running on cloud. At that point of time, uh, a lot of these data was transparent to us, right? So whether it's watching machine, choice of processors. So how do you even get to the power emissions and then calculate energy? So I think it's a journey. We went through the data challenges. We went through the vendor challenges. We then we a lot of reference material, which we use. And I would say finally we then had projects like the SCI guide that we wrote, which provided instructions on how can you go about doing a calculation.

We started off with the ontology project where we thought, okay, we'll give them a model representation of your software boundary, then maybe do a one click and then calculate the SCI score. So a lot of these thinking projects finally landed up in the Impact Framework. I think it's been a journey over the last couple of years, right?

And now, yes, at least we have, we are working towards a mature product or an API, right? Which can help enable any developer, right, to calculate SCI based on their boundary.

Asim Hussain: you're right. I think it basically came around, this is, it basically came around, you actually were, with pen and paper, in its rawest form, trying to calculate the missions of some software, you realize that data was the biggest problem. So then we launched like the data project. And I remember the first thinking we had was like, we, maybe we need to go and create some datasets, but I remember when you guys were starting to investigate this stuff, you were saying like, actually, you know, these datasets already exist, it's not a case of like creating a dataset, it's like we're not even too sure which data sets to use for which contexts. So then you wrote the SCI guide, which then became the "if you want to measure this type of information, use this data set and use it in this way, or use this equation and use it in this way." And so then that evolved to, well, now that's just some text on a page, how do we programmatically help people to actually calculate this stuff in, in a, you know, more scalable way, rather than just giving them content. Navveen, you started to look at this ontology project, which I still, SciOntology, I still love that name. We should have run something with it, but that was all about, like, how do you figure out what it is you're going to measure? That is, that was trying to answer the question, "what is an application?" Like, what are you including?

What are you not including in an application? And then like Srini, you and I were talking about this old project called CarbonQL. And what that was trying to do was trying to create like an API where you could ask this API, like anything. Like I have like. Remember we even came up with like a key format.

If you remember, I'm looking at a server, I'm looking at a server of this type. I'm looking at a server of this type on this cloud. I'm looking at it. So you came up with this, like you could request anything from this API and it was like a facade or something, and it had lots of code we had to just figure out all this logic and come back in with an API. And I can't remember exactly how we got from there to like a YAML file and an Impact Framework that may be lost in time. But we evolved from kind of an API to realizing, actually, this is just not something that we could ever do. It's too big as an API. It's like, it's enormous. It's like, how do you measure everything in the world with one API? So we said, actually, this is software that you're going to write. And then we started talking about that. And I don't know, then we just lost in a whole load of a year's worth of conversations, and then we evolved into where we are right now, which is, how would you describe, let me ask you this question.

This is an interesting question for me. I'm going to ask Srini first. When someone asks you, what is the Impact Framework? How'd you respond? Like, what'd you say to them?

 

Srinivasan Rakhunathan: So, and this question has been asked many times by my engineering team when I have presented, how do we, you know, they try to push through my agenda of having Impact Framework. And I'm trying to do that more and more with the projects that I handle. The key difference, the key USP of Impact Framework is this is by developers and this is for measurement of your development efficiency, development processes, code, as opposed to what we had prior, which was focused on, you know, what are the standards governing emissions?

What are the reporting? What is GSG saying? What is X? You know, this is a star contrast where you're trying to do something that is going to help developers measure emissions from their day to day code, day to day, you know, CICD pipelines. So that's, that resonates, uh, with most of the developers when we talk to them.

And they're more curious, you know, uh, I think, like, one of the things that we also talked about, all of us, is to, how do we make it granular such that the measurement is easy. So developers don't just need the final emission number, they need to know what you did to come to that number. They will not accept, you know, just something that you give to them on a piece of paper.

So I think that is the USP of Impact Framework for me. 

Asim Hussain: Like debugging the carbon emissions of your application is giving you that, you need that granularity. So, you know, like someone just doesn't give you like, "Oh, my carbon score is eight." And you're like, "okay, good. What do I do with that?" It's all of the workings out underneath. And I'm, and I thought it was really fascinating because we had an organization come on our last call, didn't we?

And they showed us their manifest file, which is like 13 megabytes large. So they really went granular and it still only ran in like 20 seconds. I was really impressed with that actually. So Navveen, like, how do you describe Impact Framework to, to whoever you need to describe it to.

Navveen Balani: So, so I described as, as Impact Framework. It's probably a framework that helps you realize the SCI Specification. Uh, and what it means is it helps you basically come up with an SCI score based on, uh, your software boundary. As Srini mentioned, right, it's basically a developer framework that can be used for measuring any software application. And I would even say it's a vendor-neutral framework where you can plug and play your own models or use open source models to come up with a measurement and finally arrive at an SCI score.

Asim Hussain: Yeah, I like that. I forgot. Like, yeah, we, you, you, you're the one that kind of, I remember and the calls like would, was gently nudging us back into like focusing on the SCI, which we, I suppose at that point we kind of got lost in some conversations, but that really focused the, the whole team again quite a few months ago. Do you know, I won't give my definition. I'll actually give a definition that Joseph gave me yesterday in a call that we had. Joseph's the PM for the project. And he described in a very interesting way. He said he's now thinking of it as an executable audit for a software application. And I thought that was a really interesting term, isn't it? An audit, like that manifest file that we're creating is like an audit. And the term executable is like, again, as you're saying, Srini, it's not the final number.

It's like this whole thing that you can re-execute and readjust and value. I think it's been coming up a lot. 'Cause everybody's asking me what is Impact Framework and we're constantly trying to come up with a language for it.

And I just want to maybe just acknowledge the fact that we've come up with something very different. We're kind of like setting like a paradigm here and that's why we're struggling so much to explain to everybody what Impact Framework is. And I'm very excited about that because I think that's when you really change things. We can't even really explain what it is right now. We can only tell you that anybody who gets involved gets really involved and they can really see themselves in it. It's our most popular project in the foundation right now. And when I talk to people externally, there's just a lot of interest in it.

And I'm, and I'm just so excited about it. Should I move on to the questions? I've got some questions. Yeah, should we go ahead? Okay. So here's the first question. So can you explain how the Impact Framework simplifies the process of estimating energy and carbon impact for various applications? So pretty broad question.

So can you explain how the Impact Framework simplifies the process of estimating energy and carbon impact for various applications? Hang on, let me ask this question. Does it simplify? Maybe 'simplify' isn't the right term for what it does. It's quite complicated, isn't it? Maybe it kind of surfaces information in a different way. This is one way of describing a framework. It takes observations about a running system and turns them into impacts. So that's one way. It takes observations about a running system and takes them into impacts. So I suppose one way it simplifies it is if you've got something you are already observing about your running application, like CPUtilization or something else. It can help you then turn that into energy. So that's one way it simplifies it. One other thing that, this is one of the misconceptions people have about Impact Framework when I talk to them about it, is they think it's something that you have to install on every one of your servers, right? Cause that's how most of the things that measure energy work.

They're like, okay, Impact Framework. So how do I install it on my GCP servers or my Azure servers? And I'm like, well, you don't, you just. You know, you just have to tell us what the utilization was of each of your machines and each of your processes and Impact Framework will try and convert that into energy.

So I think that's one way maybe you could say it simplifies it. You don't have to install anything at all? 

Srinivasan Rakhunathan: I think so.

And, uh, when you use the word 'simplify,' Asim, to me, the very fact it's a command line utility, it's a huge bonus, right? You don't have to spin up Kubernetes clusters. You don't have to spin up Spring Boot services. You know, you don't have to host it on an API. You don't need an infrastructure for all that, you know, you can

Asim Hussain: You don't need to instrument any of your applications or code or anything. It's just, yeah. It's just like observing. It's

just looking at it. Yeah. 

Srinivasan Rakhunathan: Exactly. so, so to me that simplification that you can just download the code, you need to know a little bit of Node.js or Yarn or how to use it to just be able to run it. As long as you're able to do that, you're pretty much up and ready. Maybe you, we can even set up a timer Asim how long it takes for someone to run it.

I bet it'll not be more than five minutes. You know,

Asim Hussain: I don't think so. I don't think so. To get the simple, like hello world version of it out with like, yes, sampled, maybe it's use it with your own data. It will take a little bit more time, but to like use it with a sample data, I think five minutes is absolutely yeah. Any thoughts, Navveen, or how, like anything you want to add to that?

Navveen Balani: So I would also say that it simplifies, I mean, if you're a beginner who wants to do software Carbon Emission Measurement, then, I mean, this API, I mean, the turnaround time for basically measuring, let's say, a virtual machine is, uh, maybe a few hours, right? Just going through the API, uh, setting things up. So the barrier to measurement, uh, I think is quite simplified. Given our history, right, where at least we took maybe a month or two months, right, just to go through the entire data capture process, which model to use, right? So all those knowledge, I would say, is accumulated in this tool, right? So the entry point to SCI now is drastically reduced.

Asim Hussain: I remember that being, I remember that was one of the, one of our original kind of design, I don't know if that's a term design decisions or requirements of the tool was to codify the expertise that was in like both of your heads and in the heads of other people, like the very small set of people who've been looking at this to make it easier, because now all you have to do is you just have to like plug in a utilization value, pick a model or a set of models, and it will like compute all that for you instead of like, "which coefficient should I use, which this, which that?" Is kind of all baked into these models. Talking of models, we call them plugins now, don't we? Sorry. We call them plugins now, which I'm having some name changes. So I remember I was chatting the other day.

We originally had this way of thinking, which is we know we need to capture some observations about our running system, be it utilization of virtual machines or billing data or whatever it is, some observations we have. And we always knew we were going to pass it through some sort of model to create some sort of impact, like energy or, or, or whatever. Then at some point we realized it's not, one model isn't going to work. We're going to have to break it out into lots of, and that was a very important decision that we made. I feel like that was like an inflection point. And there was a moment when we were like thinking about this thing in terms of one model rules them all, to hundreds of thousands of models that you can like combine in this kind of Linux piped command line process. I think that was a real breakthrough moment in the project. I think it was something about, were we trying to compare Boavizta, Cloud Carbon Footprint and Teads and these other models together?

Was that what it was? I can't remember what even triggered

Srinivasan Rakhunathan: I'm, I'm also trying to think.

Asim Hussain: Yeah, I think it was something to do with that because CCF did a lot. Oh, I can't remember. Anyway, what are some of, what are some of your favorite models? I was going to ask, like, what are some of your favorite plugins? Or, yeah, like pipeline plugins. I do remember the moment, actually, I think this is quite important, actually, as well, like, when what once we finally had this ability to grab some observations, put it in a YAML file and then pass it through a set. We know that's what we did. God, this is a memory lane. We standardize the interface to these models.

That's the first thing we did. And as soon as we standardize interface to models, we could then. Use the same data and pass it to different models. So we took the same utilization values, suddenly, suddenly, and I can't believe no one had ever really done this, ever. We took the same utilization values and we passed it through the Cloud Carbon Footprint model plugin that we created. We then took it to the Boavizta model plugin, and we then took it to the Teads, there was a Teads model plugin. And the numbers are so different.

I remember that was a real shock for all of us. And I won't go into details, but there was a, almost a 400 percent difference in the energy values from one to another.

Srinivasan Rakhunathan: I think the methodology differences between these datasets were so pronounced, like you talked about Boavizta, you talked about Cloud Carbon Footprint, that with the original concept that we had where we wanted to cover all, we would have had to build multiple flavors of the Impact Framework and there were cost issues in maintenance that would have caused issues in adoption.

I think the standardization of a model plugin was more a decision that we took once we realized that one model is not going to cut the cake for all of us. And You had different models depending on whether you are hosting it on AWS or Azure or GCP or your laptop or even your mobile devices. But if someone wants to just look at the raw emissions from the software, agnostic of the hardware, you could do that only if you have a very thin measurement tool.

Asim Hussain: Yeah. And for instance, also remember at the time I was still at Intel and we were building a model, a plugin for Impact Framework, which obviously would only measure Intel chips. So you had to have multiple models in a pipeline because if you had other vendors' chips, you would need that model in the pipeline as well to like calculate that model, you know, and the way I imagine the future is that vendors themselves would then be releasing their own models. Like my dream, Srini, is like Microsoft releases, I know it's doing the importer model, but then, you know, the future dream in the future is Microsoft releases models for every single one of its services. And if you're using that service, you plug in the Microsoft model for that service. You plug in whatever observation, like let's say it's gigabyte seconds for Azure Functions. You grab your Azure Function's gigabyte seconds, you've got the observations for there. How do you turn that into energy or carbon?

So ideally you just use the Microsoft Azure Functions plugin, plug

it in, and it knows how to convert gigabyte seconds for Azure Functions to whether, whatever it would be like energy probably, or maybe carbon.

I don't know how we'll end up there. So that'll be like, yeah, that'll be the future. My dream would be like, you come to Impact Framework and like, imagine you see like a page which is like hundreds of models and each of these models has like a logo of like some cloud service on it, you know, and you just drag and drop the cloud service that you're using. And then maybe you've even got some like automatic importer which imports the data from your cloud service into it. And boom, it's all working. It's all automatically calculating

Navveen Balani: It'll be probably like a GPT store.

Asim Hussain: A GPT. Yes. Oh yeah. The Impact Framework store where you go to, I could even imagine like, honestly, everything we've done is open source. Everything we're doing is publishing is open source. I'm fine if a commercial entity wants to come along and create a paid-for model, you know, "if you want to use this model, you need to sign a contract and pay us some money and, and use it" because honestly, maintaining a lot of this stuff is very challenging. Like get making these models is a lot of hard work. I'm okay with organizations, hint, hint out there if there's anybody listening, he wants to create a business on top of Impact Framework. It's, I think it's absolutely fine to, to create a plugin that is commercial creates, you know, let's say. I don't know what that would look like, but, you know, it pays money to, to do this properly.

Cause one of the things we're doing is like with one of our models is the Cloud Instance Metadata model. That model, given a cloud instance ID, tells you metadata about it, like the number of virtual CPUs, this, that, and the other. Because there is no good data set. There is no API, which you can go to for that.

So we need to maintain that as a GSF. And that takes time, effort. So if somebody out there wants to, you know, go do that, I think that's perfectly reasonable. Yeah. Why don't you each say what your favorite plugin is so far? I don't know if you have one. Navveen, what's your favorite plugin so far that we've built? I think I know what Srini's going to be. But, uh,

Navveen Balani: Let Srini go 

Asim Hussain: Yeah, Srini go to first. 

Navveen Balani: Let me

Asim Hussain: I'll Srini go first because it's a hard choice, isn't it. Srini, what's yours? If it's not the one I think it's going to be, I'm going to be surprised. Go on.

Srinivasan Rakhunathan: No, it's not the one you're thinking because it's not yet there. 

Asim Hussain: Oh, okay. 

Srinivasan Rakhunathan: Yeah, so I really like the TDP model. Yeah.

Asim Hussain: Like the Teads Curve one,

what we call Teads Curve? Yeah. 

Srinivasan Rakhunathan: Yes. Because that's something that was very manual earlier. I don't think any of the other assets have that capability to give that Teads curve. And for me, while the solution, the technical solution was

simpler, I think, but the concept of having a model in the first place was awesome. I think that's how, you know, keep things simple, that same, the logic that works, right? Because it solves, you can extend the TDP model for any hosting infrastructure. It doesn't have to be a laptop or anything. I can just open my power configuration on my laptop, find out what is the TDP score, and then do a multiplication. 

Asim Hussain: Oh, just plug it. Yeah.

Do you remember when, cause it's Benjamin Davies. We even brought him in to the standards working group one day, like years ago, just to talk through, cause he wrote, he did that. That's, it all started when he wrote that Medium post where they'd done that analysis and he'd like scanned through all of Amazon's bare metal servers, averaged every single server out to like, this is the generic power curve.

That's what we call the Teads curve. I don't know if that's the right term. We just call it the Teads curve, you know?

But like, that's the generic power curve. And then all you need is that data, plus what's called the TDP of a chip, and then without getting too wonky for our audience, then if you, then you can compute the, an estimate of energy for any single chip in the world. So open the door. I remember when that first came out, I was like, I felt like such a relief when Benjamin did that work. Cause prior to that, I was thinking, "Oh my God, we have to sit and figure out this data for every single chip in the entire world on every single device. How are we going to do this?"

And then he came along and went, "ah, I averaged it all out and it works pretty good." So we were like, "okay," and I see that used everywhere. So many places I see that used every, cause it's so easy. It kind of taught me a lesson actually, which is it was so stunningly easy. It was like one sentence could summarize that model. It's just everywhere. It's just absolutely everywhere. It's so simple to use. So yeah, that's a good one. That's the tease one. Yeah. Srini, Srini, you have one? Is it the SCI one? Maybe. No, Navveen.

Sorry. 

Navveen Balani: Probably I'd like to have some AI model. Currently, we don't have one. So probably I'll wait for the hackathon to provide, right? Hopefully, as part of the hackathon, we'll get a lot of good models to evaluate.

Asim Hussain: What would be a good like AI model? Because like. Would it be something that kind of like, looks at it, like, what would the observations, is it prompts? It'd be like, what would be the observation prompts?

Navveen Balani: it'll be, yeah, it'll be an interesting model, I would say, based on the deployment. Uh, for instances, just to give an example, let's say if somebody is using an OpenAPI directly, right? They're just interacting with prompts. So in that case, how do you evaluate the carbon emission given just the prompts, right?

And a lot of these observability data may not be available from OpenAPI. But let's say if you're doing fine tuning or if you're doing your own model, then you will have access to infrastructure, and then you probably can use our existing models. So I would say the first one would be quite interesting where you don't have much information available from vendors.

So how do you come up with emission, right? Just maybe, just based on traction and prompts. Maybe it is prompts, length, latency. Let's see how the community as part of the Hackathon picks up this challenge.

Asim Hussain: I think, like, when I think of the future, like, it's interesting how our world's changed because we used to talk about AI emissions in terms of the training and, like, how long it

takes to train and we used to talk about inference in this very abstract way. And I'll be honest with you in the last six months, everybody just talks about prompts.

Like the word prompt is, and I use, I'll be honest, I use AI co pilots and all this other stuff all the time. And it's like, it's all about prompts, isn't it? I do think, Navveen, I think the future is going to be prompts. Like how many prompts have you made that generate images? Like an image prompt is probably going to be different. You probably have like a coefficient for an image prompt, code prompt, an LLM prompt, something like that. At least in terms of the way humans are working with AI these days. I think prompts is like the key. Yeah. And when you see like articles and stuff out there, it's always like, "Oh, on average prompts cause this impact" that I think I see the language being used that way. So, yeah.

Navveen Balani: I think that probably brings up to, I think, one of the challenges that we still need to solve around managed services, right? A lot of these, if you treat also OpenAPI, right, servicing offer as a managed service, now how do you calculate the carbon emissions? For instance, serverless is a very good example. So you have to use some kind of approximation, right? Because based on time or resources So expect similar models once we get more data and clarity, right? Yeah, we'll reach there.

Asim Hussain: Yeah. I think that's a really interesting, yeah. Maybe we'll get you, let's propose something in the, so there's a Carbon Hack coming up, a Hackathon coming up in a, in a couple of months around Impact Framework. I was going to mention at the end, let's talk right now, actually. 'Cause that actually, 'cause obviously there's going to be prizes for the best kind of models and plugins that we're describing right now.

And, and then Navveen, just as we're talking right now, I think I would love to see, as you say, like some submissions, and we can post in the ideas forum on the hackathon website, like. I'd love to see, you know, turn prompts into emissions. 

That might be a right, that actually is turning into like a bit of a working session on Impact Framework that actually might be a good way for us to influence direction of what people are building in the hackathon is what we just described is like, "what are the observations that we want people to try and figure out the impacts for?" So I want to help figure out the impacts of prompts.

We talked about serverless, serverless, the observation for serverless is something called gigabyte seconds. Help me convert gigabyte seconds to energy. Like I can, I've got some ideas for that. Like, yeah, that's how we should think about this. We should be thinking about, we should be saying like, these are the observations that would be the most useful for us to create models, to turn those observations into impacts. So I don't know, I don't know what other observations that we have. Like billing data is obviously oftentimes a fallback.

Srinivasan Rakhunathan: GPU utilization is also there, I think.

Asim Hussain: Yeah. GPU utilization. Yeah. Or like, what about a non-cloud? Well, here's an observation. Yeah. Gigabytes transferred. Yeah. Write a model to turn gigabytes transferred into.

Srinivasan Rakhunathan: Emission.

Asim Hussain: What other observations are there, like from the web space, your observation might be page views. There's already models that do that, like page views.

Maybe this, oh, I think we've hit on something just now. I've been struggling to try and like, how do we encourage, how do we direct people? But I think this is how we direct people, which is: These are observations that we want to be able to model, submit, think it through. And we can, we can submit, but yeah, there's lots of others.

It's just late in the day. So just final question. So let's talk about this. Like, you know, we've been just building the alpha and beta version of this. And you know, there are some people using it right now, but let's just talk it through amongst ourselves, like in practical terms, how would you see, you know, a software developer, a practitioner or a company just start using the Impact Framework?

Like how would you. Imagine if you were talking to a company, what would the very first steps? What would you, what would the conversation be? Like, I'll tell you what I've been thinking about this stage. 'Cause I've really loved the idea of this term that Joseph used, which is like executable audit, maybe it's an audit. Maybe it's a, "bring me in, like what software do you want me to audit? Oh, you want me to audit your XYZ software. Okay. Give me your data. Give me your observations. I'm going to write a YAML file. I'm going to write a manifest file. And at the end, here's a file which gives you. All the emissions of this software over the last month," something like that.

Is that how you would start off or, or are you seeing the conversations go different ways? Srini, I'm seeing you like, I think you think differently. I'm just starting to suspect your mind looks looking, your face is looking.

Srinivasan Rakhunathan: No, I think, see. One scenario we've already seen, Asim, right, is many people are talking about region shifting and time shifting. So if you're running a workload based on the carbon intensity of the underlying region of data center or whatever, electricity grid, people are talking about, and I think many cloud providers have implemented it even to shift their workloads behind the scenes without.

With or without your consent to a different region which is more greener. Now, if people have accepted that as a new normal, then why are we waiting till the operational aspects of the software? Why can't we look at the development cycle, left shift the entire process, give the tool to, there are projects which have 80 developers, 100 developers, 120 developers.

Today, nobody has any idea of how many dev environments, prod environments, pre-prod environments. I think, unless you show people numbers and show people how to measure them, the real impact of what is translating into carbon emissions doesn't even come through. So I think a lot of value is there when it's a practical, when you talk to companies who are in this cloud migration initiatives or huge initiatives, multi year, multi semester initiatives, there is a lot of value in even calculating it at a development level.

Why do we even wait for the operational aspects of, you know, calculating emissions? So I think that is a USP for sure.

Asim Hussain: So I think you mentioned two things that were interesting. One was like. I think you were alluding to this whole idea of once you've got this kind of like Impact Framework manifest file, you can do this kind of what if scenarios that you're alluding to that, right?

So once you've got that manifest file, when you were saying shifting left, were you talking about once you got that audit effectively, once you walk in and you audit your application, and like, "here's my inventory," passing that to the developers and the team going, "by the way, this is everything that you're running. You can run some scenario, don't build CarbonAware computing, just add the CarbonAware scenario model to the end of the pipeline to simulate what it would look like if the CarbonAware was," it kind of gets that kind of, yeah, helps, it almost helps like model, like what if scenarios in, in that environment. And the other thing you were talking about, it was almost like, yeah, you mentioned cloud migration. In my experience, cloud migration is this kind of like, no matter what you do, it's just this messy thing. It's very confusing. You start off with like a very clear idea, a very clear plan. It's very messy and you're not really sure what's going on.

And by the end, you're very clear again, cause you're in the cloud and you've got some good metrics. I remember there was one organization that was reaching us out to the start. And they were like, we're moving to the cloud. And we wanted to measure using Impact Framework on premise. And then consistently measure as we slowly migrate our replication to the cloud. And that way, the audit from Impact Framework should then change slowly over time. Because theoretically, like the cloud is more environmentally better. Then that would have given them that clarity in that migration process. Which we were too late. They did the migration before we, we completed in where we are right now.

But anyway, that was an interesting thought. Navveen, I think because you work in the consulting scene, you actually speak to a lot more customers and clients than us. Like, I don't know, like, what do you have, do you have conversations? Like, how do you have conversations to them about the Impact Framework?

Navveen Balani: So to extend to the simulation example, right, I think a lot of cloud vendors provide calculators, right, to calculate, let's say, the cost based on virtual machines, the entire infrastructure, right? So if you could put the element of carbon and emission also, right, because they know how the infrastructure is set up. And now they can do a simulation based on both cost as well as the carbon emission and also do simulations that reducing carbon also reduces your cost, right? So a lot of, I think enterprise wants to do a lot of FinOps activity, maintain the cost also, right? Sustainability of this tool, right, can be good uh, outcome to reduce their cost also. That can be also a value proportion to lower, I mean, lower the carbon footprint as well as the lower, the total cost of ownership.

Asim Hussain: There is nothing, I would say, stopping anybody using impact for any, like cost as an impact. There's nothing stopping anybody using it just to look at cost and then scenario cost reductions as well. So, okay, I think we're running out of time now today. So let me just maybe just close out statement. I also want to give it a bit of a call out to the Carbon Hack. So thank you both again for like, I know we chat every week, but thank you both for having another chat here. I think it's been such an exciting journey that we've been on. So that's just about it for our deep dive into the Impact Framework. Before we head off, I just have a quick announcement about CarbonHack24. CarbonHack is a global contest for developers who want to make a difference in the fight against climate change. It challenges participants to use the Impact Framework, which we've just been speaking about in depth. The theme of CarbonHack this year is measurement. We want to see how you can use Impact Framework to measure the carbon emissions. You know, other, we're also talking beyond carbon this year. So we have a prize of, you know, water, carbon, other things like that. If you could help us to write plugins for Impact Framework, which help us measure beyond carbon. We would love it. That's really where we want to move the conversation. We have kind of basically three prize categories.

One is the best plugin, which is like what we've just been describing, which is like something that can take an observation and turn it into something else is a plugin beyond carbon is a price for us for a type of plugin, which can take an observation and turn it into like a water or a. Or another beyond carbon type of type of measurement.

And we also have a prize for best content. So if you can help us to explain Impact Framework better than we're explaining it ourselves, there's actually a prize for that. That's like a non technical prize, whether it's a video or a tutorial or anything like that. We also have an undergraduates prize. So if your entire team is made up of undergraduates who are university, there's a special prize for you in addition to the prizes. And we've also now got to confirm, I don't know if I told you, but we've now got to confirm that we can have an under 18s prize. So if your entire team is made up of under 18s, there is again, an additional prize just for you on top of everything else. So I'm very excited about that. So CarbonHack is online.

It's starting on the 18th of March and ends on the 8th of April. You're going to compete to showcase your best application in the prize categories I've just spoken about. The hackathon is open to all, but you must register to be part of it. Registration begins on January 22nd. 

Please head to hack.greensoftware.foundation. It's a pre-register. And once you're there, then we'll send you further emails about how to get, how to get more involved. So please go hack.greensoftware.foundation, register now. It's all in the show notes. So we've come to the end of our podcasts. All is left for me to say, thank you so much to Navveen and Srini.

That was really great. Thank you for your contribution. And we really appreciate you coming to Environment Variables.

Navveen Balani: Yeah. Thank you everyone. Looking forward to the Hackathon.

Srinivasan Rakhunathan: Thanks. Thanks for the opportunity and looking forward to meeting you guys in future as well.

Asim Hussain: Awesome. That's all for this episode of Environment Variables. All the resources for this episode are in the show description below. And you can visit podcast. greensoftware. foundation to listen to more episodes of Environment Variables. See you all in the next episode. Bye for now. 

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.