Measure, report and develop against estimated CO2 emissions #2
In a discussion this morning on the Keyoxide General Discussion Matrix channel, an idea was proposed by @Ryuno-Ki to integrate CO2 emission estimations in the development process of the Keyoxide project.
The overall concept would likely be to:
- measure data usage and traffic by the various Keyoxide subprojects
- estimate CO2 emissions
- report and track those numbers
- make (development) decisions with the goal to minimize the estimated emissions or stay within a budget
Overall, I think the idea is interesting and something that is ignored by the larger dev community. If we could implement a clear strategy to integrate those estimates, we could hopefully inspire other projects to follow a similar path.
Since estimations of CO2 emissions are already by nature an inaccurate science, thoughtful considerations must be made lest the method becomes entirely pseudo-scientific and hurts the developer experience for no actual benefit.
Thanks for the mention. I want to elaborate a bit more.
I've brought up a project I'm keeping an eye on since some time: co2.js.
I want to start with what led me to bringing this subject up before I sketch on how I would imagine this to be handled. Don't feel compelled to do it as I say but pick what you like.
Our world is burning. We emit more CO2 etc than the planet can handle. IT has to play its role in this.
Reading The Experiences of People Running Mastodon Servers Suggest a Bumpy Road Ahead
brought this subject to the top of my mind again.
Combine that with Web development's lost decade on The Changelog and you realise that we are doing a bad job.
So I want to take this project to educate in part. I'm speaking with a decade of experience in the industry. A part of it even in DevOps.
The target audience in my mind are operators. Those folks that feel a Devotion to Duty :)
In second order developers should look into this.
For the services I want to run myself I want to implement Observability. This grants me insights into how my software is doing. After doing some research I decided to go with Telegraf for my on-premise solution. It features lots of integrations to give you a glimpse of what is possible.
I'm pairing this with Grafana for dashboarding which also comes with plenty of data sources.
Relevance for Keyoxide
Keyoxide is talking to different other APIs. As such I think it makes sense to have some metrics on how those other services behave. My services are behind Nginx as reverse proxy. This web server can log request time for requests declared as upstream.
If such a service takes long time to respond, future requests should not be made and the user be shown a warning that the service is currently degraded. Best approach for that person is to try again later.
But network traffic is not the only source of emissions Keyoxide (or other projects for that matter) are causing. Algorithms is the main thing that is in control.
Speaking of numbers, I'm not sure whether the values are accurate. In fact I would assume that the datasets have some error baked in. But I would expect that the order of magnitude is about right. This alone should be valuable (if you plot, the order of magnitude for result in a logplot - that is, the axis are logarithms.
In order to be applicable to a rust crate, I think the code would need to be ported. So at the current step, take at as an opportunity to have a conversation on it. That's all I'm asking for right now.
If I get around to add it as a datasource and you are interested, let me know :)
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?