So, hello and welcome to my talk about green software engineering and more specifically
about building energy measurement tools and ecosystems around software.
My name is Arne and I work for Green Coding Berlin, which is a company that specializes
in making open source tools for energy aware software measurement.
I would like to take you on a tour today of a concept for a possible future ecosystem
we imagine where energy consumption of software is a first world metric and available for
every developer and user.
So let's have a look at a hypothetical scenario.
The Windows 10 operating system typically comes with a minimum system requirements.
So if you look on the vendors web page, you can see it has a processor that is needed,
one gigahertz, one gigabyte of RAM, a particular amount of hard disk space, graphics ports,
etc.
However, what is never given is the power on, for instance, idle that this operating system
uses on this reference hardware that it apparently already specifies.
So this should be pretty doable, right?
Also something like power the desktop activity.
So how much power does it use just to go around in the operating system, opening the
file explorer, using the taskbar and stuff like this.
On the reference system, for instance, that with Microsoft specifies or on a reference
system that we or the community specifies.
And imagine then you can make could make informed choices.
So by just saying, hey, I'm looking at Windows 10, and I see that it has 45 watts in idle.
But apparently, my computer is mostly in idle.
So it might be more interesting to use Ubuntu, for instance, which has just 20 watts in idle
or desktop activity is even lower.
So why not choose this operating system if energy is my main concern.
And this is what I, what I cherish the most in the operating system, or which is an important
metric for me.
If you think this process even further, you can think about comparing energy of applications
very specific, not only in the idle scenario or in one scenario, but in very specific usage
scenarios that are ingrained to how people typically use such an application.
What you see here is two radar charts on the left side is WhatsApp, and on the right side
is Telegram.
Please keep in mind that these are concept pictures.
So this is not actually the energy that these application use for this use case.
But let's say your use case is that you message a lot with an app, but you don't do that many
video calls.
So if you look then at WhatsApp, you see here that it has quite a high energy budget when
it comes to messaging, whereas Telegram has quite a lower budget.
Telegram is, however, very bad when it comes to video where WhatsApp could be, for instance,
better.
So let's say that you are mostly doing messaging with your application, and you would like
to keep your battery life, or maybe use Telegram on the desktop, your desktop energy consumption
low, then with such metrics, you could actually make an informed decision if WhatsApp or Telegram
is the better app for you if energy is an important concern.
And imagine as a developer, if you think even one step further, that you go to GitHub or
to GitLab or wherever your software is hosted, and you look in the repository and you see
right away with something like an open energy batch, how we call it internally, to see how
much the software, you see it down here, how much the software is actually using for its
intended use case that the developer of the software had in mind.
So you can compare one software that maybe has very limited use case to another software
or library, just by the energy budget, because you have the metrics so readily available.
We actually try to build these tools, and I would like to take you in this very short
time frame that we have been given by FOSDAM, so just about 20 minutes, I would like you
to take a tour through our projects that we are doing, more as an appetizer, so you see
what we are working on and what we think could be possible or a possible ecosystem in the
future.
You will be presented with a view that looks like such, so the green metrics tool, EcoCI,
Open Energy Badge and Cloud Energy.
So the green metrics tool is what I would like to talk about today, mostly, because
I think it is the tool that outlines our concept of transparency in the software community
the best, and then we'll talk about later about our approaches for CI pipelines or restricted
environments like the cloud.
So first of all, I think it makes sense, although I know people tend to hate diagrams
or flowcharts to some degree, but I think it makes sense to quickly go over how the concept
of the tool works from a high-level perspective.
So in order to measure software, we follow the container-based approach.
So we assume that your software is already in a containerized format or can be put in
such a format.
So for instance, even a Firefox browser, if you want to measure desktop applications,
can be put in a container and be measured with our tool.
Also machine learning applications, simple command line applications, but also web applications.
Typically when you develop software, you already have infrastructure files like Docker files,
Docker compose file, or even a Kubernetes file available, which our tool can consume
in all fairness, Kubernetes is still a work in progress, but Docker files can consume.
And then what the tool basically orchestrates the containers and attaches every reporter
that you want in terms of measuring metrics.
So here we are still very similar to typical data logging approaches like Datadoc does
it for instance, or other big players.
So the memory, the AC power, DC power, the network traffic, CPU percentage, CPU and RAM
is all locked during the execution of what we call a standard usage scenario.
So in the first couple of slides, I've shown you the concept of looking at software from
how is it typically used.
And people already have thought about this concept quite a lot when they make end-to-end
tests with their software, because this is a typical flow that a user goes through in
your application, or unit tests, which might be very reduced amounts of functionality that
is tested in a block, or benchmarks that are already inside of the software repository,
session replays, shell scripts, build files that basically measure where we could measure
your build process.
All of this is already available typically, and our tool can consume these files, will
run these workflows and then tell you the energy budget over the time of this run in
particular.
This slide is more just, if you're not too familiar with Docker, the idea is just to
have every service or every component of the application in a separate container, so that
we can later on better granularize the metrics and better look at which component might be
interesting to look at if you want to do energy optimizations in particular.
When you use the tool, and I will just go quickly over that and then probably go with
you through a live version of what we are hosting at the moment, you will get a lot
of metrics.
So you will obviously get something like the CPU utilization, or the average memory that
was used, or maybe the network bandwidth that was used.
But what is interesting for this dashboard, and basically it's USP, is that you get also
the energy metrics from the CPU, from the memory, you get a calculation what the network
has used in energy, and you get convoluted or basically aggregated values where it makes
often sense to look at CPU and memory in conjunction, or it makes sense to look at all the metrics
that you have available to get something like a total energy budget.
Then you obviously can look also at the AC, so at the wall plugs, so not only what is
your CPU and your RAM using, but what is the total machine using, or something that we
have in our lab as a setup, you just look at the main board, so not on the outside of
the PSU, so what is basically plugged in the desktop computer, but only the power that
flows directly into the main board.
And here you can see that our tool automatically calculates the CO2 budget based on the energy
that it has used for this run.
The tool also shows you which reporters have been used in an overview, and then it tells
you a lot of charts, so this is a sample chart, and what the tool can basically give you is
not only an overview capability, but also an introspection where you, for instance,
are interested in the idle time of the application.
So what is my application doing when no user is interacting with it?
Is it actually using energy, and is this too much energy for my belief or for the belief
of the community?
So for instance, here we have an example of a setup, of a WordPress setup that we have
done with an Apache, a Puppeteer container that runs Chrome, and also a MariaDB instance.
And you can see here that here are a couple of requests that have been done to the WordPress
instance, and then we are basically just idling, but still the web server is doing quite some
work, and there have been no web sockets active, so why is there server and database activity
here? Is this valid, is this maybe some caching, some housekeeping, or is this unintended behavior?
We picture that our tool could highlight such energy hotspot or energy malfunctions, as
we call them, to better understand how software uses energy.
You can also look at energy anomalies, so we work sometimes with features like TurboBoost,
which is typically not turned on in cloud environments, but very often for desktops,
which brings a processor in kind of like an overdrive state so that it can react very
quickly in a frequency above its normal frequency.
However, what we have done here in this example, we have run a constant CPU utilization, but
as you can see here, the CPU clocks at different frequency over the time, and sometimes it
uses exponentially more energy for the same tasks.
So it finishes quicker, but it uses more than only a linear amount more of energy to do
the task.
So this is a very interesting insight that our tool can, for instance, deliver when you
try for energy optimizations of your software.
So what is the whole idea that we have behind all this project? And let me move myself down
here a little bit so you can see the full slide.
We want to create an open source community or a green software community that focuses
on the transparency of software so that you have basically an interface, which we call
the usage scenario, where you can measure software against and then ask later on questions
against a database or against an API, which has measured all these softwares, questions
like how much does this software consume? Is there a more carbon friendly alternative,
or is there a software that makes less energy requests, less network requests?
The idea, if these softwares are available in your country, so Yucca to my knowledge
is, for instance, from the US and code check is more like a German application, is we want
to be the Yucca or the code check of software.
So we want to deliver answers to developers where they can ask questions about the energy
budgeting of a library, of a software, or of a functionality by providing a framework to
make these measurements.
So let me move up here again and then back to the slides.
So let me show you our other tools that we believe are needed to build an ecosystem around
green software because software is not only running in desktop environments or is not
only on a single machine, it also runs a lot in the clouds, where these measurements that
we have, and I would like to encourage you to read a bit on what sensors are available
in our tool, but where these sensors are not available, which is for instance in the cloud.
So let me bring up my browser again.
So if you are on the homepage and you have seen the green metrics tool that I've just
talked about, you'll also see that we have the cloud energy project and the EcoCI project.
So EcoCI focuses on measuring the energy of software in a continuous integration pipeline
that for instance runs in a virtual machine.
Our focus is currently on GitHub actions.
In order to estimate the energy in a virtual machine, because you cannot measure, you have
no access to the wall plug in the data center, you have no access to sensors in the CPU or
whatever, you have to estimate the machine based on measurements that you already have
for the same hardware.
If you click on cloud energy, you can see here that we have based our machine learning
model on a research paper from InterACTC and the University of London, and they have basically
taken the data from the spec power database, which is an open database for servers that
have been measured just with a fixed workload to compare it against each other.
And based on this data, we can create a machine learning model, which is also free and open
source to use, that is just a Python tool, which you call with the information that you
have.
So let's say you have the information that your CPU is from Intel, that the frequency
that you're running is 2.6 gigahertz, you have 7 gigabytes of RAM, and you know the CPU
has 24 threads.
But you don't know any more info.
You don't know if it's a Skylake processor or a more modern internal processor.
You have no more information because the hypervisor limits this to you.
So if you give the model more information, it can give you more accurate estimates, but
it can also work with the limited information in the cloud.
And then it spits out to the standard out the current watchers that you have been using,
and then you can reuse that in a tool that we build upon that.
So now that you've understood that there is a machine learning model behind the idea,
I would like to bring you to EcoCI.
So EcoCI is a GitHub action that is based on the work from the Cloud Energy Project
that can give you in a GitHub action the information of how much a CI pipeline has used in terms
of energy.
So if you go, for instance, to the GitHub repository, you can also go to the marketplace.
So we go one step further.
And here you can see you can directly use it.
It is very easy to use.
It just needs two calls to initialize a tool and then one more call whenever you want to
get a measurement.
And what it does for you, so let's quickly go to our repository where we actually use
GitHub actions to measure every of our workflows in the tool.
So we click on actions, let's say we go to manual test run virtual machine, we click
on main.
And you see here, I've run this run yesterday, it succeeded.
So our log tells us, hey, all tests have to work fine.
So to run a work point fine and also the API.
And for this run in the Azure Cloud where GitHub actions runs as virtual machines, I
have used 650 joules of energy.
And you get a nice ASCII graph over time.
We were a bit limited here in the graphs we can display in the GitHub actions overview.
But you can see here at what point in time the energy, for instance, is the highest and
then maybe look at the later tests if they, if you deem them to be more energy consuming
than for instance at the start where it was using only a fixed amount of energy.
So this gives a developer and also a user the information how much energy is not only
the software using, but also the development of the software is it maybe using more than
we want as developers or maybe even as a community.
And these are all concept tools to just get a first start of what we, what we think could
be possible, of what we think could be possible in a new future where software is basically
measured and the data of the, of its usage is constantly published by developers also.
The idea is then to have something like an open energy batch that is basically in every
repository that tells you for this software and for this usage scenario that comes with
it.
So be it for instance running the tests or be it for instance building the containers
or the intended use case of the software.
So let's say the NumPy library of Python has an energy batch where it says, hey, for 1000
times 1000 metrics multiplication, this software uses this amount of energy on the reference
system that we have specified.
And when you use the same reference systems to compare software against each other, you
come to a scenario that we have basically shown from the starters in the first slides
where you can basically tell is the one software more energy hungry than the other one comparing
the same use case.
So let me quickly get back to my slide deck.
So let's wrap up.
Measuring software energy consumption we believe is still too hard.
The goal should be easy as starting a Docker container and it should happen transparently.
Therefore we have created the green metrics tool which can reuse Docker files and infrastructure
files to make it very easy to orchestrate your architecture.
And then in a flow that you already have, be it a puppeteer file or be it just a shell
script, you can run that with our tool just as a parameter appended and it will tell you
how much energy has been used over this particular scenario that you feed in.
Measuring software is also very complex.
So this is what we have integrated best practices or tool like pausing between measurements,
letting systems idle before you actually use them, turning functionalities like SGX off,
looking at if TurboBoost is on and very more features.
Just inline measuring like Datadoc or other providers are doing it at the moment, we believe
is not enough and is too arbitrary to talk about energy.
Software must be measured against a standard usage case.
So we provide standard usage cases for software as an interface, but we ask you the community
also or we need to see over time what are the standard usage cases we can all agree on.
A software must be comparable to another similar software in terms of energy.
This is why we need these standard usage cases to make it comparable.
This also means it must be measured on reference machines that everybody has access to that
we want to provide for the community as a free service.
Energy metrics must also be available in restricted environments like the cloud.
So I've talked about estimation models that need to be open source and available and for
everybody to implement.
And energy must be transparent and a first order metric and order in developing and using
software.
People should know before they use the software how much energy it is consuming.
And this is what we are trying to achieve with the tools we are developing.
I hope it could pique your interest in our work and in the tools we are developing, some
as concepts, some already production ready.
And thank you for listening and now I hope it's time for questions.