Sustainability in Software Engineering
The entire world is moving towards being more sustainable, and why should we be any different when it comes to how we write and run software? That’s the question we’ve been asking ourselves recently. We run everything in AWS, utilising the flexibility of the cloud. When our systems were running slowly, it was very easy to just add another EC2 instance or bump the size of our RDS instance. Performance problems were usually solved quickly and more capacity was added to our infrastructure to cope with busy periods. It was much quicker and cheaper than asking an engineer to look into why our memory consumption is up 10% over last month. Maybe the traffic to our site has increased and we’ve spawned a few more processes? Maybe a new library we’ve added, or the updated version of an existing one, is a little less efficient? Maybe we’ve introduced a bug that’s consuming more memory than it should?
We receive between 7 and 15 million pageviews a month, depending on seasonality. During December 2022 we had 15.3 million pageviews. Each time someone views the site it requires energy to transfer the data from AWS across various networks to the end users device, that requires energy to process the data we deliver.
It’s not sustainable to keep throwing hardware at problems that are likely caused by inefficient code, libraries, or poor system design. We need to do better and take responsibility for these issues, investing the time to fix them and writing software responsibly. So how have we been approaching this at VoucherCodes? That’s what we’ll begin to answer.
Taking stock
To look at how we can improve we need to know where we’re starting, by taking stock of our hosting emissions, and emissions produced by our end users.
AWS
In 2022 AWS released their Carbon Footprint Tool. This allows you to see which services are producing emissions, how many metric tons of carbon dioxide-equivalent (MTCO2e) you produced, and how much was offset thanks to renewable energy purchases. Using this tool we discovered that in 2020 we produced 10.6 MTCO2e and in 2021 this had crept up to 12.1 MTCO2e.
The unit of measurement for carbon emissions is metric tons of carbon dioxide-equivalent (MTCO2e), an industry-standard measure. This measurement considers multiple greenhouse gases, including carbon dioxide, methane, and nitrous oxide. All greenhouse gas emissions are converted to the amount of carbon dioxide that would result in equivalent warming. You can read more on this topic from AWS.
AWS is a green hosting provider, they’re aiming to run all their data centres on renewable energy by 2025. This is why their Carbon Footprint Tool shows the equivalent CO2 values and provides a breakdown between your emissions saved by AWS renewable energy purchase and your estimated AWS emissions.
For example, during the first 6 months of 2022, one of our AWS accounts avoided 1.2MTCO2 thanks to renewable energy purchases.
We’re unable to see our full 2022 results as there is a three-month delay using this tool, as it stands we’re currently at 5.5 MTCO2e from January to September. We expect to be around 8 MTCO2e by the end of 2022.
While this is a step in the right direction, even AWS knows that “the greenest energy is the energy you don’t use”, as Peter DeSantis, SVP, AWS said at re:Invent 2020.
End users
With regards to our users, it’s a bit trickier to estimate carbon emissions, however there are some great resources out there to help. We have used Website Carbon Calculator for this. To understand their methodology I strongly recommend reading their “how does it work?” page along with the Sustainable Web Design’s page on calculating digital emissions.
In February 2022 our homepage produced 0.44g of CO2 every time someone viewed the page. That doesn’t seem like much on its own but, with approximately 1,000,000 homepage views a month, our end users would produce roughly 5,251 kg of CO2 over a year. This is just visits to our homepage, that’s a lot. It’s over half the emissions from our AWS infrastructure.
With some image, HTML, JS & CSS optimisations we managed to lower this to 0.18g of CO2 for every pageview, meaning the same 1,000,000 pageviews each month would only produce 2,180KG of CO2 over the year.
After discovering this interesting insight, we reviewed the top 20 most visited pages according to our analytics for the first six months of 2022. During this period, our end users viewing the site would have contributed an estimated 2,839KG of CO2 based on 20 million pageviews.
Through the entirety of 2022 we received 135 million pageviews. The majority of our site required 0.13g of CO2 for each pageview, some pages require more due to increased imagery. If we use an average of 0.141g of CO2 per pageview, calculated by averaging the CO2 required for the top 20 pages, this would put our yearly emissions from end users at 19.16 MTCO2. That’s more than twice the amount we’re expecting to have emitted from AWS, a great opportunity for improvements.
What we’re going to do
We have already made progress throughout 2022 however, for 2023, we want to really push ourselves. We’re going to aim to reduce our AWS emissions by at least 30% by the end of the year. Based on our estimated 2022 results, this would mean going from 8 MTCO2e to 5.6 MTCO2e. This is, however, a small proportion of our emissions and the largest impact would be seen by reducing the emissions generated using our site — a much trickier challenge.
With seasonality and fluctuating traffic levels it’s hard to aim for an overall target. Our goal will therefore be to reduce our average g/CO2 per pageview from 0.141 to 0.13. This sounds like a small change, and it is, but we want to be realistic with our goals. With various changes towards the latter half of 2022 our average CO2 per pageview has crept up to 0.218! With last year’s traffic this would produce 29.62 MTCO2. We’re actively investigating this and hope to reduce this again before the end of Q1.
AWS
We’ve already identified systems that are over-provisioned for certain requests that occur once a fortnight or once a month. We’ll be looking to move these to microservices or serverless solutions that will allow us to scale our infrastructure down to what we need for our average workload, and to use the elasticity of the cloud for these peaky or infrequent requests.
To help with these peaky workloads, we’ll be reviewing each one and identifying ways we can optimise the processes, and potentially languages used, to require fewer resources and run more efficiently. Rust is the hot topic for efficient languages and, while I doubt we’ll switch everything to Rust for our use cases, switching from Python to Go for certain tasks may yield efficiency improvements, as noted in this excellent post by AWS on Rust, including a comparison on the energy efficiency of popular languages.
Auto-scaling of our Kubernetes clusters is another area we’ll be reviewing. For example, we run RabbitMQ within our EKS cluster and, due to its setup, it limits our ability to aggressively scale the EC2 nodes in our EKS cluster. We’ll be reviewing the managed RabbitMQ instances offered by AWS and comparing them to SQS to identify which solution suits our requirements.
Coupled with reviewing our messaging tool, Docker images is another area we’re looking to optimise. By reducing the image size, we’re storing and transferring less data each time a new image is pushed, or pulled, when a pod is required.
Ultimately decisions such as these will allow us to reduce our EC2 usage for EKS, and to scale much more aggressively, thereby reducing our power consumption and producing less emissions.
Our final comparison for now will be x86 vs ARM, or Graviton in this case, for our EC2 & RDS instances. AWS claims up to 60% less energy usage compared to comparable x86 EC2 instances. As they are different architectures, we’ll need to review how they perform with our workloads — look out for a future post about this.
Applications/site
For our site we will continue to focus on image optimisations, utilising the latest image compression technologies and tweaking the settings accordingly. Images are the largest contributor to our page load and offer the biggest opportunity for optimisation, data transfer reduction and, ultimately, emissions reductions. We will also be looking to cache more of our content to reduce web requests to our systems. We will look to achieve this through better caching strategies, reviewing how frequently we need to refresh the cached data, statically generating portions of the site and pushing as much as possible to our CDN to reduce our compute requirements.
We’ll also be using the Well Architected framework provided by AWS. This focuses on six pillars:
- Operational Excellence
- Security
- Reliability
- Performance Efficiency
- Cost Optimisation
- Sustainability
For any new system or service we’ll continually review our decisions with the Well Architected framework in mind. When we make changes to existing systems, we’ll review the changes we’re making and determine if they meet the Well Architected criteria, chiefly whether it’s sustainable or not. Once this becomes part of our process our entire team should be thinking “do I need to run this process every five minutes or would every fifteen minutes suffice?”.
How we’ll monitor it
Honestly for now it’s fairly rudimentary, it’s a spreadsheet. We’ll monitor our progress in AWS each month using the Carbon Footprint Tool and log the values for our accounts in our spreadsheet. We’ll then review the top 20 most viewed pages for the prior month and review their carbon footprint using Website Carbon Calculator and log these too.
These will be reviewed monthly by our engineering team and, if we detect an increase, we’ll investigate and triage the issue. We’ll also discuss if there are any optimisations we can make in the coming month to help.
What can you do?
Review your own setup and challenge everything. Is your hosting provider green? Azure and Google Cloud Platform both have sustainability missions, to be carbon neutral and power their data centres with 100% renewable energy by 2025 and 2030 respectively. Google has already achieved powering their data centres on 100% renewable energy.
Are your applications performant, or did you also add more resources to cope with processing inefficiencies? Can you optimise your site to require fewer resources? You’ll be amazed at how the smallest changes can have big impacts.
Closing thoughts
Thank you for taking the time to read this. I hope it inspires you to question how sustainable your software engineering efforts are or celebrate how well you are already doing. We know there are limitations with our approach to measuring our emissions and, while we’re using both the AWS Carbon Footprint Tool & Website Carbon Calculator tools, we need to remember these are estimates. However, we feel using these tools and trying to make a difference is better than ignorance on this issue.
We’ll be monitoring our progress internally and hope to provide future posts with our progress. Look out for separate blog posts on some of our topics such as performance optimisations we uncover.
Have you heard? We’re hiring at VoucherCodes! Check out our careers page here.
