Sustainability is Crucial
Sustainability is extremely important: not just because we want to be good corporate citizens but also because our customers are also passionate about working with sustainable partners. We all collectively want to prevent this planet from deteriorating. And in GumGum Engineering, we take this very seriously.
We will be publishing a series of blog posts that describe the initiatives taken by GumGum’s Engineering department to improve sustainability efforts within various aspects of Engineering.
Need for KPIs Besides Carbon Emissions
Simply, becoming sustainable means reducing carbon emissions. While that’s perfectly clear to us, it can be a bit tricky when your company is growing rapidly. If your company is growing, if your traffic is growing, then naturally you are going to use more servers and as a result, you are going to also emit more carbon into the environment.
Here is a graph of our growth of compute in one of the AWS regions over the last 15 months:
In order to continue to grow while working to limit carbon emissions, there has to be a balance. That is why it’s important to establish a few metrics that can clearly show you that regardless your growth, your carbon emissions are effectively reducing.
Here are a few KPIs that can help you get started:
KPIs for a Supply Side Platform (SSP)
We have a fairly large supply side platform and we get billions of impressions/bid requests per day. Hundreds of servers across the globe handle these requests. We call them “inventory requests”.
These inventory requests impact the three main drivers of carbon emissions that are present in every company's infrastructure:
- Compute
- Storage
- Data Transfer
The inventory request needs processing and hence “compute” or CPU will be utilized. The inventory requests get passed to our Kafka, S3 and also to our Demand Supply partners, causing a fairly large amount of data transfer inside and outside the cloud. And this inventory request is saved in S3 for analytics and reporting, causing the storage to be consumed.
Therefore, one way to decrease carbon emissions, while experiencing growth, is to reduce compute, storage and data transfer required per inventory request. This gives us three KPIs:
Even though these KPIs are a good starting point, they are still proxy KPIs for carbon emissions. Here, an ideal KPI would be carbon emissions per inventory requests.
Why is the Proxy Metric Sufficient - At least in the Short Term?
The main issue with measuring carbon emissions is that this data is simply not available. The AWS Carbon Footprint tool has 6 month old data. We don’t think waiting for AWS to improve their data is an option. There are many tools available including in the open source space such as ThoughtWork’s Cloud Carbon Footprint. But while it can measure compute carbon emissions fairly well, we don’t think it will be able to measure our data transfer accurately. For the same reason, we don’t want to have carbon emissions numbers assigned to AWS instance types.
One of the biggest problems with it is that the carbon emissions change based on the AWS region and availability of sustainable power sources. AWS is continuously trying to reduce their carbon emissions and as a result, any empirical formulae used to come up with such numbers will not be accurate.
That is why a proxy metric serves much better. It’s readily available for measurement, currently available cloudwatch and it’s directionally accurate. That means if we simply use less amount of compute, we will be able to say that we reduced carbon emissions. Obviously we are aware that there might be some edge cases here. For example if some workload moves from Graviton CPUs to Intel CPUs, it’s theoretically possible to actually increase carbon footprint while reducing the CPU usage. But we think this will be done rarely in our environment as we are a very cost conscious engineering team.
Conclusion
When you establish clear, measurable metrics like above, it becomes very easy to judge performance of various teams in reducing carbon emissions. We can simply evangelize these three simple metrics across the engineering teams and even create goals for different teams. As they say - Keep it Simple Stupid!
