Making Sense of the 8 Principles of Sustainable Software Development
In this article I will go beyond the fundamentals of Green Coding and Green Software Development to provide a practical understanding of the emerging eight principles of Sustainable Software Development. However, first it is important to understand the context of why it is so important to understand that altering your software development practices can have a positive impact on the effects of Climate Change.
We live in an interesting cross section in the history of the world! The world has advanced over 100’s of years through a series of “industrial” revolutions. There has been a shift through a series of advancements from animal power, mass production and more recently to digital advances which have fundamentally changed how we operate as local and global societies.
On the one hand the advancements and our thirst for modernisation have brought great prowess and innovation to the world, however we have left the very engine that supports us “The Earth'' and “The Climate” as an afterthought.
It is only now in recent times that there has been enough education on Climate Change that we begin to see the emergence of movements and fields to make sense of what we can do at an “individual” level to have a positive impact on slowing Climate Change.
There are a group of emerging fields and disciplines that can help us as Tech People be good climate citizens. One of the more mature of these fields is Green Software Foundation. As highlighted in a previous blog The Foundation is a non-profit organisation established in 2021 aimed at developing a network of "people, standards, tooling and best practices for green software”.
Most importantly the Foundation has developed a set of 8 Principles that are quickly gaining momentum as the practical fundamentals that can be applied to Software Development to promote being a good Tech Climate Citizen.
The 8 principles of Sustainable Software Development
- Carbon: Build applications that are carbon efficient
- Electricity: Build applications that are energy efficient
- Carbon Intensity: Consume electricity with the lowest carbon intensity
- Embodied Carbon: Build applications that are hardware efficient
- Energy Proportionality: Maximise the energy efficiency of hardware
- Networking: Reduce the amount of data and distance it must travel across the network
- Demand Shaping: Build carbon-aware applications
- Measurement & Optimisation: Focus on step-by-step optimisations that increase the overall carbon efficiency.
Further information on each principle can be found here.
You are probably thinking, Great but what do each of these practically mean? How can you alter your approach to software development and apply these principles in a practical manner with data and measurement as an outcome.
Let’s take the first principle:
1. Carbon: Build applications that are carbon efficient
Firstly, Carbon (CO2) is a well known synonymous representation of several Greenhouse Gases (GHG). Carbon has become the most recognizable GHG.
Yes! It is true that GHGs are a naturally occurring element of our Climate! However CO2 stands out because of the human effect we have had on its increase in our climate. The industrial activities that our modern civilization depends upon have raised atmospheric carbon dioxide levels by nearly 50% since 1750.
So how do you know if you are being carbon efficient? How do we measure this? To do so we need a method of normalising all of the known GHGs into a simple formula to provide us with a unit of measure. This is known as the carbon dioxide equivalent (CO2eq).
It makes sense then that as Software Developers who aspire to be good Climate Citizens we should develop applications and services that are carbon efficient.
Thought Leadership Questions for Carbon Efficiency:
- Which solution(s) is the one that is going to be more carbon efficient?
- Which solution gives the most value per unit of CO2eq?
With this understanding of the carbon dioxide equivalent it will allow us to explore the practicalities of the second principle.
2. Electricity: Build applications that are energy efficient
There are two types of electricity, Dirty and Clean. According to an ember-climate.org report.
In 2021 global wind and solar generated 10.3% of the global electricity and combined with other clean sources, clear electricity generation reached 38% of the world's electricity.
Now, whilst this is great news, sadly the report goes on to mention that the world's high demand for electricity has meant that 2021 saw the fastest demand for electricity in the last 10 years.
The net effect of which is that 71% of electricity demand in 2021 was met through dirty electricity (namely coal) which equated to 62% of the world’s electricity from fossil fuels.
So, without electricity we would not have software! We would not have the internet. Electricity therefore is something we cannot avoid as Software Developers.
Much like carbon we have to approach being efficient with electricity in a similar way..
Again to do so we need to understand how we can measure it. Typically electricity is measured in kilo-watt hours (kWh).
Essentially kWh is a volume of energy, for example An electric heater consuming 1000 watts (1 kilowatt), and operating for one hour uses one kilowatt-hour of energy.
Having an understanding of what electricity will allow us as good climate citizens to be able to switch our mindset from that of electricity as a problem to electricity as a solution.
Thought Leadership Questions for Energy Efficiency:
- Which solution(s) is the one that is going to be energy efficient?
- Which solution gives the most value per kwh?
The essential takeaway from the first two principles is that Electricity can be equated to energy consumption and the less energy we consume the more carbon efficient our software solutions will be.
Carbon Efficiency and Energy Efficiency are very tangible proxies for carbon, allowing us to provide real world metrics and as such understand how to solution software in a sustainable way.
However just because the software is efficient does not directly show the carbon intensity of the solution. For this we need to understand the third principle of Sustainable Software.
3. Carbon Intensity: Consume electricity with the lowest carbon intensity
As I briefly touched on above we consume electricity through power grids. These grids are typically a matrix of smaller electricity generation sources that produce electricity from a variety of sources. Some of those sources are dirty such as fossil fuels, most notably coal and gas. Some of those sources are from cleaner sources such as wind, nuclear and solar.
A power grid will balance out the available electricity depending on the levers of supply, demand, cost and time. So it is quite conceivable that at a given time of day there would be more cleaner electricity available in a power grid than dirty electricity and vice versa.
So what does all this mean for Sustainable Software Development? Much like the first two principles there is a metric that can help us use Carbon Intensity as a proxy for understanding how sustainable software can be.
The carbon intensity of electricity is a measure of how much carbon (CO2eq) emissions are produced per kilowatt-hour of electricity consumed.
As a metric this equates to the total grams of carbon dioxide equivalent per kilo-watt hour (gCO2eq/kWh).
Since 2020 Australia has reduced its Carbon Intensity by 26.68%. In comparison the United Kingdom 44.87% and the USA has reduced their Carbon Intensity by 28.52%.
At a macro scale this is great news, as a good climate citizen we can effect real change on a daily basis by understanding this concept and look for opportunities to improve our software’s carbon intensity.
Thought Leadership Questions for Carbon Intensity:
- Which solution(s) is the one that is going to be less carbon intense?
- Which solution gives the most value per unit of gCO2eq/kWh?
Even the simple act of hosting more user intensive workloads in a region where the carbon intensity is lower can be a great start!
Okay, so the first three principles focus on how we can reduce carbon intensity through coding with thought given to energy consumption.
Did you know that practically everything that we have in our possession carries a carbon cost through its creation & destruction process. This concept is called Embodied Carbon and that leads us to the fourth principle.
4. Embodied Carbon: Build applications that are hardware efficient
It turns out that Embodied Carbon is a complex item to quantify. Unlike the first three principles where proxy equations can be applied it is difficult to apply the same for this principle.
The basic concept is that if you know a piece of hardware (for example a server or a mobile phone) has a certain carbon footprint you should be able to amortise over its life cycle the Embodied Carbon value of it. As an example.
In its first year of usage a mobile phone on average will produce 85kg’s of emissions. Ninety-five percent of this comes from manufacturing processes, including the extraction of raw materials, shipping and production.
Embodied Carbon becomes your responsibility once a device is in your possession or you begin using it.
Therefore if you truly want to understand the holistic view of the carbon impact of software we should also account for the embodied carbon in your software ecosystem.
There are a couple of attempts to determine Embodied Carbon of cloud services as follows:
Cloud Carbon Footprint
Building an AWS EC2 Carbon Emissions Dataset
A simplified measurement would look like. CO2eq / time = Embodied Carbon per year
Bringing this back to the mobile phone if the lifecycle of the phone is 4 years then the Embodied Carbon calculation would look like the following:
80.75kgs / 4 = 20.1875kgs per year.
After year 4 the the Embodied Carbon of the phone would = 0kg’s
If we extended the life cycle of the hardware the carbon cost per year would be less overtime. Staying with the mobile phone example, extending the phone by 1 year would see the amortised Embodied Carbon drop by approximately 20% (20.1975kgs / 16.15kgs).
Even while a mobile phone is sitting in your pocket not doing anything it is emitting Embodied Carbon!
Whilst the calculations and concept of Embodied Carbon are complex as Software Developers we can still have a positive impact through this principle:
Thought Leadership Question for Embodied Carbon:
- Can we develop software to run longer as hardware ages?
5. Energy Proportionality: Maximise the energy efficiency of hardware
Even when a server is idle it is drawing “static power”. This is because the server hardware such as its CPUs, Memory, Storage Devices and GPU’s for example are powered on ready for their next workload even when there are none. A server with 0% utilisation is still drawing power!
In fact, the less a server is utilised the worse its Energy Proportionality is and the greater impact it has on the environment.
The more you use a server the more efficient it becomes which in turn means that the electricity consumption (the energy) it uses is more proportionate to your software workload.
Energy Proportionality is a measure of the relationship to the energy consumed and the rate of which useful work is done.
This principle is extremely important for Sustainable Software Development.
The static power consumed by 1 server could be 100w when it is idle at 0% utilisation.
At 100% utilisation the power consumed is 200w. (100w of which is already consumed by static power).
Therefore at even just 10% utilisation the server would still be consuming 100w of static power plus 10w of available power.
At 50% utilisation the server might be consuming 180w of power, so the proportionality of power being utilised as the utilisation increases levels out over that amount.
If the workload was split over 2 servers at 25% utilisation each the actual power used by those 2 servers would be 280w of power (being 100w of static power plus 40w of workload per server).
It is in our best interests then to have higher utilisation on one server than to have several servers running workloads at a low utilisation rate as they would be consuming energy at a less efficient rate.
Thankfully most of the cloud providers have metrics and guidance that can be applied for Sustainable optimisation of software workloads.
Some great guidance is provided by AWS and Azure.
Thought Leadership Questions for Energy Proportionality:
- Can we develop software that is utilisation aware?
- Can we architect software to maximise workload utilisation of the underlying infrastructure and services?
6. Networking: Reduce the amount of data and distance it must travel across the network
All of the standard components that you would typically find in a network of any size such as routers, servers, switches and firewalls will consume, emit and have embodied carbon as part of their carbon footprint.
No matter the size of a network, from localised networks to the largest of them all….the internet each node will draw power and therefore emit carbon dependent on the local grid from which the node is indirectly attached.
On larger networks it is possible that there would be a greater mix of dirty and clean nodes. Meaning some nodes would be running on dirtier energy sources than others.
In an iea report it is mentioned that;
- Globally, data transmission networks consumed 260-340 TWh in 2020 (excluding crypto mining)
- Cryptocurrency mining consumed an additional 100 TWh in 2020
The report goes on to state that;
- The build out of infrastructure to accommodate greater anticipated peak capacity could raise overall network energy use in the long run
- Emerging digital technologies such as blockchain, machine learning, 5G and virtual reality will raise demand for data globally across networks
Common networking concepts such as utilising Edge Nodes to store localised data is important, as is designing applications that are not data intensive and if they are, consider what can be done on the database to minimise the volume of data transmission.
Thought Leadership Questions for Networking Efficiency:
- How can we minimise the volume of data that runs from the source node to the destination node
- How can we efficiently minimise the distance data must travel from source node to destination node
7. Demand Shaping: Build carbon-aware applications
Understanding the differences between Demand Shifting and Demand Shaping is vital to understand this principle.
At the most basic level, Demand Shifting is concerned with shifting workloads across regions. For example if carbon intensity is less in one region compared to another you would shift the workload to the region that has the lesser impact on carbon production.
Demand Shaping on the other hand is concerned with shaping demand to match existing supply. If the supply of clean energy is high, do more with the software. If the supply of clean energy is low, do less with the software.
Think about Demand Shaping as helping software consumers understand the carbon footprint of software at the time they are using it. In this manner you are building carbon aware software.
Most information available shows that mobile phones are less energy efficient than wifi connected devices.
With Demand Shaping and carbon awareness in mind it could be conceivable to develop an application that is aware if the user is on a mobile network or wifi network and adjust its functionality accordingly. For example reducing the resolution of images if the user is drawing from a more carbon intensive energy source.
A fascinating real world example of this is through the website branch.climateaction.tech
As the supply of clean energy increases the website becomes more feature rich. E.g. images are readily available to see.
As the supply of clean energy decreases the website gracefully hides images and displays an option for the user to see the image if they want to.
They also employ a visual colour gradient from Green through to Orange/Brown as the supply transition of clean energy ebbs and flows from fossil fuels to clean energy sources.
Thought Leadership Questions for Demand Shaping:
- What concessions can we make in our software to incorporate carbon awareness?
- How can we display the climate positive influences of our software to our users?
8. Measurement & Optimisation: Focus on step-by-step optimisations that increase the overall carbon efficiency.
As this principle states, optimising for sustainability is not a one step task.
Given the breadth and variability of carbon a good place to start would be to understand the complete value stream and/or full tech stack of the application or software.
In doing this you should get a better understanding of potential optimization opportunities.
Understanding that a balance needs to be maintained between effort and reward. If it is too costly or complex to decarbonise what part of the software ecosystem it is best to move onto an area that can yield more tangible results.
Given all of the moving parts that affect carbon emissions, showing real world tangible results can be tricky. If you can draw a correlation of one element to a direct carbon output then that is a good carbon proxy that can be used.
Identifying carbon proxies is the best way to measure optimisation and therefore the carbon health of your software.
Sustainable Software Development Methodology
With the 8 green principles in mind it is important then to have a development methodology that supports them.
Incorporating sustainable and green criteria into the software development lifecycle is paramount to understanding, tracking and showing value with respect to the principles.
An analysis step should also take place after the standard software development flow stages for example after requirements gathering, design, development, testing, usage, maintenance and disposal of the software.
If the sustainable and green criteria are built into the process they should be handled in much the same way as any other Functional or Non Functional requirement.
At this juncture in understanding the Green Principles it is highly probable that you could just say well, these principles are too far abstracted from Sustainable Software Development to make a difference to Climate Impact.
However, This is very flawed thinking and not dissimilar to burying your head in the sand!
Within each of these principles there are current real world correlations to best software practices today.
Most if not all businesses want their software to be designed and built to run efficiently. Efficiency is a key concept as it often means software is less costly to develop, run and maintain.
Performance is another key factor for businesses. Performant software also typically lends itself to reduced development and maintenance costs.
So already we can use efficiency and performance as levers to obtain metrics as proxies for measuring the carbon footprint of software.
Sustainable Software development and Green Thinking is everyone’s responsibility!