Screaming in the Cloud - Google Cloud Carbon Footprint with Steren Giannini

Episode Date: August 16, 2022

About SterenSteren is a Group Product Manager at Google Cloud. He is part of the serverless team, leading Cloud Run. He is also working on sustainability, leading the Google Cloud Carbon Footprint product.Steren is an engineer from École Centrale (France). Before joining Google, he was CTO of a startup building connected objects and multi device solutions.Links Referenced:previous episode: https://www.lastweekinaws.com/podcast/screaming-in-the-cloud/google-cloud-run-satisfaction-and-scalability-with-steren-giannini/Google Cloud Carbon Footprint: https://cloud.google.com/carbon-footprintGoogle Cloud Region Picker: https://cloud.withgoogle.com/region-picker/ Google Cloud regions: https://cloud.google.com/sustainability/region-carbon 

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. DoorDash had a problem. As their cloud-native environment scaled and developers delivered new features,

their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their application suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business confidence and peace of mind. Read the full success story at snark.cloud slash chronosphere. That's snark.cloud slash c-h-r-o-n-o-s-p-h-e-r-e. This episode is sponsored in parts by our friend EnterpriseDB.

EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years, and now EnterpriseDB has you covered wherever you deploy PostgreSQL, on-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal. All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money.

They can even help you migrate legacy applications, including Oracle, to the cloud. To learn more, try Big Animal for free. Go to biganimal.com slash snark and tell them Corey sent you. Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today was recently on the show. Steren Giannini is the product lead for Google Cloud Run, and we talked about that in a previous episode. If you haven't listened to it, you might wish to go back and listen to it, but it's not a prerequisite for what we're about to talk about today because apparently Google still does this 20% time. And one of the

things that Starin decided to do, because, you know, everyone needs a hobby, he decided to go ahead and start the Google Cloud Carbon Footprint, which is, well, Staren, thanks for coming back. What the hell is that? Thanks for having me back on the show. So yes, we started Google Cloud Carbon Footprint, and this is a product that now has launched publicly, available to every Google Cloud customer right out of the box of the Google Cloud console. I should also point out, because people always wonder, it's the first thing I always check, yes, this one is free. I'm trying to imagine a scenario in which you charge for this, and I was incensed by it, and I can't. So good work. You

aren't charging anything for it. Good job. Please continue. So Google Cloud Carbon Footprint helps Google Cloud customer understand and reduce their gross carbon emissions linked to their Google Cloud usage. So yeah, what do we mean by carbon emission? Just so that we are all on the same page. These are the greenhouse gases that are emitted due to the activity of using Google Cloud that are notably responsible for climate change. And we report them in equivalent of carbon dioxide, CO2, and, you know, a shortcut is just to say carbon. Now, I'm going to start with something relatively controversial. It's an opinion I have around this sort of thing.

And I should also disclaim, I am not in any way, shape, or form disputing that climate change as caused by humans is real. It is. If you don't believe that, please go listen to something else. Maybe InfoWars. I don't know, and I don't care. I just don't want you around. Now, the problem that I have with this is, on some level, it feels like a cloud provider talking to its customers about their carbon footprint is on some level shifting the onus of responsibilities in some way away from the cloud provider and onto the customer. Now, I freely admit that this is a nuanced topic, but how do you view this? What I mentioned is that we are exposing to customers their gross

carbon emissions. But what about their net carbon emissions? Well, Google Cloud customers' net operational carbon emissions are simply zero. Why? Because if you open Google's environmental report, you will see that Google is purchasing as much renewable energy globally for the year as it is using. So that means that on a yearly basis worldwide, every kilowatt hour of electricity has been matched with renewable energy. And, you know, this Google has been doing since 2017. Since 2007, Google was already matching its carbon footprint with carbon offsets. But 2017, Google went beyond and is matching the purchase of the electricity with renewable energy. So in a sense, your net

operational emissions are zero. Now, that's not sufficient for our customers. They have some reporting obligations. They need to know before this renewable matching, what were their gross emissions. And they also need to know what are their emissions coming from not only the electricity usage, but maybe the data center manufacturing. And this is all of what we expose in Google Cloud Carbon Footprint. They are before offset, before renewable energy matching. And you're right also to say that this is not only the customer's problem. And indeed, set a goal to get to 100% carbon-free electricity for every hour in every location. So the big goal for 2030 is that at every hour,

every location, the electricity comes from carbon-free sources. This is very ambitious and never done before, of course, at the scale of Google, but this is the next goal for Google. The challenge that I have in the abstract with cloud providers more or less shaming customers, not to say that's what you're doing here, about their carbon usage and their carbon footprint is, okay, I appreciate that this is everyone's problem. And yes, it is something that we should be focusing on extensively. The counter argument is that I don't recall ever getting a meeting invite

to a Google or Amazon or Microsoft or Oracle negotiation with any of your power bills or power companies or power sourcing. I have no input whatsoever as a customer on those things. And on some level, it's, ooh, you're causing a particular amount of carbon to be used by your usage of these services. Well, on some level, it feels like that is more of a you thing than a me thing. And I want to be clear, I'm speaking more in the abstract to the industry rather than the specifics of Google Cloud, not to unfairly put you in the position of having to speak for everyone. No, but you're right.

If you were to do nothing, Google is constantly working hard to sign more power purchase agreements with some renewable energy sources or optimizing its data centers. Google Cloud data centers are one of the most optimized data centers in the industry with a power usage effectiveness of 1.1, which is basically saying that the energy that is used to power the facility over the energy used to actually power the server is 1.1. So not that much loss in between. So all of that to say, Google Cloud and Google are working very hard anyway to reduce Google Cloud's carbon footprint and the carbon footprint of Google Cloud customers. So if you were to do nothing, the charts that you are seeing on Google Cloud carbon footprint should

trend to zero. But in the meantime, you know, that's not the case. So that's why we show the data, like many customers want to know or have the obligation to report on this data. One of the challenges that I see, and I believe this might even be related to the Carbon Footprint tool that you have built out on top of Google Cloud, is when I am looking at where to place something. First, let me just say the region experience is wildly different than I'm used to with AWS. In the AWS universe, every region is basically its own island. It is very difficult to get a holistic view between regions. Google Cloud does not have that approach.

There are advantages and disadvantages to both. I'm not passing any particular value judgment for once on this topic in this context. But where do I want to spin something up? And I have a dropdown of the regions that I can put it in. And some of these now have a green leaf next to them and others do not. I'm going to go out on a limb and assume you had a hand in this somewhere. Exactly. That's something I worked on with the team. So you will see on the Google Cloud console location selectors, on the Google Cloud location page, on the Google Cloud documentation, you will see a small low CO2 indicator next to some regions. And this indicator is basically saying that this region meets some criteria of high carbon-free energy percentage or low grid carbon intensity.

So you don't need to go into those details. You just need to know that if you see this small leaf, that means that for a given workload, the emissions in that particular region will be way lower than on another region which doesn't have the leaf. Often at Google, when we do a change, we A-B test it. We A-B tested those small low CO2 indicators because, you know, that's a console-wide change, so we want to make sure that it's worth it. And well, it turns out that for people who were in the experiment, so people who were seeing the leaf, among new Google Cloud users, they were 50% more likely to pick a low-carbon region when the leaf was displayed. And among all users, it was 19%.

So you see how just by surfacing the information, we were able to significantly influence customers' behavior towards reducing their carbon emissions. And, you know, if you ask me, I think picking the cleanest region is probably one of the simplest action you can take, if possible, of course, to reduce your gross carbon emissions. Because, they don't require to change your architecture or your infrastructure. It just requires you to make the right choice in the first place. And just by letting people know that some regions are emitting much less carbon than others, we've basically allowed them to reduce their footprint. A question I have is that as you continue to move up the stack, one of the things that Google has done extraordinarily well is the global network. And we talked previously about how I run the snark.cloud URL shortener in Google Cloud. That is homed out of US Central 1 as far as regions go. stateless, it just talks to Google Sheets for its source of truth, but then just runs a Docker invocation on every request, cool. I can see a scenario in which that becomes much more of a

global service. In other words, if you can run that in POPs in every region around the world on some level, there's no downside from my perspective on doing that. What I'm wondering then as a result of that, is as you start seeing the evolution of services becoming more and more global instead of highly region-specific, does that change the way that we should be thinking, potentially, about carbon footprint and regional selection? Or is that too much of a niche edge case to really be top of radar right now? Oh, there are many things to talk about here. The first one is that you might be hinting at something that Google is already doing, which is location shifting of workloads in order to optimize power usage and, you know,

of course, carbon emissions. So Google itself is already doing that. For example, I guess to process YouTube videos that can be done not necessarily right away, and that can be done in the location in which, for example, the sun is shining. So there are some very interesting things that can be done if you allow the workloads to be run in not necessarily a specific region. Now, that being said, I think there are many other things that people consider when they pick a region. First, well, maybe they have some data locality constraints, right? This is very much the case in European countries where the data must stay in a given region by law. Second, well, maybe they care about the price. And as you probably know, the price of cloud providers is not the same in

every region. I've noticed that. And in fact, I was going to get into that as our next transition, but you just opened Pandora's box early. It's great to have the carbon-friendly indicator next to the region, but I also want number of dollar signs next to it as well. Like in AWS land, you have the tier one regions where everything is the lowest price. US East 1, US West 2, and a few others that escape me from time to time, where managed NAT gateways are really expensive. And then you go into some others and they get even more expensive somehow. Like talk about pushing the bounds of cloud economics. It's astonishing to me. Yes. And so I want that display on some level as a customer in many cases.

So there is price, there is carbon, but of course, you know, if you are serving web requests, there is probably also latency that you care about, right? Even if, for example, Finland is very low carbon, you might not host your workloads in Finland if you want to serve US customers. So in a sense, there are many dimensions to optimize when you pick a region. And I just sent you a link to something that I built, which is called Google Cloud Region Picker. It's basically a tool with three sliders. First one is carbon footprint. You tell us how much you care about that.

Hopefully, you put it to the right. The second one is lower price. So how much do you want the tool to optimize to lower your bill? And third one is latency. And then you tell us where your users are coming from and if you care about latency. Because some workloads are not subject to latency requirements. Like if you do batch jobs, well, that doesn't serve a user request.

So that can be done asynchronously at a later time or in a different place. And what this tool does is that it takes your inputs and it basically tells you which Google Cloud region is the best fit for you. And if you use it, you will see it has very small symbols like $3 for the most expensive regions, $1 for the least expensive ones, three leaves for the greenest regions

and zero leaves for the non-green one. This is awesome. A little bit disappointed that I hadn't seen this before. This is a thing of beauty. Yeah, again, done by me as a 20%. And, you know, the goal is to educate. Like, of course, it's way more complex. Like, you know that price optimization is way more complex than a slider.

But the goal of this tool is to educate and to give a first result. Like, okay, if you are in France and care about carbon, then go here. If you are in Oregon, go here. So many parameters that this tool helps you optimize in a very simple way. One of the challenges I think I get into when I look at this across the board is that you have a couple of very different ends on a confusing spectrum. By which I mean that one of the things I would care about from a region picker, for example, is, is there sufficient capacity in that region for the things I want to run? For my scale of things, we're right now on Google Cloud. I run a persistent VM that hangs out all the time, and I run. For my scale of things, we're right now on Google Cloud. I run a persistent VM that hangs out all the time

and I run some Google Cloud run stuff. Great. If you have capacity problems with either one of those, are you really a cloud? But then we have other folks who are spinning up tens or hundreds of thousands

of a very particular instance type in a very specific region. That's the sort of thing that requires a bit more in the way of capacity planning and the rest. So I have to imagine for those types of use cases, this tool is insufficient. I mean, the obvious reason, of course, if you're spinning up that much of anything, for God's sake, reach out and talk to your account manager before trying to do it willy-nilly. But yes. That's exactly right. So as as i said this tool is a simplified tool to give like the vast majority of users a sense of where to put their workloads but of course if you are a

very big enterprise customers going to sign a very big deal with google cloud talk to your account manager because if you do need a lot of capacity, Google Cloud might need to plan for it. And not every regions have the same capacity and we are always working with our customers to make sure we direct them in the right place and have enough capacity there. A real life example of a very high profile Google Cloud customer was that they were selecting a region without knowing its carbon impact. And when we started to disclose the carbon characteristics of Google Cloud Regions, which is another link we can send to the audience,

this customer realized that the region they selected, you know, maybe because it was close to their user base, was really not the most carbon-friendly. So they decided to switch to another one. And if we take an example, if you take Las Vegas, it has a carbon free energy percentage of 20%. So that basically means that on average, 20% of the time, the electricity comes from carbon free sources.

If you are to move to Oregon, this same workload, Oregon has a carbon-free energy percentage of 90%. So you can see how just by staying on the West Coast, moving from Las Vegas to Oregon, you have drastically reduced your carbon emissions. And your bill, by the way, because it turns out Oregon is one of the cheapest Google Cloud data center. So you see how just being aware of those numbers led some very important customers who care about sustainability to make some fundamental choices when it comes to the region they select. I guess that leads to my big obvious question where I wind up pulling up my own footprint in Google Cloud. Again, I don't run much there. And apparently over the last year, I've had something more carbon than that just searching Google for carbon-related questions about where to place things. So for my use case, this is entirely academic. You could almost run my workloads based upon, I don't know, burning baby seals or something.

An ecological footprint does not materially change. Then we go to the other extreme end of the spectrum with the hundreds of thousands of instances where this stuff absolutely makes a significant and massive difference. My question is, when should people begin thinking about the carbon footprint of their cloud workload? What point of scale? So as you said, a good order of magnitude is one transatlantic flight is a thousand kilogram of equivalent CO2.

So you see how just by flying once, you are already completely overshadowing your Google Cloud carbon footprint. But that's because you are not using a lot of Google Cloud resources. Overall, I think your question is basically the same as when should individuals try to optimize reducing their carbon footprint? And here I always recommend there are tons of things you can optimize. Start by the most impactful ones.

And impactful means an action will have a lot of impact in reducing the footprint, but also the footprint reduction will be significant by itself. And two kilograms of CO2, yes, indeed, it is very low. But if you start reaching out into the thousand of kilograms of CO2, that starts to represent like one flight, for example. So you should definitely care about it. And as I said, some actions might be rather easy, like picking the right region might be something you can do pretty easily for your business. And then you will see

your carbon emissions being divided by, you know, sometimes five. This episode is sponsored in part by our friends at Lambda Cloud. They offer GPU instances with pricing that's not only SCADs better than other cloud providers, but is also accessible and transparent. Also, check this out. They get a lot more granular in terms of what's available. AWS offers NVIDIA A100 GPUs on instances that only come in one size and cost $32 an hour. Lambda offers instances that offer those GPUs as single card instances for $1.10 an hour. That's 73% less per GPU. That doesn't require any long-term commitments or predicting what your usage is going to look like years down the road. So if you need GPUs, check out Lambda. In beta, they're offering 10 terabytes of free storage, and, this is key,

data ingress and egress are both free. Check them out at lambdalabs.com slash cloud. That's L-A-M-B-D-A-L-A-B-S dot com slash cloud. I want to challenge your assertion, incidentally. You say that I'm not using a whole lot of Google Cloud resources. I disagree. I use roughly a dozen different Google Cloud resources tied together for some of these things. But they're built on serverless design patterns, which means that they scale to nothing. I'm not sitting there with an idle VM except that one that is existing on a persistent basis. For example, I look at the things that show up on the top five list.

Compute Engine is number one, Cloud Run, Cloud Logging, Cloud Storage, and App Engine are the rest that are currently being used. I think there's a significant untold story around the idea of building in a serverless way for climate purposes. Yes, so maybe for those who are not aware of what you are seeing on the dashboard. So when you opened this Google Cloud Carbon Footprint tool on the cloud console,

you saw a breakdown of your yearly carbon footprint and monthly carbon footprint across a few dimensions. The first one is the regions, because as we said, this matters a lot, like the regions have a lot of impact. The second one are the month. Of course, you can see over time how you are trending. The third one is a concept called Google Cloud Project, which is, for those who are not aware, it's a way to group Google Cloud resources into buckets. And the third one is Google Cloud Services. So what you described here is which of your services emit the most and therefore which ones should you optimize first? Like, again, to go back to impactful actions. And to your point, yes, it is very interesting that if you use products which auto scale, basically the carbon attributed to you, the customer, will really follow this auto-scaling behavior.

Compare that to a virtual machine that is always on, burning some CPU for almost nothing because you have a server that doesn't process requests. That is wasting, in a sense, resources. So what you describe here is very interesting, which is basically the most optimized products you are going to pick, the less waste you are going to have. Now, I also want to be careful because comparing one CPU hour of Cloud Run

and one CPU hour of Compute Engine is not comparing apples to apples. Why? Because when you use Cloud Run, not sure if you know, but you are using a regional product. So a product which has built-in redundancy, which is safe if in case of one zone going down in a region.

So that means the Cloud Run infrastructure has to provision a little bit more machines than if it was a zonal product. While Compute Engine, your virtual machine, lives in one zone and there is only one machine for you. So you see how we should also be careful comparing products with other products, because fundamentally,

they are not offering the same value, and they are not running on the same infrastructure. But overall, I think you are correct to say that, you know, avoiding waste, using auto-scaling products is a good way to reduce your footprint. I do want to ask, and this is always a delicate topic because you're talking

about cultural things. How much headwind did you have internally at Google when you had the idea to start exposing this? How difficult was it to bring this to fruition? I think we are lucky that our leadership cares about reducing carbon emissions and understood that our customers needed our help to understand their cloud emissions. Like many customers before we had this tool, we are trying to cause some kind of estimate the cloud emissions. And it was, you know, Google cloud was a black box for them. They did not have access to what you said, to some data that only Google has access to. And to build that tool, we are using energy measurements of every machine in every data center. We are using

customer-wide resource usage. And that is something that we use to divide the footprint among customers. So there is some data used to compute those numbers that only Google Cloud has access to. And indeed, you're correct, it required some executive approval, which we received because many of our leaders believe that this is the right thing to do. And this is helping customers towards the same goal as Google, which is being net zero and carbon free. Many of our customers have made some commitments, some sustainability commitments, and they need our help to meet those goals. So yeah, we did receive approval first to share the per region characteristics. This was already a first in the industry where a cloud provider disclosed that not every region is equal and

some are emitting more carbon than others. And second, another approval, which was to disclose a per-customer carbon footprint, which is broken down by service, project, region, using some, you know, if you touch a little bit on the methodology, you know, it uses energy consumption, resource usage, and carbon intensity coming from a partner of us to compute basically a per-customer footprint. My question for you is, on some level, given that Google has already committed to being net zero across the board for all of its usage, why do customers care? Why should they care? Effectively, haven't you made that entirely something that is outside of their purview? You've solved the problem either way. This is where we should explore a little bit

more the kind of carbon emissions that exist. For a customer, their emissions linked to their cloud usage is all considered their indirect emissions. This, in the greenhouse gas protocol standard, this is called scope three. So our Google Cloud emissions are the customer's scope three emissions. They are all indirect for them. But those indirect emissions, what I mentioned is being net zero are the emissions coming from electricity usage.

So to power those data centers, those data centers are located in certain electricity grids. Those electricity grids might be using energy sources that emit more or less carbon, right? Simply put, if in a given place, the electricity comes from coal, this will be emitting a lot of carbon compared to when electricity comes from solar, for example.

So you see how the location itself determines the carbon intensity. And these are the emissions coming from electricity usage, right? So these are neutralized by Google purchasing as much renewable energy. But there are other types of emissions. For example, when a data center loses connection to the grid, we start up diesel generators. Those diesel generators will directly emit carbon. This is called scope one emissions. And finally, there is the carbon emissions that are coming from the manufacturing of those servers of those data centers. And this is called scope three emissions. And the goal of Google is for the emissions coming from electricity to be always coming

from carbon free sources. So this is a change that we've recently released to Google Cloud Carbon Footprint, which is now we also break down your emissions by scope. So they are all scope three for you, the customer. They are all indirect emissions for you, the customer. But now those indirect emissions, you can see how much is coming from diesel generators, how much is coming from electricity consumption, and how much is coming from manufacturing of the data center and other upstream downstream activities. And yeah, overall, this is something that customers do need to report on.

I think that's very fair. I do want to thank you for taking so much time to speak with me. And instead of the usual question I like to ask here, where can people go to find out more? Because we have a bunch of links for that. Instead, I want to ask something a little bit different here, which is what are the takeaways that customers or prospective customers should really have around their carbon footprint when it comes to cloud? I would recommend our audience to consider carbon emissions in your cloud infrastructure decisions. And my advice is, first, move to the cloud. Like we've talked that

Google Cloud has very well optimized data centers, like your cloud gross carbon emissions are anyway going to be much lower than any on-premise carbon emissions. And by the way, if you use Google Cloud, your net operational emissions are zero. Second action is pick the region with the lowest carbon impact. We discussed that this is probably a low effort action, if possible, that will have a lot of impact on your gross carbon emissions. And, you know, if you want to go further, try to schedule those workloads when the electricity is the greenest, you know, when the sun is shining, the wind is blowing, for example, or try to schedule those workloads in regions which have the lowest impact. And yeah, Google Cloud gives you all the tools to do that, the tools to optimize your region selection, and the tools to report and reduce your gross carbon emissions.

We haven't talked about it, but Google Cloud Carbon Footprint will even send you some proactive recommendations of things to do to reduce your emissions. For example, if you have a product, a machine that you've forgotten, Google Cloud Carbon Footprint

will recommend you to delete it and will tell you how much carbon you would save by deleting it as well as dollar of course. It's funny because I feel like there's a definite alignment between my view of cloud economics and the carbon perspective on this which is step

one. Everyone wins if you turn things off when you're not using them. What a concept. I sometimes try and take it too far. Turn off all of production because your company's terrible. Yeah, it turns out that doesn't work super well. But the idea of step one, turn it off, especially when you're not using it, and if you're never using it, why would you want to pay for it? That becomes a very clear win for everyone involved. I think that in the fullness of time, economics are what are going to move the needle on driving

further adoption about this. I have to guess that you see the same of time, economics are what are going to move the needle on driving further adoption about this. I have to guess that you see the same thing from where you are? Yes, very often working to reduce your carbon footprint is also working to reduce your bill. And we've also observed, not always, but some correlation between regions that have the lowest carbon impact and regions that are the cheapest. So in a sense, this region selection, optimizing for price and carbon, is often optimizing for the same thing. It's not always true, but it is often true. I really want to thank you for spending so much time to talk with me about this. This is

definitely giving me a lot of food for thought. And I have to imagine that this will not be our last conversation around the topic. Well, thanks for having me. And I'm very happy to talk in the podcast, of course. Staren Janimi, product lead for Google Cloud Carbon Footprint and Google Cloud Run. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry screed about how climate change isn't real as you sit there wondering why it's 120 degrees in March. If your AWS bill keeps rising and your blood pressure is doing the same, then you need

the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a humble pod production stay humble