In this episode, we go to both Denver and Montpellier to meet Cameron Casher, Clean Tech Strategist at ThoughtWorks, and Benjamin Davy, Sustainability Director at Teads. Being both hands-on engineers 👨‍💻 and well-known voices in Cloud Sustainability 🌱, they were the perfect match to assess the Sustainability dashboards provided by AWS, GCP and Azure as well as pro and con of Cloud Carbon Footprint, the open-source tool. Which one can truly help responsible technologists to assess 📏 their GHG emissions ?

❤️ Subscribe, follow, like, ... stay connected the way you want to never miss an episode!

📧 You can also send us an email at [email protected] to share your feedback and suggest future guests or topics.   

Gaël: In this summer episode, we do a premiere: Green IO first group interview on 3 different time zones. We went to Denver where we had the pleasure to speak to Cameron Casher. Cameron is a Senior Software Engineer as well as a Clean Tech Strategist at ThoughtWorks - Does the name of this huge Chicago-based Tech consultancy company ring a bell? Yes there are the ones best known for crafting the Tech Radar. But this is not the reason we have Cameron on the show. Actually, Cameron is one of the main contributors to the Cloud Carbon Footprint initiative as well as a founding member of the Green Software Foundation. We also had the pleasure to welcome Benjamin Davy on the show. Based in Montpellier Benjamin is Tead’s Sustainability Director. 

Tead’s name might not ring a bell except if you work in digital marketing but they are one of the biggest Media platforms worldwide. And with ads distributed to over 1.9 billions people every month they do have a tech stack worth paying attention to, especially knowing how much they use (and pay) for AWS and GCP services. However, if you navigate into the Digital Sustainability field in Europe, Benjamin’s name should ring a bell. He has been a restless advocate for cloud sustainability, sharing many insights on Tead’s engineering blog or in conferences like the AWS Summit or APIdays as well as volunteering for Boavizta whose API & open database track the environmental impacts of devices and servers. 

Welcome Cameron and Ben, thanks a lot for joining Green I/O today.

Cameron: Thanks for having us.

Benjamin: Thanks a lot Gaël, it's a pretty nice introduction.

Gaël: I try to do my homework :). So, Benjamin, let's talk about you! Any misses in my introduction or some information you'd like to highlight?

Benjamin: No, it's all good. And this is my first time on the podcast, so I'm glad it's on Green I/O.

Gaël: Thanks a lot. It means a lot coming from you. And what about you, Cameron? What did I forget to mention about you?

Cameron: Not much. Honestly, I also point out that this is my first podcast. So also happy that it's Green I/O but I guess I just wanted to mention that along with the digital sustainability side, I'd like to think that I have a deep connection with the environment living in colorado in the US where I try to center all of my favorite hobbies around outdoor activities, like hiking and camping and skiing in the winters. So, happy to be talking today,

Gaël: I heard this is an amazing place for outdoor activity! I had a question for the two of you, which is a very standard question in my show. How did you become interested in sustainability in general and the sustainability of our digital sector in the first place?

Cameron: So, I'd say my interest with the digital sector started when I joined ThoughtWorks as I started volunteering my free time in the sort of grassroots project to help define what our North America team wanted to focus their work on and I was assisting with industry research and interviewing folks involved in the sustainability sector across various companies, and as it turns out, this work really helped build the foundation around our team's goals and ultimately help towards the decision to start building the Cloud Carbon Footprint, open source tool that I now help maintain. So I'd say, you know, joining ThoughtWorks really helped jumpstart my interest.

Gaël: I wouldn't have believed that such a big company like ThoughtWorks would have created a trigger for action for sustainability in the first place. So kudo to them,

Cameron: it's really, I'd say more so individual contributors at the company tried to basically form an initiative and I was lucky enough to get exposed and connected with the right group people early on.

Gaël: Okay, got it. Well, thanks a lot. And what about you, Ben?

Benjamin: Yes, so I've been looking for ways to work or contribute to having a positive impact during the past few years, initially I was mostly interested in ways to fix plastic pollution. So I got really into open source projects like precious plastic, if that's something that was really listening to the podcast now. So, an initiative that created open source plans to build the machines to recycle plastic and wanted to apply also the same kind of initiatives internally and in my day to day job and discussing with my colleagues, I mean, might be 2.5 years ago now, we wanted to know more about the impact of our digital service and this is how I started to look into it actually.

Gaël: Okay, so from plastic pollution to digital sustainability. That's cool. I'd like to start talking about the main topic of this episode, the sustainability dashboards. So let me introduce it that way. We have recently seen a lot of hype around the pledge made by the three big Western cloud providers to reach net zero emissions, being carbon neutral, etcetera. Some NGO pointed out that these environmental claims are not without flaws but today we'd like to focus the discussion not on the sustainability of the cloud - at least not only the sustainability of the cloud - but the sustainability in the cloud and having a hands-on discussion for all the CTO and their teams willing to green their cloud infrastructure so how AWS, GCP and Azure empower their customers to monitor and reduce their greenhouse gas emissions. What's the state of the market regarding Cloud Sustainably if I may ask? And Ben I recall, your company is a big customer of both amazon web services and google cloud platform. What's your view on these tools? Both AWS sustainable console and DCP carbon sense suit.

Benjamin: I think we could spend an hour already discussing only on these topics. I'll do my best to answer quickly to start. I would like to say that I had to spend quite some time learning about carbon reporting methodologies to be able to understand what was actually reported by these tools. So there are two important things I have in mind regarding these carbon calculators. First is that they can't really be compared as they all calculate emission on different parameters. So if we look at AWS and GCP, they focus on emissions related to the electricity consumption of their data centers on this topic. Most of the sustainability initiatives focus on renewable energy procurement. There will be a lot to say about this, but not all procurement schemes are equal in terms of impact - or positive impact - and it's hard to get precise data about this. So what's important is that in any case the electricity that is used by data centers comes from the local grid, the local electricity grid and when the grid is not available, it will be instantly backed up by diesel generators or more common power sources and not really by remote wind or solar generators. So this is important to focus on electricity. They talk about renewable procurement, but in reality we know that the electricity they actually use is from the grid and talk shortly about Azure. Azure reports broader scope including emissions related to manufacturing, transport and end of life of the hardware they use to provide the clothes services. So these emissions are called Scope three and are really important. We might talk about this a bit later and GCP and AWS actually communicated on the fact that they are working on scope three reporting as well. So the first thing is that each cloud provider has its own methodology and perimeter on which it covers this. The second point is that on top of reporting on different scopes, they also use different ways to allocate emissions to calculate how they distribute uh emissions to the use of cloud services. What I can say on this point is that Microsoft were the first were the first to look into scope three emissions documented how they calculate hardware, lifecycle emissions in a very detailed white paper. So it's really worth having a look. But I won't comment on the report itself. Maybe I'll let Cameron talk about it later as we don't run anything on Azure. Coming back to GCP and AWS. If we look at GCP the report details scope two emissions and they actually shared about the methodology. They used to allocate these emissions to the cloud products and most importantly, they also transparently disclosed the carbon intensity of the electricity grid that is used to power the data centers which is really nice. We can say so from a client perspective, user perspective, the report that they provide is interesting because it will reflect true carbon emissions related to electricity consumption. The report granularity is not perfect but it's already useful to observe the impact from architecture changes. For example, their reports are available on a monthly basis with a few days of delay and the split of the emissions is per google cloud projects. So it's not that granular but it gives some insights. Now if we look at AWS we don't really have any details on the methodology that is used and on top of this, the emissions related to the use of electricity reported using a market based reporting methodology. So to be simple, this methodology will consider that you can count zero emissions for the electricity you consume from the grid when this consumption is matched with renewable energy procurement and again it's hard to assess. We don't have all the details of how they procure this energy. So it's a bit difficult to say if it's good, really good or not that good. But more practically speaking, the report is available within a three months delay due to this procurement process and emissions are split per month and region. So it's a bit less granular and for example for teads our European activities are hosted in Ireland and the report simply tells us that the use of AWS emitted zero gram of CO2. So to be totally honest in our case this reporting might only be useful for corporate accounting and again, it's only covering part of the total emissions. We would like to have a view on this on. I would simply conclude by saying that these reports are not yet granular and complete enough to be used by engineering teams to make educated decisions on how they use cloud resources. It's a good first step. It gives some insights depending on the provider. It's more or less documented. More or less granular but it's not as detailed as I wish. It would be.

Gaël: Ben just to wrap up what you've said actually, what should be assessed with these reports is a/ the openness of the methodology; b/ the granularity - by granularity what you mean is really, is it just the bulk of all your services or you can go very deep into tracking? And there is also this geographical granularity. So this is the third point. And the fourth point for AWS is you’re based on market based and that's not actionable. Isn't it any ways when you use the AWS console that you can switch from market based to location based and vice versa?

Benjamin: No, not directly. And I forgot to mention that it's for us. It's also split by main services. So like you mentioned, so you have EC2, S3 bucket, and the main big services in the region. You cannot switch to a location based. However they share about the amount of renewable electricity that, so they give some information on how they calculated the market based. So you could reverse engineer it, but it's not really accurate because there are some subtle things in the calculation. So you could maybe try to reverse engineer the report, but that's not really a precise or accurate

Gaël: before jumping to Azure with Cameron. I'd like to ask your opinion on PPA.

Cameron: I think the important thing to consider and Ben has been touching on this fact that Cloud Carbon Footprint focuses on location based and not market based. So we're not concerned with any Power Purchase Agreements or Renewable Energy Credits, we're only concerning ourselves with the pure amount of carbon or CO2 emitted into the atmosphere. And I think it's also worth arguing that estimates by definition are not, you know, the most accurate and how much they are useful is more important than being accurate. I think it's what I might say.

Benjamin: I would say that the issue with PPA. Is that they are not disclosed. We don't really know which PPA is powering which data center. So if we add more transparency into this topic, we might be able to include it in calculation. But again, if we even look at the GHG Protocol, the standard for carbon reporting, it's written on this standard that you must - you shall, I think that's the exact word that is used - report, do a dual reporting, so reporting both location based to have the actual emissions and market based to also show that you have initiatives to fund new renewable energy generation plants. So ideally I think we would like to have both which is what GCP is doing. So some are doing it, I hope everybody will be able to at some point

Gaël: and that's a very very interesting statement that should be done. If we were to follow a GHG protocol! And Cameron, can we go back to actually Azure because we didn't speak that much about Azure and I know that you practice it quite a lot

Cameron: sure. I'm happy to share some of you know the notes I've taken around the tool. So Microsoft's emissions impact dashboard I believe is available generally to those with a power bi pro subscription. The dashboard provides insight into total Microsoft emissions associated with your Azure cloud use which includes Scopes 1, 2 and three. These emissions calculations take into consideration emissions associated with the full life cycle of hardware devices used in their data centers, data center efficiency and the grid emissions factors for each data center. It accounts for the energy used to run your services and takes a market based approach by factoring in renewable energy purchases by Microsoft. The dashboard allows you to see this data in various ways, including year to year comparisons and trends and insight into projected end of year use on the emissions details page provides further granularity allowing you to view emissions and usage quarterly and understand the impact of subscriptions, services and regions. It also contains a map illustrating your emissions by location especially relevant to organizations assessing their move to the cloud. The dashboard includes a page highlighting the estimated emissions avoided due to your current Azure cloud use. It provides a rationality savings with estimates of the amount avoided due to data center efficiencies, renewable energy purchases and factors in the carbon spend of the migration. It puts this in real terms with an estimated percentage saved and the equivalency in terms of driving distance and the emissions impact dashboard aims to assist organizations as they look at reporting emissions, allowing you to export data, generate custom reports and view an auto generated preliminary GHG Preparation report and a description of the methodology approach can be viewed within the tool and links to additional resources, resources such as the validated scope three methodology white paper. So in my opinion, I think the Microsoft tool is very robust. I think the emissions impact dashboard was the first out of the three major to come out and as Ben mentioned, it does consider scope three and also the market based approach.

Gaël: It sounds more robust than the others, indeed! Do you know how they assess them? Savings made thanks to the migration,

Cameron: not in too much detail, I know that they provide a white paper around how they consider what some of, you know, the migration emissions might be. I think AWS does something a bit similar where they track what the potential savings could look like with the migration as well.

Benjamin: Yeah. I think most of the providers did this type of study to compare an average data center workload running in average data centers and estimating the impact from moving to the cloud in terms of the use of resources and the efficiency gains by having a better PUE for example. So most of the providers did this type of study. Sometimes you can argue that some hypothesis that they took is maximizing the efficiency gains we could discuss about this at length.

Gaël: They don't offer a way to fine tune “where do you come from?” for instance “Were your datacenter being powered by mostly renewable energy versus being on the very carbon intensive grid” that's not an option. It's just an average data center around the world or at least in the region where you start from?

Benjamin: Yeah. For AWS, they did studies specifically for Europe for the US I guess. And each time they adapt the methodology to take an average data center profile specific to the region.

Cameron: I do believe too that Google's more transparent methodology states that they use hourly emissions pulled from tomorrow's electricity map, which I think is pretty awesome.

Gaël: Kudo to them. So your feedback on the three dashboards is very interesting and I'd like to link it to a discussion I supported in the Climate Action Tech community between Drew Engelson and Ismail Velasco the tech lead at graze.com. He wanted to try the carbon footprint on individual AWS services and super soon they pointed out that cloud carbon footprint was a much needed tool, and Cameron correct me if I'm wrong, but you joined this conversation as well. So maybe it's time to start talking in depth about Cloud Carbon Footprint and also how useful it can be when you use AWS, when you use GCP and maybe is it still useful or not when you use Azure? Because it sounds pretty robust what you've described with the Azure emission impact dashboard.

Cameron: Yes. So I'm a big fan of the climate action community. I've got the slack up on my computer frequently, so I like to see what the latest news is and ongoing discussion threads. So I was happy to notice that conversation take place. Yeah, I think um, you know, when the CCF development first started these tools by the cloud providers hadn't really been released and now that they have, I don't see that in a negative way. In fact, I think it's actually helped the emissions calculations behind the CCF methodology a bit, as we've been able to maintain really solid relationships with some of the people behind the scenes at google and AWS and Microsoft and you know, understand how our calculations might differ and get them into the same order of magnitude difference based off how we might be going about different approaches. So it's been really nice to collaborate in those ways, but I think the main difference I would say that CCF provides and why it may not have become obsolete yet is that it's a cloud agnostic solution. So we're talking about how AWS, Microsoft and Google have their own dashboards with their own methodologies. Well if you're using multi cloud, like a large percentage of organizations are, how are you going to realistically compare and contrast those results? And that's where we think CCF can be a bigger differentiator using the same methodology across the three major cloud providers. You can see your results in similar terms. I think there's also something to be said about the granularity of the data that we're working with since, you know, there's only so much we can grab from the cloud providers themselves. Cloud Carbon Footprint is really doing the best it can with the given data that's available right now. So along with the, you know, cost and usage reports and billing data that we're querying to base our estimations off of, we can't grab a lot of these carbon metrics. So what we have to do is use our methodology that we've validated, source some open data sets online, including spec power database where we can view, you know, wattage values, memory values associated with specific servers and try and map those to some of the data we're able to retrieve in the billing and the fact that we're able to use these average values from the open data that we're sourcing allows us to get into a more granular data set. So what the CCF tool is able to provide is data by day without a lag! The only lag is the data we're able to get from the cloud providers. How frequently we’re able to pull that billing data. I could talk a bit more about, you know, what's working well for CCF too

Gaël: I would love to, I just had one question before: is CCF totally open source?

Cameron: Yes, So that was a big decision right out the gate when CCF was being developed, deciding to make an open source, it just seemed like the right decision. Before my time ThoughtWorks had a history of developing open source tools for the community. So I think that was a really fun journey to start on creating Cloud Carbon Footprint as an open source solution has really benefited us in a lot of ways. And you know, that's how I was able to connect with Ben in the first place where you know, once we started gaining traction, sending out calls for actions about, you know, working with industry experts to try and, you know, let's say, get a solid calculation out there for calculating memory consumption in the cloud, you know, that's where we were able to connect with Ben and discuss what his thoughts were, you know, work to build that back into the tool. So we're getting a little bit of validation there from, you know, industry and community experts being able to see what our source code looks like and provide feedback in real time.

Gaël: And do you consider now that you've managed to build a good enough ecosystem of peers being able to provide feedback from the different cloud providers, different partners in the industry? 

Cameron: Yeah, so part of my day to day work includes being a maintainer of the Cloud Carbon Footprint tool along with my team. So you know, each day we're monitoring for new issues, new pull requests, we have a Google group forum where anyone can email us directly with questions or insights and you know, the traction hasn't really slowed down there. There's a lot of community involvement and you know, I'm happy to hear any time. There may be a new organization adopting Cloud Carbon Footprint.

Gaël: Ben mentioned earlier that the AWS Dashboard was very interesting to get a general idea but that it was not really actionable for an engineer. Do you believe that CCF has managed to be truly actionable for engineers to make an educated decision?

Cameron: You know, we have a demo that you can view that has mocked data right on our website and it shows you what our front and dashboard looks like and what sort of data you can view and we think that this data could be utilized from different levels through practitioners all the way up to sustainability executives who might want to see trends over time or spikes on a given day, if you see a time series chart there. Otherwise, if you're a practitioner or a developer that are really wanting to investigate what a spike might be on a given day, you can really analyze the data you're given, see what service it's coming from, see what day it is, see what region it's located in, see what account it's associated with. And then we also provide actionable recommendations. These are provided out of the box, just based off what we're able to query from the cloud providers, which is mostly right sizing recommendations. So you might be able to, you know, terminate an idle instance, which I would think most developers are aware of most of these recommendations but piece that we're able to add through our dashboard is the equivalent carbon savings and energy savings associated. So not only cost

Gaël: Fair point and Ben, is it the way you use it as a practitioner?

Benjamin: So we used this bottom up approach starting from the granular data for different things. We initially used it to perform life cycle assessment for digital service. So it's a big, big study to understand the overall emissions of our platform. But actually this type of bottom up solution can be used for many things to report carbon emissions per service. We usually report cost per service and our teams are accountable for the cost of the service they manage. Being able to also report carbon emissions is quite interesting because you can compare evolution in cost and evolution in carbon. So that's an additional insight that can be rewarding when you work on optimizations! You can also use it not related directly to bills, but during the design phase, use the data from the Cloud Carbon Footprint. The data set to help choose between two technical solutions or even calculate positive impacts of adopting best practices like the ones AWS published with its well architected framework. They did a great job on this part. So actually what we're able to do with CCF data is to yeah, have a deeper and more granular analysis on day to day activities optimizations, having more metrics and on our daily jobs that

Gaël: And at Teads your infrastructure is with multi-cloud providers. And Cameron, you  say that CCF is especially valuable for a large company having several cloud providers. Is it still true for a smaller company having only one cloud provider? I mean maybe not one running on AWS because obviously Ben has described pretty well that it's not that much actionable. But for instance if you had a company running solely on either Azure or GCP, do you believe that they should still invest a bit of time and energy into using CCF?

Benjamin: Actually as most reports are on a monthly basis, CCF is on a daily basis. So even here you can see that the granularity can serve different use cases.

Gaël: So CCF is definitely a silver bullet when it comes to being immediately actionable I would say. 

Benjamin: Yeah it might be.

Gaël: But Azure report comes on a monthly basis as well Cameron? Or do you have access to it on a daily basis as well?

Cameron: So as far as I've seen, the lowest granularity that you can get is quarterly.

Gaël: OK

Cameron: In theory you could get monthly by selecting one month at a time to view the data. But when looking at emissions data and emissions savings, it seems like quarterly is as granular as you're able to see. I think I may have mentioned this you know, it's useful to take in all the different perspectives and if you have Azure data, you know, use the dashboard alongside CCF or use the AWS carbon footprint too alongside CCF. And you can even plug in the billing exports from GCP and plug those into CCF. So you could even see your GCP data in the CCF dashboard. So.

Gaël: Thanks a lot Cameron. And another point is “okay, so I might have several cloud providers, but I might, - yes, that's true. That happens especially in the public sector, but not only; in heavily regulated industries for instance - I might still have my own data centers, my bare metal servers. Can I use CCF to help me with this infrastructure or do I need to look for something else?

Cameron: I think that what we aim for CCF to do is provide transparency first and foremost with what your data looks like and then from there and this kind of gets into what ThoughtWorks can offer as an organization from a consulting standpoint is allowing our teams to go in and really assess what your cloud infrastructure looks like and based off the data, we're able to view from CCF or also the cloud provider tools in tandem. We can, you know, go in and assess and analyze what your current systems might look like and identify ways that you could improve the infrastructure based off green software principles. And I just want to call out that currently I'm involved in a working group at the Green Software Foundation where we are developing green software principles, patterns and practices So principles being the main educational piece that we're still working out a training for to be able to understand first and foremost, like what you're dealing with with green software, what the main core principles are with learning objectives. And then patterns is how you would apply the principles to your infrastructure and then practices is giving real time examples of how you implement some of those patterns

Gaël: And could you give us an example for instance or is it still too early?

Cameron: No, I could give you an example of, you know, an optimization strategy. There's this idea of being carbon aware and that pertains to identifying the best time of day or location to be using your system. So if you were to be able to view that during a certain time of the day, maybe around noon where the sun is shining and the wind is blowing, there might be more renewable energy resources on the grid. That might be a more optimal and efficient time to be running any batch jobs you might have or by location. You know, if uh if you were formally running services that were based in you know Iowa in the US, that might not be the cleanest region. So you could switch regions and workloads to run in a cleaner region, which means more renewable energy is on the grid maybe in the UK. So that would be, you know, one of the principles and the pattern could be identifying how exactly you want to set up that batch job to understand when it should run, where it should run. And this is where you could utilize certain KPIs like tomorrow's electricity map to understand hourly emissions data. And then maybe building out a machine learning or even a i to be able to measure that and know to switch times or switch locations when those batch jobs should be running.

Gaël: Okay. Ben, do you have also some feedback to share on these green computing principles? I mean, did you get involved? 

Benjamin: We simply try to optimize the resources we use and use them as efficiently as possible. So most of the work we did was rather finding ways to automatically shut down. For example, see the CI/CD is useful during certain times of the week. And during weekends or at night, it's not of use for anybody, so we shut it down, and full of machines and we we also worked on many, many optimizations so that the infrastructure team at Teads did that. Adding an carbon aware logic into this is something uh we discussed internally, it's something we can imagine for as a Cameron said, so for batch processes, for example, for machine learning training that are done regularly may these are the types of service of processes of workloads that can be delayed in time or maybe moved in space, but it's still very early days to… I don't know any framework that would ease this and maybe I hope that's the next frontier for open source.

Gaël: Well, that's very interesting because with see that this is very, very early stage. But folks, I'd like to… just before jumping on the second part of the show, there is one point that actually I forgot to ask you: “And what about the other cloud provider?” So I did my homework, I tried and I managed to reach out to some of them in France, UK and Switzerland and this is actually the discussion I'd like to report here. The discussion I had with Nico Schottelius Data Center Light CEO. They're based in Switzerland. They've got their own hydro power plant and we had a very meaningful discussion and he was pretty straightforward regarding CCF saying “I’d love to participate, I don't have enough resources and I've got almost no push from the market”. So after the discussion, I was like “maybe this is not the best example because obviously these customers know that they're truly green powered - like locally green powered”. But that's also a message that I've heard from other people like Scaleway and friends, etc. “we do it on a voluntary basis, but we don't have that much market push to join CCF or to disclose better metrics on our carbon footprint. So what is your take on it?

Cameron: So um, you know, at the root of what CCF is doing is it's utilizing the methodology that we've worked on to convert billing and usage data to energy in CO2 emissions. And what we've been able to do is hook that up to the billing data that we've called via API. To the major cloud providers. And we've built the tool in such a way that it is extensible to add more cloud providers outside of the main three. You know, as long as you can get the necessary metrics to make the calculation then there's no reason you can't add those in and you know, with all the demand that we have with the tool we've had to really try and prioritize what some of the work should be laid out on our roadmap. Um currently, you know, we're trying to work on performance optimizations on our backlog by adding other cloud providers, but truly we're driven by the demand of the community and our clients that we're working with with the tool. So I would love if, you know, there were some open source community members that wanted to work on adding something like this and creating a pull request in the repository and GIThub. But as far as market push, I think, you know, we're starting to get into a phase where there might be more regulatory pressure from governments here in the US. You know, there's SEC proposals about having more diligent reporting take place and you know, this is where organizations might need to start thinking about this sort of thing and this might, you know, traditionally be done by a Chief Financial Officer, but this is where you could involve a CIO as well and really have someone that's more closely related to the digital sustainability side and have their inputs weight out as they might need to start reporting on some of these different greenhouse gas protocol

Gaël: Thanks a lot Cameron! Folks. Let's switch to the second part. Maybe because I think you've already shared quite a lot of knowledge. It was a good walk around all these dashboards and what CCF can do. So thanks a lot to both of you for joining the show. 
And my dear listeners, I hope you enjoyed this episode as much as we did, making it for all of you. As you rightfully guess, the next episode will be live within a week, and we will stay with Cameron and Benjamin to talk in depth about embedded carbon and other environmental impacts of cloud computing.