Introduction

Sustainability is an important topic these days and, in many fields, people are trying to find more sustainable solutions for their current processes or products. So of course, for software engineers, software architects and people in IT-operations, there are a lot of tips and possibilities. In this blog post I will give you a short overview in the form of a checklist.

Some Green IT-tips are well-known best-practices for which sustainability is merely an additional pro-argument, some are only yet emerging and work-in-progress. Some might need a lot of consideration or involve tradeoffs – but some might be easily implementable in your project(s) without entailing any major disadvantages.

So let’s see what there is to discover 😛

What is Green IT?

Green IT means reducing the amount of carbon emitted by running software and using hardware.

One can do that by making software more…

… energy efficient (CPU, RAM, network and storage usage, which seem like abstract numbers on your dashboard, all consume a certain amount of energy, even when idle)
… hardware efficient (use as little hardware as possible, as manufacturing hardware has a bigger share in IT-emissions than one would think. For a laptop, around 80% of carbon emitted is from manufacturing and only 20% is from use over a three-year lifetime)
… carbon aware (running software at a time and place where the percentage of renewable energies in the grid is high)

For a lot more detailed information and info graphics, see: Introduction | Learn Green Software

Green IT Checklist

During my research in the last weeks I collected the following tips on how to make IT-systems more sustainable:

1. Requirements Engineering:

evaluating the importance of sustainability to the customer:
- clarifying in the beginning how much value a customer-company places on sustainability and explaining what possibilities exist for this specific IT-system
- depending on that, giving sustainability weight in technical decisions

re-checking existing requirements for the system:
- re-evaluating decisions taken earlier: it makes sense to be overcautious and overprovision for the sake of performance or stability when designing a system. After having gained some experience with it, one could take the time to reduce what has turned out to be superfluous

2. Software Engineering:

supporting endusers’ older hardware
- hardware manufacturing emits lots of carbon. One way to achieve longer lifespans is by providing software support for an extended period and considering performance on older devices

using environmentally friendly technologies:
- using an energy efficient programming language like Rust (2^nd rang) – but Java is not that bad either (taking the 5th rang) compared to python (making only 2^nd last and using 75 times as much energy as Rust)
- profiting from a resource friendly cloud-native java-framework like Quarkus or Spring Native that starts up quickly so that you can scale applications trouble-free on demand

solving performance issues and fixing memory leaks:
- where performance issues or memory leaks have a big impact, try to solve them

reducing logging
- logging as little data as possible while still being able to retrace what happened in production
- adding appropriate log levels
- choosing reasonable retention times (e.g. longer retention times for audit logs, shorter retention times for logs that exist only to facilitate incident response)

finetuning observability
- observability can also accumulate data, so using it in a controlled way can save storage

3. Architectural Patterns – CPU / RAM

This point is rather specific to microservices. The goal here is to reduce the amount of maximum CPU / maximum RAM allocated to a service so that there is only minimal idle CPU / RAM when the service is running

eliminating peaks in CPU / RAM (to reduce the need of overprovisioning a large buffer that is then unused most of the time):
- distributing load evenly to avoid spikes by queuing requests
- throttling client requests if this is a viable option / using a circuit breaker
- if the spikes are caused by scheduled requests: jittering the requests randomly so that they do not all arrive at the service at the same time

utilizing architecture to enable scaling:
- extracting components that should be individually scalable as separate microservices
- evaluating whether FaaS (e.g. AWS Lambdas) are a fit for your use-case as they only get activated when they are needed

4. Architectural Patterns – Networking

Since many hardware components like routers, proxies, loadbalancers etc. are involved in networking, it is worth to aim for reducing network traffic in order to reduce energy costs along the chain of communication

shortening transport distance of data:
- shortening the distances traveled by using e.g. a CDN caching data directly at the client

sending as little data as possible:
- introducing a filtering step before sending data in order to send only data required by the target
- reworking requests / queries, which might be as simple as not using SELECT * FROM when the table has lots of columns

5. IT-Operations:

Most of the software systems already exist and are operated in large data centers. Measures taken here have the greatest impact on the carbon footprint since they may affect multiple systems at once. Additionally, energy consumption and energy savings can be monitored very easily.

detecting memory leaks and performance issues:
- monitoring e.g. CPU and RAM usage
- setting alerts for unusually high values in order to detect and then fix memory leaks or performance issues

measuring not just proxy metrics like CPU/ RAM but energy usage and carbon emissions:
- using Kepler:
  - RedHat emerging-technologies open-source-project
  - estimates power consumption of Kubernetes Pods
  - can be used for pod scheduling and scaling or extended with carbon intensity metrics
- using CloudCarbonFootprint:
  - free and open-source
  - architected to work for multiple cloud providers including, AWS, Google Cloud, and Microsoft Azure
  - includes estimates for both energy consumption and carbon emissions, considering emissions for computing, storage services, networking, memory usage and the emissions from manufacturing hardware
  - offers visualization with graphs and charts, shows emissions in terms of airline flights, phones charged and trees planted
  - gives recommendations for AWS and Google Cloud to reduce cost and carbon emissions as well as projected savings
- the big cloud providers like AWS, Google Cloud and Microsoft Azure offer their own tools to measure carbon impact:

scaling „zombie pods“(= idle pods) down to zero:
- deleting all pods that no longer fulfill any purpose
- scaling dependent on CPU-usage
- making use of event-based scaling e.g. with KEDA (can scale according to events like: number of messages in a queue, query-results from different database-products, …)
- stopping all pods in dev-environments during specific time-periods, e.g. during the night or on weekends with a tool like kube-green

reducing the number of environments on the platform:
- checking whether all environments are used for different purposes and whether some environments can be merged

minimizing network distances
- if the user group is mostly concentrated in one or just a few areas: deploying the applications in a region geographically close to its users
- deploying all applications that communicate often with each other in a single region as well

executing time-flexible workloads when the percentage of renewable energies in the grid is high:
- combining data from carbon intensity APIs (e.g. Carbon Aware SDK(free)) with the energy measurement tools from the bullet-point above to create a low carbon scaling and / or scheduling strategy
- using pre-existing solutions like the KEDA Carbon Aware Scheduler

reducing energy usage of backups and archived data:
- avoiding backing up unnecessary data, e.g. temporary data or data that can be easily recreated with the data already contained in the backup
- classifying files in storage according to how often they get used and moving seldomly used files to a more energy efficient but slower storage

6. Public Cloud

running applications energy-efficiently in the cloud
- data centers of public cloud providers are highly efficient and run at a utilization rate of approx. 65% while private data centers often only reach a rate between 12 to 18%. Therefore, switching to a public cloud provider can save energy
- employing platform features offered by cloud providers to further reduce energy usage (for AWS, see the link to a series on sustainability in the following paragraph)

Conclusion & Link-List

I hope you could find something for your use-case! As always, before implementing any optimizations, it is important to ensure that they genuinely contribute to the desired outcomes.

Of course, there is a lot more information about Green IT than I could fit into this blog post, so here are a few links to interesting websites or guides:

Three part AWS-series on how to utilize their platform features to increase sustainability: (click)
Interesting Energy-Efficient-Software-Architecture-Talk at the last GOTO-conference: (click)
Quarkus video on LightswitchOps (= scaling down all unused applications, made possible by startup times quicker than a lightbulb lights up): (click)
10 talks about environmental topics at the last kubecon: (click)The Green Software Foundation, a foundation focused on making software more sustainable: (click)
CloudCarbonFootprints’ methodology documentation offers a good overview of how much energy CPU, storage, memory and networking consume respectively: (click)