Transcript
Bergman: Can green software engineering solve the climate crisis? This is a chart over the global atmospheric CO2 concentration since the year zero. I was born here at 359 parts per million. My parents were born at 320 parts per million, and any child born today will be born at 420 parts per million. That means that we already knew about climate change when I was born. In fact, we deemed it important enough to teach kids in primary school because I cannot remember a time in my life where I did not know about climate change. There is scientific consensus that the amount of greenhouse gases that humans are responsible for emitting into the atmosphere is causing our climate to rapidly change. That begs the question, can green software solve this?
Who am I and why am I talking about this? My name is Sara Bergman. I'm an individual contributor at The Green Software Foundation, where we work with questions around green software and minimizing the impacts of software on our environment. I am also a Senior Software Engineer at Microsoft where I work with Microsoft 365 products.
Why Talk About Climate Change?
Why is this a passion of mine? Why do I talk about it? Climate change has been a fact of life for all of my life, very likely for all of your lives, as well. I think for a lot of us, at least for me, standing by and doing nothing, putting my head in the sand was never really an option. I did a lot to take individual action in my private life. Then I realized that actually, even though I'm not a marine biologist, or not a climate engineer, or a researcher in the climate space, I still have an opportunity for impact at my workplace that is bigger than the opportunities for impact that I have in my private life. I started to learn more about green software, and on that path, I have continued, and that's where I am right now. Why should we talk about this? We've mentioned climate change a bit. Typically, a question that people ask, is software really something we should focus on here? Is that a worthwhile conversation to be having? Should we not be focusing on other parts of the problem? It seems like there are transportation problems, or the fashion industry maybe have a higher impact or more important.
Global Trends in Digital and Energy Indicators, 2015 - 2021
There are several studies around this actually. Here's one, which I've linked here. Basically, what this paper found that if unchecked, the ICT's greenhouse gas emissions, their relative contribution would grow from roughly 1% to 2% in 2007, to exceeding 14% of 2016 levels of worldwide greenhouse gas emissions by 2040. That means that the ICT, so the Information Communication Technology sector, we will account for more than half of the current relative contribution of the whole transportation sector. That's saying quite a lot because we do talk about transportation quite a lot. We talk about aviation. We talk about eating local, all those things. Actually, we are trending in the direction of being half the size of transportation. There are also some global trends in digital and energy indicators, this is from a paper from EIA. We can also see that there is work going on here. We are focusing on things like efficiency. For example, if we take a look at this, so the data center workload from just the past 3 years, so from 2015 to 2021, increased by 260%, which is a very big increase in data center workloads. Energy use did not increase that much, it just only increased 10% to 60%. That's, of course, largely supported by the move to these hyperscale clouds, to better hardware, to some extent, and to increased focus on being efficient with how we run our workloads. If we look at internet traffic, which is another major contributor to the ICT sector in general, something we maybe talk even less about on the data center side, the data transmission network. From 2015 to 2021, the surge in traffic which was, of course, largely supported by some major world events in 2020, increased by over 400%, which is quite a lot. The data transmission network use did not increase 400%. Instead, it just only increased 20% to 60%. A part of that is because we tend to overprovision how much energy our networks require. Part of this is because we have invested significant effort into making this more efficient. Of course, there are other sides of the ICT industry where we are not really having these efficiency gains. If we look at crypto for example, the amount of energy we use for crypto mining increased by 2000% to 3000%, during this 6-year time period.
Energy and Policy Considerations for Deep learning in NLP
Another interesting trend to look at is machine learning, and specifically these large language models or natural language processing. This paper now is a few years old, it's from 2019, it's from Strubell, McCallum, and Ganesh. I think it's a really good paper, so even if it's a little old, it's well worth a read. This is one of their splashiest findings from this paper. What they did was that they characterized the dollar cost in carbon emissions of training popular, what they call off-the-shelf NLP models. One of them which is, to be said, a quite expensive one to train, is this transformer renewal architectural search. Just training that, so excluding all other parts of the machine learning lifecycle, it costs five times the carbon of an American car. That's quite significant. For more everyday examples, the cost is not as high, it's lower. What they successfully showed in this paper is that machine learning does have a big impact of how much carbon that we're spending in our software. I think it's an interesting example to look at.
Carbon Footprint vs. Carbon Handprint
We talked a little bit about what we call the carbon footprint of software. The carbon footprint is basically an estimation of the size of the impact of your actions on the climate. That could be of any entity. That could be of a person. That could be of software. That could be of business entity, really anything. I think we're mostly familiar with its terminology. Something that I see used not as often, but I quite like this terminology so I'm going to use it, is the carbon handprint. The carbon handprint is the opposite of a carbon footprint, where it recognizes the actions that you take that have a positive impact on climate. Over and above reducing your carbon footprint which we should all strive to do, then you can also maximize your carbon handprint. If you do enough of these actions, maybe they will even outweigh the size of your carbon footprint. Because of course, software can be an enabler of climate solutions. To talk a bit about that, I'd like to use this terminology. We can talk about green software. Green software is going to be the topic of this talk. That has to do with the carbon footprint. Basically, how do we minimize the negative effects of software on our climate? Green by software, on the other hand, means that software can be an enabler of climate solutions because software can of course be built to help accelerate the decarbonization of all sectors and all industries and society. Of course, we need people to focus on this and on both aspects, of how to make software greener, and how to make green enabling software, which is very interesting and a very worthy cause.
It is, however, not the topic of this talk. The topic of this talk is this, minimizing the negative effects of software on our climate. It's not only the topic of this talk, it's also the mission of The Green Software Foundation. Because we want software to become a part of the climate solution, rather than being part of a climate problem. I think that's something if we go back to instinct, and motivation, something we can all feel aligned with. I think it's very motivating to work to be part of a solution of something rather than the problem. In The Green Software Foundation, we are focused on reducing the negative impact of software on our climate by reducing the carbon emissions that software is responsible for emitting. Our primary focus is to create this ecosystem for developing green software.
Green Software Foundation - Our Theory of Change
Let's talk a bit about our theory of change. Like I said, our mission is to change how we build software, so that there are zero harmful environmental effects of software. Our vision is to do this by creating this trusted ecosystem of people, standards, tooling, and best practices for creating and building green software. We trust the ecosystem. Why is that so important? I think it's great that there are individual organizations and people and academia around there who are contributing to this course. That's something we, by all means, should continue with. For some things, it's really great if we can come together as an industry and say, this is something we all stand behind. The Green Software Foundation is beneath the Linux Foundation, so they're very rigid ways of coming to a decision on anything that we publish. That means that if we publish something, that means every member organization stands behind it. I personally think that's very powerful, because more people, just better. Anything is better the more people who had a chance to contribute to it and say what they think. Who do we serve? We primarily serve software practitioners, note that I'm not saying engineers or data scientists. There are a lot of people who are involved in the process of creating software, and those are the people that we serve primarily. Secondarily, it's leaders, policymakers, students, and anyone in a software adjacent role.
Green Software Fundamentals
For the rest of this session, we're going to take our footing, our foundation in this circle. We're going to start talking about some principles, then we're going to dive into the SCI specification. SCI stands for software carbon intensity. That means I'm going to get into all of that. Then we're going to end to talk about some patterns.
Principles
Some principles first. Then that begs the question, what makes software green? We have a terminology called carbon efficiency. Carbon efficiency means we emit the least amount of carbon possible. This comes with three under categories. I want to dive into each of these four in more detail. First is carbon efficient, the overarching umbrella term. Everything emits carbon into the atmosphere. We breathe, we emit carbon. It's a fact of life. For software to be green, we need to extract the maximum amount of value out of every single gram of carbon that is emitted into the atmosphere. Let's just take a step back and really think about what I mean by carbon. Because at least in my native language, we don't say carbon when we mean carbon dioxide, because carbon is the same word as for coal. That will be super confusing. In English, we tend to say carbon when we actually mean carbon dioxide equivalent. What carbon dioxide equivalents are is basically a mapping from all the greenhouse gases. We know that there are a lot of greenhouse gases, not just carbon dioxide, and how they affect the atmosphere and how long they last and their global warming potential is different. We don't necessarily want to reason over that when we build software. It's already a lot to take in. Luckily for us, there are some very smart people who have created this conversion into carbon dioxide equivalent. That is what we use, so that we can have one metric to reason over all different greenhouse gases. The goal here is that we want to be efficient with carbon, with carbon dioxide equivalent. We want to emit as little as we possibly can. This will likely never be zero just for the nature of software work. We can always hope, but I have a hard time seeing that we will find a way to build servers that don't include mining and transportation and energy-intensive assembly of hardware, for example, or that we will run them on anything else but electricity. The least amount possible is the key word here.
There are four under categories on how we do this. The first is energy efficiency. Consume the least amount of electricity possible. If you start thinking about this for the first time, it's likely the first thing you're going to think about. It makes sense. Especially if you've been living in Europe the past year, when we lived through this energy crisis, this is likely something you have started thinking about more, how much electricity do you consume, and the cost of that? The first principle is to consume the least amount of electricity as possible, because the way electricity is generated creates different emissions depending on how we are creating it. We'll go into that a bit more. No energy is for free. Being energy efficient is our first principle.
The second one is hardware efficiency: use the least amount of embodied carbon as possible. If this is the first time thinking about carbon efficiency, and you're like a software-software type of person, this might feel like, no, this is not my problem. I have some data center people or some asset management people who take care of this for me, and I just run my software. That's all well and good. Actually, there are a lot of things that we can do on the software side to be more efficient with the way we use our software. When I go into the patterns, I'm hopefully going to explain that in a bit more detail, or at least with some examples. Embodied carbon, that's another new word. Let's dive into what that means. Any physical object that we create releases carbon into the atmosphere during its creation and destruction. For servers, for example, we mine the materials, we ship them somewhere, and we produce them in some way. At QCon, there was a great keynote called, "The Future of Microprocessors," by Sophie Wilson. I thought it was fascinating because she explained how processors are created. It's an incredibly energy-intense process, because obviously we're making chips smaller, and to fit the atoms where we need them, it's more precise work. That makes sense, but I hadn't really reflected on that until that keynote. I highly recommend it. This is not only true for processors, there are many parts of a server that is quite energy intense, or quite intense in either the mining process because the metals are so rare, or the recycling process because we are making devices harder to recycle. Servers are very expensive in terms of embodied carbon. Of course, a wooden chair also has embodied carbon, but significantly less. That's why it is very important for us to think critically about how we use hardware. I know I said servers a lot, but of course this applies to end user devices like laptops or phones as well.
Our next principle is carbon-aware computing: do more when the electricity is clean, and do less when the electricity is dirty. I mentioned previously that not all energy is created equally. Again, this is probably something many of you maybe knew from before, or at least started reflecting on the past year, if you lived in Europe and seen the energy prices go up and down. I live in Norway. Here we have hydro and we have an excess of hydro, so we export. That means that no matter when I consume electricity, it's going to be from hydro. The carbon intensity is going to be the same. That isn't really true for most grids around the world. In fact, they fluctuate over time of day, and this also fluctuates inside a country, at least a region if you go a bit broader. There are some very high carbon intense sources like coal or gas, and there are other ones that are low carbon or that are even renewable. As software engineers, we can make use of this fluctuation in the grid. In times of day or even in regions where the carbon intensity is lower, we can make use of that and do more. We can do on-demand tasks, for example, and make use of how that can work, which is, I think, quite cool, a bit tricky the first time you think about it. Again, I'm going to show some examples to make you understand a bit more what we can do here.
That helps one with just consuming electricity that has a lower carbon intensity, but also, it helps with energy transition. Because there's something really cool happening right now where grids all over the world are moving from these high-carbon sources like coal, to these low-carbon sources like solar, wind, and nuclear. I know saying nuclear as some positive energy producer can be controversial for some, but I'm going to refer to it as a low-carbon source, because it does emit a lot less carbon than things like coal or gas, for example. This shift that is happening is called the energy transition. We needed the energy transition to happen before I was born. We needed it yesterday, but we can't have that. We will have to settle for as fast as possible. One of the ways that we can help this is actually to do more when there is green energy available. Here, again, is where things get a bit tricky. Normally, as a software engineer, you wouldn't calculate these signals or metrics yourself. You would rely on some external provider to calculate this number for you so that you can have a single thing, high or low-carbon intensity. Because you want something that is going to affect the grid now, but also that over time is going to help this energy transition, so that we, over time, support the build and production of more low-carbon sources. Again, a bit complicated, but let's just say that spending energy when there are many renewables or low-carbon sources on the grid, helps the energy transition because more money goes into those lower-carbon plants. We do have an article on The Green Software Foundation website called, "The Grid Beneath the Internet," where you can read more if you thought that this was really interesting. The third principle is to be carbon aware: do more when the carbon intensity is lower and do less when the carbon intensity is high.
SCI Specification
We're back to our little wheel. We went through some of the principles. Let's talk a bit about specifications, or the SCI specification in general. Measuring. It's really hard to improve something if you cannot measure it. I think a lot of time we in the software industry are quite obsessed with charts, and graphs, and understanding where something comes from and how we can manipulate it, and what we can do. I'm not sure if that has to do with the intangible nature of software. It's rarely something that we see and touch. Or maybe this is just like a builder's thing, anyone who builds anything ever, like psychometrics describes. What I want to say here is that typically, in the past, also in the present, we have measured the carbon footprint of something as a total. The total is great, but it's only one metric to describe the state of something. To make the right decision, it might not be the only metric that is sufficient. Say you are the leader of an organization, and your task is to reduce the carbon emissions of your software. You measure the total in Q1, and it's like 35 tons. Then you invest in products, you try to eliminate these emissions, and by Q2, the emissions have actually increased to 52 tons. That does not look very good for your performance review. Did your investments pay off? Did your project succeed? Should you continue doing those? A total by itself doesn't really tell you, it doesn't tell the whole story here. We might need other metrics to help describe what is going on here. If we instead only look at the total, a total is final, and that might inform one set of decisions. If we also looked at the carbon intensity, we might see another perspective of what's happening. Say we measured a carbon intensity as a rate of carbon equivalents per user. We say that in Q1, it was 3.5 grams, and then we measured in Q2 and it was now 2.9 grams. That means that we have reduced. Our totals had, carbon emissions are increasing, and that informs one set of decisions, but the carbon intensity of your software has decreased and that informs your choices to eliminate emissions are working. It's best to continue in that direction to gain even further reductions.
How do you get this type of rate then? We have the software carbon intensity specification or the SCI. The SCI is a rate of carbon emissions, it's not a total. It's better the lower you have, but you can never reach zero. Zero is impossible, but lower is better. The equation consists of four key parts. The first is the energy consumed by the software in kilowatt hours. That's the E that we're seeing. Then you multiply that with the carbon emitted per kilowatt hours of energy, so the carbon intensity, and that is the location-based marginal carbon intensity. Basically, who, when, and where did you consume this energy. That's the location-based part of it. To this, you add the M, so the carbon that was emitted through the hardware that your software is running off of. Then you take all of this total C per R, where R is a functional unit. It describes how your software scales. For example, this can be per user, or this can be per device, anything that really makes sense to your application. The goal of this study can be used at any stage of software development. It can be used in the design phase. It can be used in maintenance or in active development. We want you to measure it, or to use it, measure it, change something and measure again and see what happened. Did it go up? Did it go down? Was it a good decision, or was it a bad decision? It's heavily biased towards action. You can see that it's very clearly connected to the principles we talked about before. It's because we want you to act based on this. It's not primarily meant for reporting, even though you should report on it, or can at least report on it. It's meant to inspire people to do something.
I said, measure a lot. The goal of the SCI is to quantify how much carbon or C is emitted per one unit of R, your functional unit, API calls you serve, device, whatever it is. There are two main methods of quantifying the carbon emissions. You can indeed do measurements via real-world data, or you can do calculations via models. Measurement is basically measuring the total real-world carbon emissions of whatever component you are looking at, and then dividing it by the total number of functional units. For example, you can have data regarding real-world usage of the application in the wild. That you may measure and then you divide it by, let's say the total number of users serviced, or the total number of devices used in that same period, to get C per user or C per device. That's all well and good, but sometimes you might not be able to do this. For example, if your software runs on client end devices, measuring all of this might in fact use more carbon than what you would save by gaining this insight. Instead, you can calculate it. Then what one unit of R looks like is modeled, and the total carbon, so C, is calculated for executing one functional unit of work in a controlled lab environment. For example, you have a benchmark application, and that is created, that models the user interacting with your application, and then you measure C emitted per run of that benchmark. The result then will be C per user as well. Both these options are perfectly allowed. If you want to learn more, I recommend checking out the full specification of the SCI, which I have linked in the end.
There are some core characteristics of the SCI which will stay the same when it develops, because they will develop. It was first released for COP26. Then we released the v1 version in the fall for COP27. These are the core characteristics. Firstly, SCI is sensitive to carbon awareness, energy efficiency, and hardware efficiency that we just talked about. The SCI also take a systems impact view. What does that mean? That means that your software boundary needs to consider the entire system that makes sense to your use case. Because if you're doing a low-level transition over here, that may lead to some micro improvements which make you look really good, and have an amazing performance review. Actually, it has negative downstream effects at the macro level over here or over here, by those actions, and maybe even negate the things that you improved here. Taking the system-wide view is very important. The SCI should also be easy to implement. You should not need to take a certification or a course. Anyone who knows their own software should be able to do it. We encourage the use of granular data simply because it gives you the opportunity to take action. That's the goal. If you have more information, you can take better action. Of course, that's not always possible, so I think annual values is the lowest acceptable level of granularity. Again, go read the full specification if you really want to get into the nitty-gritties here. Also, I think it's worth mentioning exclusions, because, again, actions, and only actions that eliminate your emission will reduce the SCI score. The SCI score cannot be reduced by a carbon offset such as market-based reductions. Why is that? It muddies the pictures. If you're trying to act on something as a software practitioner, and you see a decrease, how would you know if that's because of market-based reductions or carbon offsets, or if it's because of things you did. Makes it harder to know. It also is because the goals we have set as a community, they are actually about reductions and eliminations not about offsets.
Let's dive into that a bit more. There are many paths to zero. If we have our emissions here to the left, and we say we want to reduce them by 50%, we can do that in different ways. You can actually eliminate something or you can offset it, which is the middle pillar, or compensate it. Often, we conflate these two to mean the same thing. They don't really on a global scale, and the goals we have set as a community, not just the software community, but as a worldwide community for 2030 and for 2050, they are about reductions. They are not about neutralizations, because neutralizations are not permanent, but emissions are. Net-zero, which we're still lacking a global standard for, but they are about elimination. Some say eliminate 90%. Some say, eliminate as much as you can, and then neutralize the rest. The SCI can be a tool for you to reach net-zero.
Patterns
We made it through two parts of the wheel, and now we have our last part, the patterns. The Green Software Patterns Catalog is a catalog of best practices for building green software. Any pattern that we published have been verified by subject matter experts in The Green Software Foundation. Before we publish them, they are, of course, agreed via consensus by all member organizations. The goal is that if you apply any of these patterns to your software, they will reduce your emissions. Of course, it's not a complete catalog. In fact, you can submit patterns to it if you have something that you think we are missing. Not everyone will agree even though we have agreed as the member organizations, but you might have patterns that work even better for your organization. Please continue to help us improve this. We would love to have your contribution. I'm going to go through some of the example patterns to show how the patterns can look, and also to show how the principles that we talked about, the SCI, and this all comes together. Yes, maybe give you some inspirations for things that you can try out on your own software.
First, I wanted to show something that affects the M, so the embodied carbon. The pattern here is to delete unused storage resources. From an embodied carbon perspective, again, all the carbon that we spent building and hopefully recycling, and removing a device, it's called embodied carbon. From that perspective, it's better to delete unused storage resources so that we are efficient with the hardware that we have, and so that the storage level is optimized for your task. The solution is simple, delete any unused storage resources. If you reduce the total amount of storage volume that you require, the total embodied carbon goes down. We tend to think of storage as cheap. It's definitely not the most energy intensive hardware that we have, but it does come with an embodied carbon cost. This does not affect the performance of your software in any way. I recommend applying all of these patterns if they make sense to you, and you can, of course.
The next pattern is matching utilization requirements with pre-configured service. This pattern is specifically for people running in the cloud. The description here is that it's better to have one virtual machine that's running at a higher utilization than to have two virtual machines running at a low utilization. Not only in terms of energy proportionality, but also in terms of embodied carbon. Because two servers that run at a low utilization rate, they will consume more energy than one running at a high utilization rate. In addition, this unused capacity of these underutilized servers could actually be used more efficiently for another task or another process. One of the benefits of the cloud is that you can autoscale to meet your peak demand, but if you're constantly asking for virtual machines that are larger than what you need, you're preventing the cloud provider from packing the virtual machines on the fiscal hardware as efficiently as they could. Because, yes, moving to the cloud is generally a good thing for being more efficient with your hardware. It does require you to do your bit as well. The solution is to right-size your machine by selecting the pre-configured server that matches the utilization requirements of your process better. This pattern affects both the E and the M, so by reducing the total numbers of servers required to run this process, the total embodied carbon is lower. It also affects the energy that you need because of the energy proportionality of how servers work. Servers consume a static power draw just by being switched on when they're serving no data or no workload whatsoever.
Next pattern has to do with the I of the SCI, and that's time shifting Kubernetes cron jobs. Like we talked about for a while now, the carbon emissions of a software system depends on the power consumed by the software. It also depends on the carbon intensity of the electricity that's powered on, so this fluctuation of the grid in time and space. For this reason, running energy efficient software on carbon intensive grids might be ineffective in reducing the global carbon emissions. Kubernetes have these recurring jobs, ML training jobs, batch job, things like that, and they can be implemented as cron jobs, which is pretty cool. What you can do is actually shift these in time by using a carbon intensity forecast data to calculate the best time in the future to execute this job. Because a lot of these jobs, they are important, but they're not urgent. That means you can wait a little. How long you can wait is up to you and your use case, but they're rarely so urgent that you need to run them right now. They are a great candidate for this type of shifting. That reduces the SCI, because you've not really changed much in your software, it's just a scheduling thing. Your E and M will stay the same, but your I, your carbon intensity will help reduce your score.
Actually, there's already plenty of examples of services doing this in the wild right now. For example, Windows 11 update, they will schedule update installations at specific time of day when doing so results in lower carbon emissions. Xbox, they recently had a very similar announcement, they will make updates and game downloads also carbon aware. iPhone and Apple have something that they call clean energy charging. When you enable this and you connect your iPhone to a charger, your iPhone gets a forecast of the carbon emissions in your local grid wherever you are, and then it uses it to charge your iPhone during cleaner energy production. I think these are really cool examples where you're not compromising with the user experience at all. It doesn't matter for me if my Xbox wakes up and installs at 2 a.m. or at 5 a.m. If you can do this and also save some carbon, I am delighted.
Lessons Learned
Software and climate was the topic of this talk. What have we learned? We learned that software does have a role to play when it comes to climate change, and specifically when it comes to climate solution, but what role it plays, that is completely up to us. We have learned that you can use the green software carbon intensity specification to assess the carbon score of your product. We've also learned that there are already research and techniques available to you to reduce your carbon footprints.
Green Software for Practitioners (LFC 131)
I also want to recommend, if you thought this was interesting, but you would like to dive in further and get a bit more out of it, take the Green Software Practitioner course. It's under the Linux Foundation. It's an introductory course assigned for software practitioners, and it will teach you how to apply green software principles to the design and development of your software application. I recommend it. I think it's quite good.
See more presentations with transcripts
