BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles How to Fight Climate Change as a Software Engineer

How to Fight Climate Change as a Software Engineer

Key Takeaways

  •  Software has an impact on climate change and we as software engineers can make a difference. By keeping the created carbon emissions in mind and doing what is possible to reduce carbon emissions caused by software, we can contribute to the fight against climate change.
  • Waiting for data centers to fully run on renewable energy is not enough and will take too long. We need to decrease the amount of energy that software consumes, in addition to increasing the amount of renewable energy that powers the data centers in order to speed up this transition.
  • Huge amounts of energy are wasted every day by software blocking space and consuming energy at data centers without being used most of the time. We need to consequently scale software down to zero and remove unused deployments from data centers.
  • It is worth taking a look at the actual resource consumption of software; efforts to reduce this resource consumption pay off in terms of lower energy and hardware consumption. The impact looks small initially, but scaling effects turn it into significant numbers.
  • Take the carbon intensity into account when choosing a data center or public cloud region - the carbon emissions caused by a data center can vary a lot when running the exact same workload. Choosing a region with lower carbon intensity helps quite a bit to run your workload with less carbon emissions.

We need to reduce and eliminate greenhouse gas emissions in order to stop climate change. There is no way around this. But what is the role that software plays here? And what can we - as software engineers - do about this? Let’s take a look under the hood to uncover the relationship between greenhouse gas emissions and software, learn about the impact that we can have, and identify concrete ways to reduce those emissions on a day-to-day basis when creating and running software.

Software is everywhere. We use software all the time. There are probably millions of lines of software running in your pocket, on your smartphone, all the time. There are millions of lines of software running on devices all around us, and there are trillions of lines of software running in data centers around the globe that we use every day, every hour. You can’t make a phone call anymore without huge amounts of software being involved, you can’t buy your groceries at the store or use your bank account without software being involved.

If you look behind the scenes of all this software, you will find huge amounts of greenhouse gas emissions - the driving factor of climate change - being produced and emitted to the atmosphere in this process, caused by a variety of activities around software. The hardware that is used to run the software needs to be produced, the data center that runs the software needs to be powered with energy, needs to be cooled, data needs to be transferred over the network, and so on. The more you look into the details of software, the more aspects you identify that cause greenhouse gas emissions - directly or indirectly.

As an example, we can look into data centers that run huge amounts of software every second. We know that the total energy consumption of data centers around the globe is significant - and will increase even further in the future. We are talking here about something in the range of maybe 10% of the energy produced on the entire planet being consumed by data centers in the near future. This is huge. And it is only one of many aspects here.

Energy is a key factor

Energy production is still a major driver of greenhouse gas emissions. Even if you hear slogans of “we use 100% renewable energy”, this usually doesn’t mean that your data center really runs on renewable energy all the time. It typically means that the provider buys (or produces) renewable energy in the same amount as the data center uses over a period of time.

Unfortunately the energy consumption of a data center doesn’t align with the energy production from renewable sources all the time. Sometimes more renewable energy is being produced than consumed by the data center, but sometimes the opposite happens: the data center needs more energy than is currently available from renewable sources. In those situations, the data center depends on the energy grid to fill in the gaps. And consuming energy from the grid means to depend on the energy mix that is available on the grid at that moment. The exact mix heavily depends on the country, the location within the country, and the exact time. But in almost all cases this mix includes energy being produced from emitting CO2 into the atmosphere (largely from burning coal, gas, and oil).

The companies who operate large data centers try to avoid this situation, for example by locating the data centers in locations with cool weather conditions (like Finland), so that less energy is needed for cooling. Or they locate data centers close to renewable energy production sites like windparks or hydro-based power stations. But running a data center on renewable energy all the time is still a huge challenge. We will get there, but it will take a long time.

The good news is that we as software engineers can help to accelerate this transition.

What can we do?

There are basically four fundamental things that we as software engineers can keep an eye on to accelerate the transition to run all our software on 100% renewable energy all the time:

  • Delete workloads that are no longer used
  • Run workloads only when necessary
  • Move workloads to a low carbon location and time
  • Use fewer resources for your workload

Delete workloads that are no longer used

Sometimes we allocate resources at a data center for a certain workload, we deploy and run the workload, and then, we forget that this workload exists, that the workload silently continues to run, and blocks allocated resources from being used elsewhere. Studies have revealed that these so-called “zombies” are a real problem. Jonathan Koomey and Jon Taylor revealed in their analysis of real-world data centers (Zombie/Comatose Server Redux) that between 1/4 to 1/3 of all running workloads are zombies: they are completely unused and non-active, but they block allocated resources and therefore consume significant amounts of energy.

We need to clean up our data centers from these zombies. That alone could help reduce the energy consumption significantly. Unfortunately, we don’t have the tools yet to automatically identify zombie workloads in data centers or on public clouds. Beyond the fact that this is a huge opportunity for new and innovative projects in this space, we need to help ourselves in the meantime and manually identify those zombie workloads.

The simple first step is, of course, to manually walk through all the running workloads to see if we immediately see a workload that we forgot about and/or that doesn’t need to run anymore. Sounds trivial? Maybe. But this usually surfaces surprisingly many zombie workloads already. So doing this little annual (or monthly, or weekly) stock-taking and removing those unused workloads already makes a difference.

In addition to that, we can use regular observability tools for this job and look at usage numbers. The number of HTTP requests or the monitoring of the CPU activity are good examples of metrics to manually look at for a period of time to see if a workload is really used or not.

Run workloads only when necessary

Another interesting outcome of the study mentioned above is that, beyond zombie workloads, there is a large amount of workloads that are not being used most of the time. Their usage is not at zero (like zombie workloads are), but at a very low frequency. The cohort that the study discussed were workloads that were active for less than 5% of the time. Interestingly, this cohort counted for roughly another 1/3 of all analysed workloads.

When looking at those workloads, we need to keep in mind that having those workloads deployed and running consumes energy 100% of the time. The amount of energy that non-active workloads consume is definitely less than the same workload being used at 100% (due to energy saving technologies being applied at the microprocessor level, for example), but the total energy consumption that is related to the workload is still significant (probably something around 50% of the energy consumption when running under load). The ultimate goal here is to shutdown those workloads entirely when they are not used.

This is something that software architects and software engineers need to take into account when designing and writing software. The software needs to be able to startup quickly, on-demand, and needs to be capable of running in many possibly very short cycles - instead of a more classical server architecture that was built for server applications running for a very long time.

The immediate example that comes to mind are serverless architectures, allowing microservices to startup fast and run only on demand. So this is nothing that we can easily apply to many existing workloads right away, but we can keep this option in mind when writing or designing new or refactoring existing software.

Move workloads to a low carbon location and time

One of the challenges of powering data centers with renewable energy is the fact that renewable energy production is usually not at a constant level. The sun doesn’t shine all the time and the wind doesn’t blow all the time with the same intensity. This is one of the reasons why it is so hard to align the power consumption of data centers with the power produced from renewable sources.

Whether the data center produces renewable energy on-site or consumes energy from the grid while purchasing green energy somewhere else doesn’t really make a big difference with regards to this specific problem: each data center has different characteristics with regards to the energy mix it consumes during the day.

Fortunately, we can help this situation by moving workloads around in two dimensions: space and time. In case workloads need to run at a specific moment (or all the time), we can choose the data center with the best energy mix available. Some cloud providers already allow some insights into this, giving you an overview on the regions and their level of green energy. Others do not (yet), but you should ask for it. This is important data that should influence the decision of where to run workloads.

The second dimension here is time: renewable energy is not available at a constant level. There are times when more renewable energy is available and can power all the workloads, whereas there are other times when not enough green energy is around. If we can adjust the timing of when we run the software (for example for batch jobs or software that runs only periodically), we can take the amount of renewable energy into account when deciding when to run it.

Both adjustments - space and time - are hard to do manually, especially since we don’t have the right tools available yet. But the clouds and data centers will move into this direction and automate this - it seems obvious that cloud and data centers will be moving workloads around for you and automatically shift them to a low-carbon data center all the time. The same will happen for software that runs only periodically.

Keep this in mind when writing software and see if you can deploy your software in a way that allows the data center to move it around within certain boundaries or conditions. It helps data centers to adjust the load depending on the carbon intensity of the available power and therefore reduce carbon emissions.

Use fewer resources for your workloads

The last chapter of these various efforts is to use as few resources as possible when running the software. The rule of thumb for software engineers that I found during my studies for this purpose is to “try to run your software with less hardware.” Most of the other, more detailed suggestions and guiding principles can be derived from this simple rule of thumb.

Let’s assume you run your software in a containerized environment like Kubernetes. When running the workload, you define the resource requirements for your workload, so that kubernetes can find a place on a node of your cluster that has enough free space to schedule your workload within the constraints you defined. Whether your software actually uses those defined resources or not doesn’t really matter that much. The resources are reserved for your workload. They consume energy - even if those resources are not used by your workload. Reducing the resource requirements of your workload means to consume less energy and might even lead to more workloads being able to run on the node, which - in the end - even means to have lower hardware requirements for your cluster in total - and therefore less carbon emissions from hardware production, hardware upgrades, cooling of the machines, and powering them with energy.

Sometimes talking about using fewer resources for a workload sounds like talking about tiny little bits and pieces that don’t change the game, that don’t move the needle in the overall picture. But that is not true.

If we talk about small wattage numbers for memory or CPUs running in idle mode, those numbers sum up pretty quickly. Think about how easy it is to scale your software. You can scale it up to multiple, maybe hundreds or even thousands of instances running in the cloud. Your wattage numbers increase in the same way. Don’t forget that. When we talk about saving 100 Watts of CPU consumption for your application because you can deploy it on an instance with only four cores instead of six, it sounds small. But when we scale this application to 100 instances, it means saving 100 Watts per instance * 100 instances = 10000 Watts. Suddenly that is a lot. If we do this for every application that we run in the cloud or our own data center, energy consumption gets reduced quite a bit.

But we need to change our mindset for this. Sometimes we find ourselves thinking in the opposite direction: “Let's better give the application a bit more memory to make sure everything goes fine, to make sure we have a buffer, just in case…” We need to rethink that and change our perspective into the opposite direction. The question in our mind should be: “Can we run this application with less memory?”, or “Can we run this application with less CPU?”, or both.

Defining and running realistic load tests in an automated way can help here. The environments for those load tests can be defined with the new perspective in mind by reducing the available resources step by step. Watching the resource consumption using regular profiling and observability tools can surface the necessary data to find out when and why resource limits are hit - and where we need to optimise the software to consume less.

Unfortunately, we don’t have all the tools yet to directly observe and measure the energy consumption of individual workloads or the carbon emissions caused by the consumed energy. A lot of research is going on in this space and I am sure that we will get direct visibility into the energy consumption and carbon intensity of individual workloads in data centers in the future.

Energy consumption as a differentiating factor

Not every software is equal with regards to carbon emissions that are caused by that software. We can’t hide or ignore this. And people will want to know this. Users and customers will want to know about the impact that the software that they use has on climate change. And they will compare software with each other with regards to this impact, for example, the “carbon intensity” of a software. Most likely software with a much lower carbon intensity will be much more successful in the future than software with a higher one. This is what I mean with “it will be an important differentiating factor”. The carbon intensity of software will drive decision-making. So as someone writing or selling software, you better prepare for this sooner rather than later.

Unfortunately, there is no common ground or established practice yet for how to measure the carbon intensity of software - at least not yet. The Green Software Foundation is working on a specification for this - which is an important step in the right direction. Nevertheless, this is still far away from measuring the actual impact of a concrete piece of software in a practical (and maybe even automated) way.

Other work is in progress here. We will see platform providers (like cloud providers or virtualization platforms) surface data about energy consumption and related carbon emissions more transparently to the user, so that you can see real numbers and see trends of those numbers over time. This will provide an important feedback loop for developers, so that they will be able to see how their workloads behave over time with regards to carbon emissions.

And I very much hope that cloud providers and data center operators will provide more insights and real-time data into their energy usage, the energy mix, and the carbon emissions when running workloads on their clouds. This will be an important data point for engineers to take into account when deciding where to run the workload.

Conclusion

We all know that, in order to fight climate change and in order to create a sustainable future, we need to decarbonize the entire world of software engineering and software. There is no way around this. Everybody knows that. And everybody needs to start contributing to this effort.

Additional resources

About the Author

Rate this Article

Adoption
Style

BT