Software and online solutions are often put forward as convenient, low-emission, high-efficiency answers to real-world problems, but just because the end-user doesn’t see any tangible evidence of the internet’s negative environmental impact doesn’t mean there isn’t one.
In his 2010 book, How Bad Are Bananas?, Mike Berners-Lee estimated that the average email accounts for approximately 4g CO2e. This is a relatively low-carbon process, but once you factor in all the energy needed to run the infrastructure that supports that email, as well as how many emails are sent on a daily basis, the cumulative global impact is huge. Sadly, this isn’t an excuse to swear off email forever, but it is a good illustration of how many complex, emissions-heavy layers go into a seemingly simple process.
In some back-of-the-envelope calculations Cathleen did on the environmental impact of the web, she estimated that social media use emits around 1.4 million metric tons of CO2e annually. To put that in context, that’s the amount of energy that the Environmental Protection Agency estimates would power 161,000 US homes for a year. The energy needed to emblazon banner ads across the internet would power around 7 million US homes, whereas the impact of the world’s main streaming services accounts for around the same as Japan’s total yearly emissions. These are just ballpark estimates and do not take into account the potential positive balancing effects of the internet, but it’s enough to give you an idea of what we’re dealing with.
Developers have a unique opportunity to make a real impact on reducing greenhouse gas emissions as the digital world grows and matures. When we build climate awareness into our processes, products, and services, we pave the way for powerful, rapid change.
Programming languages, for example, differ in lots of ways that go beyond factors like logic, syntax, and capabilities. They also differ in terms of energy consumption. Designing your tech stack in a resource-aware manner might, for example, mean opting to write scripts in Rust rather than JavaScript or Python. And even if you’re not in a position where you can design or redesign your tech stack, regardless of the language, optimising your code to make it faster and more efficient will in turn mean it consumes less energy.
Application architecture choices have a direct impact on emissions comprising computation, networking and memory usage, amplified by idle servers. As an example: To mitigate the impact of CPU and memory at Climatiq, we dramatically decreased computation time and memory usage by using Rust as our main language for the API, which is, at a very rough estimate, a reduction of about 80-90% compared to a standard API implementation. In addition, Climatiq reduces traffic by deploying the application to the Edge, reducing the roundtrip of data between the client and the API, and we reduce idle server impact by using a serverless platform. This removes the need for idle servers as the application runs on-demand only.
There are many examples and the key point is that each of your choices can make a difference. A lot can be done at a baseline level in the tech stack and infrastructure to vastly reduce emissions. As a first step: understand your current impact and figure out tweaks that can result in immediate, meaningful reductions. And next time you start building up from scratch, you can be secure in the knowledge that each choice, each language, and each architecture can be resource-aware and make the right kind of impact.
