I recently learned about this project, and I can’t stop thinking about it, and how it is strangely connected to what I was doing for a big portion of my professional life.
First of all, what is this project about? Since people rarely click the links, let me copy a project description here:
Cloud Carbon Footprint is an open source tool that provides visibility and tooling to measure, monitor and reduce your cloud carbon emissions. We use best practice methodologies to convert cloud utilization into estimated energy usage and carbon emissions, producing metrics and carbon savings estimates that can be shared with employees, investors, and other stakeholders.
What exactly contributes to the carbon footprint? The operational costs consist of Cloud provider usage, Cloud energy usage, power usage effectiveness, and grid emission factors. In other words, if you use more CPU to make the same calculations, your CCF will be higher. If you perform more IO operations to obtain the same data, your CCF will be higher. At this point, it should be clear how this is related to what I am doing. When I optimize queries or improve application data access patterns, my goal is to avoid “killing it with iron,” in other words, to avoid solving problems by adding more hardware. The KIWI approach is not scalable :).
Quite often, developers (and especially their managers) claim that it is faster and cheaper to throw more hardware into a problem rather than rewrite the application code. Now, we have one more argument against that approach: inefficient queries increase carbon footprint!
Right now, I am unsure of how I could possibly contribute to that project, but it looks like in addition to two existing optimization goals – decreasing query execution time and increasing system throughput, we should consider the third one: minimizing the carbon footprint.