Cloud Footprints with CCF

Environment Variables

Host Chris Adams is joined by Arik Smith and Cameron Cash from Thoughtworks in this episode of Environment Variables. Together they discuss the Cloud Carbon Footprint (CCF) tool and the role it plays in sustainable software development. Join this conversation as they nerd out together about the future of measuring carbon in the cloud, open source collaboration, and some cool posters in the background.

Learn more about our people:

• Chris Adams: LinkedIn | GitHub | Website
• Arik Smith: LinkedIn
• Cameron Casher: LinkedIn

Find out more about the GSF:

• The Green Software Foundation Website
• Sign up to the Green Software Foundation Newsletter

News:

• Responsible Technology Playbook: Tools for the United Nations | Thoughtworks [06:40]
• GCS23: Cameron Casher on Responsible Tech & Cloud Carbon Footprint [07:05]
• Cloud Carbon Footprint [09:25]
• Etsy Engineering | Cloud Jewels: Estimating kWh in the Cloud [12:41]
• 20231124 - green coding summit - ai environmental impacts assessment workshop [26:19]
• 20231124 - green coding summit - infra/cloud environmental impacts assessment workshop [26:52]

Resources:

• Arik’s awesomely distracting looking poster [02:36]
• Notes from the SDIA Green Coding summit [07:05]
• (GreenOps) A forecast of green clouds | Thoughtworks [08:18]
• Green Software Patterns [08:24]
• Electricity Maps API Documentation [28:36]
• Software Carbon Intensity (SCI) Specification Project | GSF [32:38]
• GitHub - cloud-carbon-footprint/cloud-carbon-footprint [38:04]

If you enjoyed this episode then please either:

• Follow, rate, and review on Apple Podcasts
• Follow and rate on Spotify
• Watch our videos on The Green Software Foundation YouTube Channel!
• Connect with us on Twitter, Github and LinkedIn!

TRANSCRIPT BELOW:
Arik Smith: [00:00:00] At the end of the day, CCF is a community supported and collaborative tool, and I think that's the biggest and strongest part of all is that this isn't a methodology that one organization has owned or came up with, but that the, I want to say the entire industry who really cares about this subject has contributed and promoted growth within.

Chris Adams: 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, Chris Adams. Hello, and welcome to another episode of Environment Variables, where we bring you the latest news and updates from the world of sustainable software [00:01:00] development. I'm your host, Chris Adams. In our first episode of Environment Variables, we spoke about the team working on Cloud Carbon Footprint, about the subject of carbon calculation in the cloud. And a lot has happened since that episode. We've basically seen a spawn of imitators, and we've seen a launch of a number of native new platforms that various cloud providers use to help people understand the environmental impact of using digital services. Cloud Carbon Footprint has remained the open source reference, and as we'll discuss in more detail, parts of it end up making it into all kinds of other services these days. So it's been a while since we spoke about Cloud Carbon Footprint, or even Carbon Calculation in total. So joining me today are two of the main maintainers of the project to dive into some of the weeds on this. All right, today I'm joined by Cam and Arik. Folks, I'll just give you the space [00:02:00] to introduce yourselves.

Cam, if I give you the floor, then Arik, I guess you can introduce yourself after that.

Cameron Casher: Thanks, Chris. Really happy to be here. I'm Cameron Kasher. I work at ThoughtWorks on software, data, sustainability, general responsible tech, and really happy to talk to you today about Cloud Carbon Footprint.

Chris Adams: Cool, thank you. And Arik?

Arik Smith: Hey, I'm Arik Smith. I also work as a developer consultant at ThoughtWorks, mainly as a cloud SME and a green software specialist. But I am also excited to be here, so thanks for having me.

Chris Adams: You're very welcome. I'm excited here, but I'm also quite excited by that awesome looking poster that I can see inside the video. I'm afraid that you can't see it in the audio, but there looks like there's a Japanese poster behind you. Is that Zelda or something? Arik, can you please tell me what that is, because it's totally distracting, but it looks really awesome.

Arik Smith: Yeah, for sure. So behind me I have my home office, which is basically in my basement that I call my culture cave. So what [00:03:00] you're looking at is what I call my wall of culture, where I just hang up artwork that I usually find at local vendors around town, mainly around my favorite video games and movies.

So yeah, the poster is a poster with Link on it and in Japanese katakana, it says Zelda, but there's also some other stuff on there. I have an Avatar poster right next to it for The Last Airbender, and a Final Fantasy VII, and an Arcane League of Legends poster. Lots of fun stuff going on.

Chris Adams: Wow that's an impressive nerd cave, and I think anyone who's been following Zelda this year will probably be excited about a reference to Tears of the Kingdom, amongst other things. All right, and Cam, we met in person, actually, about a month ago, when you came over to Berlin for the Green Coding Summit, and I A, I realized you were so much taller than me, oh my god, but also I didn't realize whereabouts that you were coming from.

So you were coming from Colorado before, and at the time of recording, this is the 21st of December, so there's a bunch [00:04:00] of really explosive political news that might impact what will happen with elections next year. But, as much as I do want to talk about that, and what the climate implications of having different leadership in America might be, I think I should ask you about one thing you told me about, skiing in Colorado. That's a thing that you do on a regular, right?

Cameron Casher: Yeah, it was great to see you in the flesh in Berlin. It was really awesome to be there. And yes, Colorado has found itself at the forefront of U. S. politics at the moment. So, that's exciting. And, yeah, we're in uh, ski season here. I'm excited to get out and snowboard a bit. But still waiting on some of the good snow to hit some of the Colorado ski resorts, but I'll be trying to get some days in this winter for sure.

Chris Adams: Nice. Okay, cool. I'm calling from Berlin, and if you haven't heard this podcast before, I should probably introduce myself as well. My name is Chris Adams. I work as the executive director of the [00:05:00] Green Web Foundation, a small Dutch non profit focusing on reaching an entirely fossil free internet by 2030. But I'm also one of the chairs of the Green Software Foundation's policy working group, where we do work with standards bodies and other organizations working in this field of sustainable software and general sustainability. All right, I think with that in place, I should ask you folks, are you sitting comfortably?

Looks like you are. Okay, then I guess I'll begin. Okay, Cameron, I'll ask you about this because you were talking about this notion of responsible tech when you came over in Berlin, and then maybe that will use that as a way to talk about some of the projects that you've been working on. Maybe we could just open with what this notion of the Responsible Tech Playbook that you're presenting, because that looks like it provides a bit of context and that helps understand where tools and carbon calculation might actually fit into the context of using technology in a more responsible basis.

If you could start there, maybe.

Cameron Casher: Yeah, [00:06:00] definitely. I know you'll probably hint to this, but we can definitely link to these resources in the podcast description. But

Chris Adams: Yeah, absolutely. Thank you for reminding me. If you hear any projects mentioned or anything like that, and if we don't put it in the show notes, please do let us know, because we realize that people who listen to this podcast often use every single project as a jump off board for their own research. So we will do everything we can to make sure this is useful for other people who are taking their first steps or trying to explore this new field. All right, Cameron, yes, you were saying we were, you were

presenting about this, yeah.

Cameron Casher: So ThoughtWorks has done some really cool stuff in the area of responsible tech. We had a playbook that came out a couple years ago. And really cool thing recently is we got in touch with some folks at the United Nations and they were very interested in our Responsible Tech Playbook. So we were able to do some really cool work partnering with them to create a more customized [00:07:00] version of it. They're very large around the world and they have a lot of people doing a lot of great stuff. So incorporating responsible tech principles and practices was very important to them and doing it in a more customizable way. So that's what I talked about in Berlin a bit at the Green Code Summit about what the playbook was.

So maybe it's worth just defining what we consider responsible tech.

Chris Adams: Yeah, go for it.

Cameron Casher: We consider responsible tech as the active consideration of values, unintended consequences, and negative impacts of technology. A lot of times these tend to go overlooked. It's not always necessarily a negative intention when developing technology, but really it's, the idea is to manage and mitigate potential risk and to be inclusive to all communities.

There are a lot of different topics we cover in the playbook, including data and AI. Accessibility is a big one, but what I really focused on in [00:08:00] Honestly, because a bit of my background was sustainability, so I was able to shift the focus at the conference talking about it, but also help get a really cool chapter in the playbook around sustainability and how we could incorporate the idea of GreenOps and incorporating Cloud Carbon Footprint.

Chris Adams: Okay, and GreenOps in this scenario is essentially what DevOps is to developing. GreenOps is to this same idea, like it's essentially operationalizing some of the kind of aspects of green software. Is that the idea behind it?

Cameron Casher: Yeah, and another ops really, there's a ton of ops these days, but the idea is tying it really close to DevOps or FinOps too, from a more financial standpoint, really considering green software, carbon emissions, carbon footprint within your development process.

Chris Adams: Ah, okay, so that makes sense. And now I understand the link between there and Cloud Carbon Footprint in its own right, which basically ends up essentially using some of the [00:09:00] usage data that gets produced as a byproduct of operating various digital services and then providing that in a way that you can act upon, or do something, or, or, you shouldn't.

Arik, I see you nodding, so I suspect maybe I should actually give some space for you here. Maybe you can introduce Cloud Carbon Footprint to people who have never heard of this, and why someone who is a software engineer who is curious about environmental sustainability in this context might care about it or want to know about it.

Arik Smith: Yeah, absolutely. Cloud Carbon Footprint is an open source tool for tracking your energy usage and carbon emissions across All the major cloud providers, AWS, Google Cloud, and Azure. And, which we can talk about later, we've also added, or begun to add support for Alibaba Cloud as well. It's a great tool, it serves as an unopinionated monorepository of multiple toolkits for you to go about grabbing your estimates.

So we have a CLI, uh, or a command line interface you can interact with, uh, we have an [00:10:00] API that you can integrate into existing workloads or directly carry, as well as an out of the box dashboard for visualizing and tracking your emissions over time. Um, and we present this at a daily granularity, sometimes even hourly.

Because what we do is we query your usage from your billing data. So think about AWS, Athena, costing usage reports, exports, or your Google Cloud, BigQuery, billing data exports, or your Azure cost details API or exports. We take all of that in the granular usage data that they use and convert that into energy where we can then convert that into carbon emissions to display.

Chris Adams: Ah, cool, okay, so anything that can basically expose billing data or usage data can then basically provide a single view across maybe in a state or a different set of services. So rather than having 3 or 4 competing and possibly incompatible calculators, you have one [00:11:00] consistent way of looking at this stuff, right?

Arik Smith: Absolutely, yep, you'll have one unified methodology to be able to view your usage across multiple cloud providers all within a single dashboard or a single place, which is great just to get a holistic view of where you stand and comparing apples to apples in that way.

Chris Adams: Gotcha. All right, okay. Now, I know that I've been somewhat familiar with Cloud Carbon Footprint and there's a bit of a backstory behind how it came about, because I think there was actually a few years ago there was some really like pioneering work from some folks at Etsy who started on some of this. I'll leave that open for either of you to actually talk a bit about that, because I think there's a really interesting story about how some of this work done in the open there ends up turning into a tool which ends up feeling a little bit like, you know, that XKCD cartoon where there's that one piece of project that everything gets built on? That's how I see a bunch of this. And maybe I, maybe I'll let one of you folks explain some of the origins of this and how that end up, how some of that led to [00:12:00] CCF, or Cloud Carbon Footprint, being like an open source project with a number of users.

Arik Smith: Yeah, absolutely. So within ThoughtWorks itself, there was a lot of growing interest within climate action and getting a hold of our own infrastructure and where our footprint stands with that, especially within our cloud resources. And what we found was that there was not really a tool to do so at the time.

So this was about, and Cam, feel free to correct me on timing, but I believe about 2020, where the bulk of this work was done. And being ThoughtWorkers, we typically decided to look into ways we could perhaps create a way for ourselves to measure our own cloud usage. And we came across Etsy's awesome Cloud Jewels methodology and saw the way that they were estimating compute resources within the cloud, and it served as a great basis and foundation for us to build and find out how can we do that for Google Cloud and AWS and Azure, all the [00:13:00] different cloud providers that we have some level of usage within.

So we started building out a proof of concept to estimate our own internal usage and eventually we made the decision that due to the absence of any tooling out there that this is something everyone should have because we want to empower all organizations and all users to be able to have this level of transparency with their cloud usage because the compute resources and overall energy usage of the IT industry in general is a big major part of our global footprint, especially in major large tech companies and large scale product companies.

We went open source back in March 2021, and since then we've been iterating on it ever since until the cloud providers came out with their own native tools, which is great, and we saw more and more tools and interests popping up in this space.

Chris Adams: okay. That's cool. So basically there's this OG climate calculation stuff, uh, from Etsy, and then that big, that served as some of the basis for a more polished [00:14:00] tool that could be used in lots of different contexts, rather than just the ones that Etsy used, because I think back then, Etsy had a bunch of on-prem stuff and a bunch of Google Cloud, so that was where some of it looked like, but when CCF became, I think the first version that I saw, actually had support for both AWS and a bit of Google Cloud, and now it's actually got support for, like you said, all the big ones, plus Alibaba, I didn't know about Alibaba, actually.

it.

Arik Smith: Yeah, Alibaba is limited to compute resources for now, but we're still looking into ways to expand that. Um, similar to how we did Um, at the beginning with Etsy, they were estimating cloud, um, compute resources. And then we started thinking about how can we expand that to memory and to networking. And all of that has been a collaborative effort, which is why we call out Etsy within our methodology as the basis from where we started from.

Like even just the networking estimations. We work with Benjamin Davey from Teads based on a write up he did for estimating network as well as embodied admissions and iterated within the other [00:15:00] usage levels within the same way.

Chris Adams: Ah, cool. I think I remember, actually, there's a bit of work by David Mitton there, when he did some work around the CPU coefficient stuff as well. I realize I'm diving into, like, loads of really nerdy stuff, uh Cam, I see you nodding, so maybe I'll let you just touch on some of that stuff, because I think it might be worth talking a little bit about where else this turns up, because we've seen a number of calculators kind of launch now.

A lot of them either reference CCF, or have started using that as a basis. But before, though, I'm getting ahead of myself, yeah. Maybe I'll give the space for you, Cameron, because I saw you getting a bit excited there when we were talking about some of that.

Cameron Casher: Yeah, what's funny is the opportunity to speak here today with you gave us, gave Arik and I a chance to be a little retrospective about our time with CCF and think about lessons learned and what's gone on, what's been challenging. And yeah, even just hearing Arik talk about our partnerships and collaboration, I think it's just worth saying that's been a really cool aspect of being an open source maintainer. [00:16:00] Just being able to openly work with the community, being able to have really awesome discussions with industry experts like David Mitton or Benjamin Davey or everyone at Etsy to just continually evolve the methodology for CCF and make it better, make it fit users, and getting into some of the challenges, I don't know if it's necessarily a challenge, but it's just a tough point is that. We don't have the best transparency into who's using the tool, and I think that's a pretty common trend for open source software, but a lot of it is just through word of mouth, or even when I was in Berlin and talked about it, I got the chance to meet a lot of people that approached me and let me know that they were using CCF, which is, it's really cool to hear about that and the impact that it's had.

Chris Adams: Oh, thanks, Cam. So you mentioned David, uh, David Mitton, and, uh, and I realize there's a couple of other people who are also involved in this as well. I mean, well, the original person on the podcast was, uh, [00:17:00] uh, Danielle, uh, oh, Cameron, I need you to help me with her surname. What was Danielle's surname again?

Because she was

the original product manager on this.

Cameron Casher: Danielle Erickson, and she was, yeah, one of the first guests, and she was a very integral role with the open source launch and continued feature development for CCF as our project manager. So, um, yeah, Danielle had a serious role. And also Lisa McNally, who is the, also on the policy working group with you, um, she helped spearhead a lot of our development too.

And I'd be remiss if I didn't mention Marco Valtas, who had a significant role on the dev team as well.

Chris Adams: Oh, cool. I'm really glad you mentioned that, actually. And, uh, actually going back, Jesus, in a few years back now, oh, uh, was, uh, I believe Chelsea, Chelsea, I think it's Chelsea Mozen. She was one of the people who was organizing Climate Action Tech back in 2019 2020, and, uh, I learned so much from her, and she was one of the people really pushing the stuff at Etsy as well.

So, it's, I'm really glad [00:18:00] you spoke about some of the other people, because there's a whole lineage of people who've been contributing to this now over the years.

Cameron Casher: And so many people are coming to mind and, you know, even Dan Lewis-Toakley, who's been a part of the Green Software Foundation, really spearheaded the open source launch too, in the early days. So important to include him as well.

Chris Adams: Yeah, happy days.

Cameron Casher: So I think we're just trying to look for ways to have a better understanding of who's using it.

We have an adopters markdown file in our GitHub repo. We're still trying to get the word out that we want to know what your story is and what your experience has been with CCF. And we have a blog that we just put on the microsite and we're very open to just sharing stories and experiences to providing help for anyone new who wants to try and get it set up at their organization or just for their own personal use.

Chris Adams: I can definitely speak to this because, uh, we maintain, where I work, we maintain a library called CO2.js, which we know is used in a few places, like, uh, we [00:19:00] spoke to Mozilla, and it's in their browser, which is cool, and we work with some other people where we collaborated, but then sometimes it turns up in totally random places.

So, like, I did a talk, um, in Hungary, uh, and I was invited to speak at this event, and then when it was launched, I found out that it was actually used inside one of the key projects that people were actually launching on the day. I was like, "oh! Wow, that's cool and unexpected, but nice to know," right? And I feel that seems to be some of the cases when I see with CCF, because I know that, um, there's a tool called GreenPixie, which is a quite well developed, quite sophisticated commercial product that initially had some origins with CCF, where they use some of that.

I understand, I believe, I think VMware uses some parts of it, as well as IBM. So it turns up in all these interesting places that I didn't, that I hadn't thought about. And when I actually was at the same event as you. I didn't realize the footprint it had in the financial services industry. And that was the thing that really blew my mind, actually, and this, it's, I guess it kind of does [00:20:00] make sense, really, because if you don't have access to information here, having an open methodology is quite useful, and we, at that event, we saw at least one person from a well known bank, ABN AMRO, this is like one of the third largest banks in the Netherlands, they basically said, we're a regulated organization, we, when we calculated our emissions, it's like 40 percent of our carbon footprint comes from our use of digital services.

So we want to have an open tool that doesn't have us rely on a single thing and lets us be transparent with both our regulators, but also our sustainability teams. And this was actually mind blowing that you'd actually have companies talking about this because for the longest time, people tend to either don't say too much about what the environmental impact of digital services might be in their organization, or they say it's very low.

So to have organizations say, yeah, we're using it, this is what we use as our basis, and this is how we calculate it, was mind blowing. It was really useful to see that actually because Like you said, it's really hard to see, and it would be so nice to know that it's [00:21:00] reassuring to find people using your projects, but sometimes it's so hard, you do ask yourself, like, could we have found out another, did I have to really fly across the Atlantic to find out that people are using this tool?

Cameron Casher: Yeah. Yeah. And I'll just add, I think we might touch on this a bit too, but our roadmap, how we decide what we want to continue to build and look into is really community driven. So it's really helpful to understand how people are using CCF to help us understand what to fix or implement. Yeah, it's just very important, really.

Chris Adams: So maybe we can talk a little bit about that then, because we spoke about roadmaps, and like I saw you nodding along when you were thinking about some of the things that are on this list, and I realize that you've been implementing some of this. Are there any kind of, like, exciting things that you're looking forward to seeing the light of day, or being able to work on, that you're really thinking, "Ah, I cannot wait for this to be visible," for example?

Arik Smith: Yeah, absolutely. So we have a few things in the works that I think are [00:22:00] exciting. One of the big things is a lot of improvements we've been trying to do this year is to our overall implementation of Azure, as well as just performance and scalability, which has been one of the biggest lessons learned during the time that we've been developing CCF.

Because ThoughtWorks itself isn't a product company, so we don't have a lot of internal cloud usage. So really learning and leveraging partners and collaborators and sometimes even clients to figure out what type of issues or what type of considerations that enterprise level product companies will have when using CCF has been really helpful and what we've been really leaning into.

And even just Azure as well, because Azure has a Different implementation where it's more API based instead of SQL based like your Google Cloud BigQuery or your AWS Athena, which we interact with for usage. So we currently have a migration going on to migrate to some of the new ways that Azure has made available to [00:23:00] grab billing data.

And one of that is through their new Cost Details API, which we were previously using their Consumption Management API. And then as well as the ability to export cost into an Azure blob and be able to parse a large amount of data from that. So that's currently in the works and we can't, we think this will help a lot of large scale Azure users, which unfortunately due to the differences in implementation.

tends to lag a little bit behind in some of the ways we deal with the other cloud providers. But also, even beyond that, we've seen a lot of interest in Trying to get a grasp of usage and cost for Kubernetes workloads and clusters. And we have a really cool partnership coming up in ways we are looking into collaborating with OpenCost, another open source tool for diving into Kubernetes spend and finding ways to use CCF as a basis to showcase energy [00:24:00] usage and carbon emissions alongside the data that they show within the tool.

We've done a similar collaboration in the past with Backstage, making CCF a plugin for their platform. And that is also another cool opportunity coming up because people use open costs and we're trying to really leverage the ways that CCF is flexible and extensible to where you can still use CCF's methodology as we've seen

in some of the other tools we mentioned, but also in your existing toolkit, and that's why we keep referring to it as a tool and not just a product, because it's really just a means to an end to be able to get transparency into your cloud usage and carbon footprint. I think those are two of the biggest things.

Oh, and we also have Boavizta, but I may actually toss that to Cam because that's something he's been a little bit closer

to to talk about.

Chris Adams: Alright, Cam, before we go into that, I just want to, I realise that we didn't actually speak about this now, um, CCF [00:25:00] is a open source product, um, it's presumably written, is it TypeScript or JavaScript? Maybe we could just touch on that briefly because I realize that we didn't actually talk about any of that, uh, and it might be useful for people who are curious about taking their first steps, right?

Arik Smith: Yeah, for sure. Yeah, CCF is an open source monorepository, all written in TypeScript. And that was a deliberate decision because we wanted to have a single language used across the entire codebase to make contributions and onboarding to the project easier. So if you're looking for an open source project to contribute to, we welcome it.

Even if you just want to read the methodology and provide feedback, we welcome that as well. But yeah, so the dashboard itself mainly leverages React. It has a simple React dashboard for visualizing your data with the API being in Express and the rest being in native TypeScript. Tried to keep it simple, but,

Chris Adams: so it's stuff that people are likely to be, to use, it's not something like written in Sorry [00:26:00] Haskell Friends, like Haskell, or something which is not that popular. Okay, cool.

All right, Cam, yeah. Cam, you were about to talk about some of the other things on the roadmap that you, uh, touched on. I think, maybe it might be worth just briefly explaining what Boavizta is, because if people haven't heard of Boavizta, they might not know about the cool French guys and, uh, women working in that particular project.

Cameron Casher: Yeah, Boavizta actually had a really cool workshop at the summit that we were at in Berlin. And they were explaining some of the ways that you can go about measuring the energy from some of your server usage, which is some really cool work and props to those guys who did an excellent job there. Because I think there was a really good collaboration in that workshop and it was pretty well received and spawned a lot of great conversation.

Chris Adams: I agree with you on that. I remember, so the, so the thing with, the interesting about Boavizta is like, we'll share a link to the workshop, because one thing that was nice is they did this, Boavizta led one of these workshops about understanding [00:27:00] the both embodied energy and the usage energy in cloud, but they did another one about AI as well, but they were gracious enough to share the entire decks and everything online as well, so we'll add some links to that.

So we've established Boavizta, that was one thing, but you mentioned there's some other products or other kind of integrations that are on the roadmap that you might be talking about, possibly also with French speaking people involved, I suppose.

Cameron Casher: Yeah. So I guess for context, we, with our methodology, we've had to rely on a lot of other public and open datasets since a lot of the information around carbon or energy estimations, we haven't been able to grab directly from the major cloud providers, at least just yet, we are really reliant on some of the open data sets we find.

And with that comes a lot of manual updating and monitoring to make sure we're aware of when some of these data sets get published with new information, this really led us to the idea of wanting to [00:28:00] more automate the way that people could get some of this data, whether it's energy estimations for servers or even carbon intensity values. What I really wanted to try and do lately is almost integrate feature toggles. You can always default to some of this average data from the publicly available sources, but if you have a Boavizta subscription or however you'd connect, then maybe you could select that as your way to get some server information from some of your, let's say AWS vCPUs. Or another thing that we wanted to express was our partnership with Electricity Maps. This is another company over in Europe that's doing a really great job around understanding real time carbon intensity values from regions globally around the world. This is really nice for CCF because you can really get more accurate carbon [00:29:00] intensity data, which is a integral part of our estimation for carbon emissions in our methodology. And some of the work we were able to do lately was map the Electricity Map zones to cloud provider regions. So you're able to directly connect. If you have a subscription to Electricity Maps, you essentially just pick a box and say you want to use this and get to see some of their data and map it to some of the daily values that you'll see from your cost and usage report.

Chris Adams: Ah, I see. Okay, so if I, to make that a little bit more concrete, when you often have, say, some values which might be, so people often talk about the idea that you can maybe change a region to reduce the environmental impact. Let's say you're using AWS, and on one part of the United States, on the Eastern Seaboard, New Virginia, not Eastern Seaboard, but North Virginia, yeah, that's going to be using a bunch of coal, and you, but on the other side, you might have, say, in Oregon, it's going to be a very [00:30:00] kind of like cleaner grid by comparison, but there may be other places which might fluctuate at various times and that will capture some of those changes specifically that an Electricity Map would give you, right?

If there's maybe times of day where it's particularly sunny and windy, you'd have green energy there and it would actually reflect that in the billing, for example, or show it in your stats in a given day or hour, right?

Cameron Casher: Right. And the really cool thing about their API is that we are able to grab historic data. And a lot of people using CCF are wanting to see what their usage looks like for the past year or two. So we're able to actually map on those given days of their usage, backtrack and backfill. And yeah, they also offer hourly estimations too.

That's something we're looking forward to potentially implementing for CCF is estimations on an hourly basis.

Chris Adams: Ah, I did not know that. That's very cool to know. All right, because this is one of the scenarios that I'm curious about. Because once you do actually have like enough usage data, you often, the question is, it's almost hypothetical. [00:31:00] "Now I know I've been doing this year. What could I have done so that I can inform like future discussions?"

This is why, because a lot of the time having maybe a bunch of historical data and then being able to see would it have made a difference if I switched to another region, or would it have made a difference if I moved a particular piece of job that happened, a computing job that happened every single time at this time, could I have measured that?

And it sounds like this, these are some of the tooling that actually makes some of that possible, so you can start comparing what you would do then, say this is what we should be doing next year, now that we've actually got some of our own usage data and some carbon information about what, where we might go from there.

Cameron Casher: Yeah, and I know a lot of organizations that are trying to set their sustainability goals for the future and even in the case of ThoughtWorks, having that baseline year is very important where you can set a year and be able to say, okay, this is our baseline. This is where we want to measure up against as we try and hit some of our goals that we're setting, like our 5 or 10 year plans.

Being able to see that historic data is very important today. If you want to [00:32:00] set 2023 as your baseline, you can see what your cloud carbon footprint looks like from that year and just move forward and try and improve it.

Chris Adams: Ah, okay. That's helpful because basically the entire sector needs to halve its emissions by 2030 in order to stay on the kind of pipe, on the trajectory for 1.5 degrees. And I guess that gives you some context that works out to be about a saving, you need to reduce emissions by between seven to 10% per year depending on what you have.

And this might give you a way of saying, "okay. Here's what they are now, this year, this is what we need to beat or stay inside if we're going to be on track." Huh, I didn't know that.

Okay,

Cameron Casher: Yeah. And actually that's a good plug for the, the SCI standard at the Green Software Foundation because, uh, CCF does a really good job at giving you your holistic view of all your usage and emissions, which a lot of companies is only going to grow as they scale. Also using this alongside the SCI could be helpful to see more of the rate of carbon emissions.

Chris Adams: [00:33:00] Okay, so this is one thing that I think is interesting that really caught my eye, because when I was initially looking at Cloud Carbon Footprint, there was this idea that you can tag certain services, so you can say, here's my team, or there's a particular there's maybe a particular digital service I make available to people. Presumably you could track that, and you could say, "over this week, the SCI has been this much, which is the Software Carbon Intensity. And then I want to improve that by X percent," and you could set that as a target for the next month, and so on. That's essentially what you would be able to do. Is that correct?

Cameron Casher: Yeah. So we did implement tagging, which was a really crucial feature for us in a lot of ways to help with this whole idea of GreenOps and just understanding how you can do different breakdowns for teams or resources. And actually Arik was a really pivotal developer for the tagging. So I might let him speak a little bit about,

Chris Adams: Yeah, please do. Yeah.

Arik Smith: Yeah, for sure. So yeah, so tagging [00:34:00] basically allowed for us to display the same tags that you would use within your AWS or Google Cloud or Azure Resources, but also expose them on the resources that we were estimating within CCF. And it's great because not only does does it allow you to filter at a more custom level when you're using the CCF API, if you only want to see

resources tagged with a specific value, but it's also great for when you're trying to see aggregated estimates for a custom grouping of resources. So Cam mentioned whether this may be at a team level, or a sub organization level, or a project level, or however you wish to organize it. So, it has been great in getting a grasp in a much more custom level of where you stand within your organization and what your big contributors are that go beyond just the account and service level.

Chris Adams: No, that's actually really interesting. So, what I think it sounds like you're saying is, with tagging like this, you could basically say in a given [00:35:00] month, I know that all the billing for this particular service has been this much. And I know I've done maybe 100, 000 or 10 million requests. Then basically, because the software carbon intensity is essentially, it's the number of things you've done, divided by the emissions, or the other way around basically. That sounds like you could plausibly get SCI ratings for almost any service very quickly that way, across an entire project, basically. I didn't really, I didn't really think of it that way, but that, that, that would be right. If you just have a bunch of things tagged, you know how much usage you have, like, how many people have used this, or how many requests have you served? That will be enough to put together some calculations for a rate like that that you could track over time, right?

Arik Smith: Yeah, absolutely. I think it also opens a lot of possibilities for the ways that you can use CCF. So it's something that I forgot to mention on our roadmap. We're trying to continue to expand upon right now, a lot of those features are available at the API level, which just so happens to be the most [00:36:00] popular way people interact with CCF.

But we're also trying to leverage the dashboard to be able to view a breakdown of your tagged resources in a much more custom way and be able to filter through data through there as well. But absolutely, yeah, it opened up a door to where the world is your oyster in terms of how you choose to bring your estimates or certain groupings into your overall footprint.

Chris Adams: Okay, so I'm glad we had this conversation, because the next thing I want to ask is about community involvement, because when you're running an open source project, there's, there's a, there's a challenge about working out, do you use a mailing list? How do you actually get feedback from people? Let's say we just had this conversation about, okay, I want to have automatic SCI readings for every single thing that comes through, like, where would I ask?

Is there like a Slack channel? Is there a mailing list? Or is there a GitHub discussions board or something? Maybe I could ask one of you about where I would ask something like this to have this conversation, because I'll be honest, I might look at some of this over winter, if nothing else, over the winter break, [00:37:00] because I'd, that didn't occur to me until we just had this conversation now.

Arik Smith: Yeah, absolutely. It's been a learning experience for us. Um, ThoughtWorks has had a few open source projects previously, but at least for us personally, we've never been maintainers, so we've definitely still have been trying to figure out that cadence of what is our preferred communication method? What do people prefer?

And with this project being targeted not only to the software engineer that's curious about their own team's carbon footprint, but also IT execs that are can actively make decisions and utilize CCF to provide a lot of information behind those decisions. We have to be flexible. So we started and currently still use a simple Google group, which is on our website that you can join and become a community member of.

And we get lots of emails that way, either asking direct questions or troubleshooting information from our team or just the community at large, which has been [00:38:00] great because sometimes people may chime in and share their experiences or give their feedback. Of course, since our project is on GitHub, we leverage a lot of GitHub issues and the typical cadence that you would find within the open source repository there.

So people usually raise new issues for bug reports or features, and we've also recently enabled the GitHub Discussions board for our repository to allow for further discussions, especially around feedback or general questions to hopefully try to lessen the load on our email group a bit and keep it closer to our code since we've been seeing a lot of technical questions and bug reports and troubleshootings coming through there and more recently we've been trying to experiment with a Slack channel to get some of those conversations going at least a little bit more seamlessly because one of the main things we've been troubleshooting and learning from is the way that we interact with collaborators.

A lot of times when [00:39:00] other organizations or companies are standing up CCF within their own organization, they often want to get back to the tool or they may find a bug or something to improve and may open up pull requests and a lot of that conversations have been through the email group or GitHub at large, but for instance, that Azure API migration that we're working on is actually being collaborated with some engineers from Resync that Cam met during his time in Berlin.

So we've opened up a Slack channel to hopefully make some of that collaboration and communication and questions easier. Before it's been ad-hoc, "okay, we'll join your Slack or we'll join your, your Teams account or maybe we can do a simple Google chat," but hopefully to centralize and encourage a lot of those communications and collaborations going forward.

Chris Adams: Ah, cool. So you said one thing that was quite interesting there, about that it's not centri It's, this gives me the impression that it's, that Cloud Carbon Footprint is almost like yes, there's obviously some work from ThoughtWorks, and some [00:40:00] contribution there, but it exists as its own project, and I think when I'm looking up now If I go to GitHub, it's its own organization, so there's like a, there's the implication there that this would be like a community project that, in the long run, would have other organizations contributing and maintaining it, because I didn't know about Resync actually contributing in that way.

That's really neat.

Arik Smith: Yeah, absolutely. That's the stance we've always taken with CCF. I know we mention ThoughtWorks a lot, and that's why we're trying to pivot the language to ThoughtWorks just being the primary sponsor of the tool.

Because at the end of the day, they have invested a lot. Within Cam and I's team and the sustainability solutions team at large to put in a lot of the day to day work within the tool, but everything we spoke about from that initial methodology and building on top of Etsy Cloud Jewels, like there were conversations with Etsy actually being had to get Feedback on the methodology, we're coming up in the okay to move forward that way.

Uh, we've collaborated with cloud providers [00:41:00] themselves to get feedback on the way we're doing things and to see if our estimates make sense. And yeah, even with other organizations on our website, we have a list of innovation partners, which really don't even cover everyone we've worked with that have contributed to the project in some way.

And that's why even on GitHub, it's organized within, at least all the, all of the CCF related repositories are organized within the Cloud Carbon Footprint Organization. Because at the end of the day, it is a community supported and collaborative tool. And I think that's the biggest and strongest part of all is that this isn't a methodology that one organization has owned or came up with, but that the, I want to say the entire industry who really cares about this subject has contributed and promoted growth within.

Chris Adams: okay, so like an open place where there's some consensus to actually figure out, "okay, this is how you measure this stuff." All right, wow.

Alright, we're coming up to time now, so I just want to make sure, are there any things that you folks would like me [00:42:00] to draw attention to, or are there any questions I haven't asked yet that you'd like me to ask or you want to talk about before we come to the end of this?

Cameron Casher: I'll just say that I just want to thank you for letting us speak to CCF. Um, If there's anything that's become more apparent to me recently, it's been the impact that CCF has had in the community and in this domain. And I know we talked a bit about this, but just stressing that we want to hear more from the community.

We want to understand the people using it. So really feel free to reach out to us in any of the ways that Arik just explained, Google or GitHub. And. Yeah, we'd love to talk more and understand about how you're using CCF and one of the things we didn't really get into today was just how CCF can really be like the starting point for a lot of companies because just understanding where you're at in measuring is a first phase of even this Green Ops idea where you get into [00:43:00] understanding, measuring, and then the final act of reducing your carbon footprint. So, we'd like to think that CCF really helps enable that act of reducing, and I know the Green Software Foundation has a lot of great material around where to start, especially around the cloud with the green software pattern.

So, using CCF to have sort of a perspective and baseline of where you think you can start to tweak and make some changes is really a cool and important way to understand how different people are mitigating their carbon footprint in the cloud.

Chris Adams: Brilliant, thank you for that Cam. And to Arik, I realize that I should have asked this at the very beginning, but if someone wants to find out about Cloud Carbon for the project, is there a domain name, is there a website, what would you, what would they type into their favorite search engine or browser?

Arik Smith: Yeah, absolutely. Usually, if you Google Cloud Carbon Footprint, we're appreciatively [00:44:00] one of the first, if not the first, to pop up. But, yeah, you can definitely find us at cloudcarbonfootprint.org. Um, it contains our website, our main documentation, and a breakdown of our methodology. There's also a live demo there, if you don't want to download the tool but want to get familiar with what the dashboard is and the capabilities of it, um, and also links to our GitHubs and some of the community groups like the Google groups that we mentioned is available there as well. Otherwise, like Cam mentioned, we're pretty open, so if you still have a question or want to get involved in some way or even have feedback, which we welcome a lot, feel free to hit us up on LinkedIn or shoot us an email.

Maybe we'll provide a link or something and, or any preferred channel that you can find us on.

Chris Adams: Brilliant, thank you for that. Okay then, and maybe we'll just wrap up there, but I feel like there's maybe one thing that it's really worth emphasizing. If you're using tools like Cloud Carbon Footprint, please do tell the maintainers that they're using them. [00:45:00] Because usually you only ever hear from people when they're unhappy with your product or project rather than when they are using it. And it does make it easier to feel better about your life choices. So that was the last thing I might share with you, uh, because it's something that we actually experience ourselves with CO2.js as well. But folks, I really enjoyed learning about cloud carbon footprint with you here. And, uh, I'm looking forward to some of the cool new things that come up from there.

Once again, thanks again for your time. And Cam, enjoy your skiing. And Arik, enjoy adventures with Link, alright?

Arik Smith: Will do. Thanks a lot, Chris.

Cameron Casher: Thank you, Chris.

Chris Adams: Thanks guys, see you around. 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'd love to have more listeners. To find out more about the [00:46:00] Green Software Foundation, please visit greensoftware.foundation. That's greensoftware.foundation in any browser. Thanks again and see you in the next episode.