The Information and Communications Technology (ICT) industry is responsible for up to 3.9% of global greenhouse gas (GHG) emissions today. This figure was 1.6% in 2007, and scholars at McMaster University predict it to reach a 14% share by 2040 as technology adoption continues to accelerate worldwide.
The challenge in reducing these emissions is multi-layered. But the impact of the energy used to power the hardware and software we build is a significant contributor to these statistics.
Compute power is becoming more and more efficient, performant, and readily available. As a result, software efficiency has taken a backseat in favor of developer productivity and delivery velocity. And with this behavior, GHG emissions from software are increasing somewhat unchecked.
The necessary drive to reduce emissions presents an excellent opportunity to interrupt this trend and place greater importance on software efficiency. While researchers have been looking into green software development for some years now, it is only recently that community sentiment has picked up steam.
We’re starting to see positive movement. But most people I speak to in software delivery are still relatively underinformed. They lack a clear understanding of technology’s impact on the environment and the steps they can take to improve things as part of their role.
Where is the Industry today on Green Software Development?
The industry’s understanding of green software development is still in its infancy. Today the focus on the concept has been a little intangible, primarily through community building and awareness initiatives, with the Green Software Foundation leading the way. While these are foundational puzzle pieces, there is still limited tangible implementation advice (e.g., patterns, practices, and tools) for those who build software.
To date, the most advanced tangible aspect of green software delivery is measurement - specifically in the cloud. AWS, Azure, and GCP have each developed tools to measure and analyze cloud emissions. However, these solutions provide variable granularity and transparency. In some cases, they don’t include embodied carbon – a proportional share of carbon emitted in the manufacture and disposal of the hardware itself and an essential factor in measurement. In addition to vendor tools is the Cloud Carbon Footprint open-source measurement tool – designed to work across public clouds with a granular level of detail, which includes embodied emissions.
Embodied carbon can be a majority of the overall picture, and not measuring it can hide the true carbon impact of cloud services. Furthermore, if you rely on cloud measurements alone, you restrict software boundaries, excluding hardware outside of the cloud and supporting systems such as onward network data transfer, as well as end-user device energy and its associated embodied carbon. This can be another significant factor for a high-usage app or website.
Still, cloud measurement is a valuable piece of the overall picture and an essential part of green software development. It enables the observability of energy and carbon costs as used in the “test and learn” loop. Without cloud measurement, it becomes a challenge to identify the full scale of emissions and the impact any improvements may have had.
Cloud measurement tools are central to a CarbonOps approach, similar to FinOps, whereby you can monitor cost (in this case, carbon cost) and the actions taken to reduce expense over time. As a result, you can reduce the emissions of existing software already in production use.
This CarbonOps approach requires a starting point upon which to implement incremental improvement. When developing new software, the starting point does not exist until the system reaches a certain level of development and use, perhaps the MVP. This is especially true in the enterprise setting. Here, getting code into production use quickly may not be possible for some systems, and you may need to extend feedback loops over lengthy release windows.
Considering this, if the software is designed and built with poor consideration of emissions, you may find yourself locked into a poorly optimized solution - one that is hard to improve, based on architectural decisions you cannot easily reverse. Waiting until you can measure is too late.
Beyond MVP, when building each new iteration, we want to give it our best shot as we develop and “test and learn” on top. This is especially true where release windows are far apart. We believe you can make greener software as you go by considering the concept throughout the software delivery lifecycle rather than treating it as an afterthought.
Green Software Literacy
One of the first things that can be done to make greener software is education to build software carbon literacy within your teams. They must be familiar with the fundamental concepts of energy usage, carbon emissions, and the actions you can take when designing and building software to reduce carbon emissions.
As you read this series, you’ll see that a great deal of critical thinking is required to develop greener software, and carbon literacy is necessary to support that.
Microsoft has a short learning module on sustainable software engineering principles, which the company has designed for those working in software delivery. It’s worth each of your team members taking an hour to read through this and take it on board – it’s the same set of topics covered here.
These principles will be expanded to include patterns and practices in the near future, making them a more useful practical resource. Additionally, the Green Software Foundation has recently released a short set of training materials, with a stated aim of having one million certified globally before the close of 2023.
Finally, we also recommend giving people some time to do their own research. There’s a considerable amount of information, and it’s a great learning experience to work through it naturally.
This is the first article in a long running series where we dive into green software delivery. The remaining articles in this series will each dive into one or more areas of software delivery, from requirements through to operations. Each will detail approaches that can be taken, considerations to be made, and resources to use to deliver software with a lower carbon footprint. Look out for the next article where we discuss how to bring a green approach to requirements.