Why are we concerned with whether we can measure things? Our slogan may be “Architecting your Business” but we're not an architecture company ...
Wanting to improve things is naturally ingrained into us IT people – when you reach for the stars, you naturally want to improve the world. That's how we created p-sustainabilities – a group within pentacor whose mission is to make pentacor greener, more sustainable and more environmentally friendly. After a while, we had worked on all the low-hanging fruits – now we have regional drinks in the fridge, organic breakfasts on the table and we are probably all a bit more conscious about sustainability. Of course, we also keep the lights off in the office for as long as possible in the evening (not just for sustainability reasons, as we all know IT people don't like light).
But somehow it didn't really feel like saving the world. So where are the tools that can really make an impact? We have identified for ourselves that we as a company can achieve a greater impact by bringing the topic of green IT to our customers, making it relevant for them and thus also helping them to remain relevant, competitive and in tune with the times. At the same time, we are doing good for the basis of all life. There are enough reasons to consider green IT an important topic at pentacor, even if our customers have not (yet) asked about it directly.
It was not enough for us to know various ways to develop code in the spirit of green IT and we continued to think about how we could achieve more impact. For us, knowing the impact of our changes to a system is a prerequisite for being able to really make a difference. So, we asked ourselves how we could measure and compare the impact of the status quo and the (future) impact achieved by our changes.
When dealing with the topic of sustainability, it is relatively easy to get past various metrics such as electricity consumption, water consumption and CO2 emissions. If you delve deeper into the topic, it quickly becomes clear that all metrics can be summarized by carbon footprint. So how can we determine the carbon footprint of our software systems and perhaps even monitor it over time and track its development?
In our search for approaches that may already exist, we came across the Green Software Foundation (GSF). This is currently the place to go when it comes to sustainability in the IT sector. We found a wealth of information, links, references, and a newsletter that summarizes the latest developments and findings in the field of green IT. We also learned about the SCI (Software Carbon Intensity) Specification, a standard for the sustainability assessment of software systems. This was back in autumn 2023, when the SCI was not yet an official standard - so it only became clear to us over time that the standard is really comparable to a DIN standard. The SCI is therefore not intended for direct application but as a basis for implementation of specific tools.
As we were not aware of this at the time, we tried to apply the SCI specification directly to determine the carbon footprint of software systems. As part of a focus day, we looked at a small, well-defined part of one of our customer projects. Even with this small software system, it was very time-consuming to collect all the required data. We had to use estimates for some values, as the project's split runtime environment sometimes did not allow us to make precise statements or we simply could not find any precise information. The required values had (and still have) to be gathered from a variety of sources, and getting data from the major cloud providers is a challenge in its own. After it took us a whole day to calculate the CO2 emissions of an API request and we were very unsure about the validity of the result, we asked ourselves whether Ratiopharm might already have something to offer.
This brought us back to the GSF Impact Framework (IF), which we were already familiar with at the time, but which seemed far too complicated. After our experience with the SCI specification, we were no longer frightened by the initially perceived complexity of the IF. Especially since, according to its own statement, the IF aims to make the environmental impact of software quick and easy to determine and share.
The Impact Framework enables the flexible calculation of the CO2 footprint of software systems at different points in their lifecycles. To use the IF, an idea of the system architecture is sufficient. In contrast to other tools (such as the Cloud Carbon Footprint Tool), it is not necessary for the components to have already been implemented and deployed (and under load) in their target environment. This makes the IF ideal for considering variants before changing cloud providers, for estimating new systems and for modeling architectural ideas for new systems.
The IF examines the carbon footprint of a system based on the (expected) resources used in the target environment. The fine-grained consideration at code level (as possible with the help of EcoSonar, for example) is not included.
The IF allows to create models of software systems with the help of a pipeline consisting of the phases Observe (data collection), Regroup (grouping and sorting the collected data) and Compute (impact calculation on the previously provided data basis). The individual phases are each implemented by one or more plugins. These provide data from static or dynamic sources, transform this data and calculate the impact of the system. The individual phases can be executed all together or individually. For example, data collection, which is usually time-consuming and resource-intensive, can only be carried out as required and different variants can then be considered based on the data that has already been collected.
The system to be examined is modeled within a yaml file called manifest. This contains general information about the system (context), A representation of the system structure (tree) and the definition of the pipeline with its three phases. The individual phases are each described using plugins and, if required by the plugin, input values (inputs) can be defined. The manifest is then executed with the impact engine via the command line. You can define which phases of the pipeline should be executed. The result (output) is created in the previously defined way (for example as a yaml file or on the command line). The result consists of the manifest, which is supplemented by further information on the individual plugins (explain) and the intermediate and final results of the calculation (outputs).
This means that the values determined with an IF pipeline are strongly dependent on the plugins which were used. Currently, plugins are mainly available for determining the CO2 footprint. However, if the appropriate plugins are used, it is also possible to determine other values, such as water consumption.
The plugins are divided into built-in and community-owned plugins. Built-in plugins are developed and maintained by the GSF itself and, like the framework itself, are published open source under the MIT license. Currently, the built-in plugins are still limited in number and functionality, but very active development work is taking place. Community-owned plugins are community projects that depend heavily on the needs and activity of the community. With the help of community-owned plugins, individually required functionality can be implemented and published, covering a wide range of different use cases.
To become familiar with the IF, we first recreated the example used in the documentation and then modeled and calculated our previously mentioned example from the study of the SCI specification. We were pleased to find that we achieved very similar results with both methods. We then began to design and model a complex, prototypical example based on our project experience. At this point, we got introduced to one of the disadvantages a project in incubation status can have. We were surprised by breaking changes, which ultimately led us not to finish modeling our example, but to continue working on other aspects.
We are currently working on ways to make the IF more usable and, above all, automated. Our aim is to develop p-lugins (plugins the pentacor way) within the observe phase that collect data dynamically from systems such as Datadog. In the future, we want to develop a workflow that makes it possible to automatically determine the carbon footprint of a system in CI/CD pipelines and thus monitor systems in their development over their lifetime. In the next step, this will open up opportunities to recognize promptly when the CO2 footprint of a system changes over time. With the help of such monitoring, targeted measures can then be taken, for example to avoid the constant growth of a system's carbon footprint.
Over the past year, we have been able to build up a lot of knowledge and gain insights into how the environmental impact of software systems can be determined. We have discovered that it is already possible to determine the carbon footprint of software and that this may also be automated in the future. Currently, the practical usability of the IF is still limited, as the number of available plugins is small and only systems from certain providers are supported. From our point of view, a lot of development is still required before productive use is possible. However, the basic approach of the IF seems promising to us and we want to keep an eye on it, follow it and possibly help shape it.
We have also found that topics relating to green IT and sustainability in software development are good topics to talk about, with which we have been able to make contacts and have inspiring conversations at conferences and meetups. At the same time, it is a huge range of topics, of which currently only the same few aspects are highlighted and discussed. By measuring the CO2 footprint, we want to explore another topic area and make it better known.
Stay tuned!
