Sustainable software architectures: energy efficiency as a design goal

Contents

For IT specialists and software architects, sustainability is an important aspect of their work and the crucial keyword here is energy consumption. The Borderstep Institute describes this in relation to Germany in 2024 as follows "Between 2010 and 2024, the electricity consumption of data centers and smaller IT installations increased by over 90% to almost 20 billion kWh per year. [...] The accelerated growth of the data center industry will inevitably lead to a further increase in energy demand. By 2030, data centers in Germany are expected to consume slightly more than 30 billion kilowatt hours of electricity per year. This forecast considers the requirements of the Energy Efficiency Act and assumes a significant improvement in the efficiency of building technology [...] The greenhouse gas emissions generated by the electricity consumption of data centers will decrease significantly in Germany because the electricity supply is increasingly being converted to renewable energies. They are expected to fall by 30 % by 2030".

Uwe Neukam

Uwe Neukam ist Software Architect bei DATEV eG und hat in mehr als 20 Berufsjahren in mehreren Unternehmen den Wandel von on-premises Entwicklung hin zur Webentwicklung begleitet. In individuellen Analysen und auf das Unternehmen zugeschnittenen Umsetzungen sieht er den Schlüssel dafür.

Noah Neukam

Als Grenzgänger zwischen Software Engineer und Software Architect ist Noah Neukam von ITech Progress in Web-Architekturen heimisch. Seine Steckenpferde sind qualitätsgetriebene Softwarearchitekturarbeit, Kommunikation und Umfeld, sowie die Auswirkungen von Strukturen und Strukturmustern auf Software.

The role of software in CO₂ savings

Sustainability has many facets, as a look at the UN Sustainable Development Goals shows. Bitkom 's definition (2021) in the "Resource-efficient programming" environment also defines the term very broadly, as the following excerpt from the definition shows:

"Sustainable development that meets the needs of the present without risking future generations not being able to meet their own needs [...]."

The crucial question, however, is: Where can we have a direct influence on the development of software? The most obvious aspect is clearly the energy consumption of IT, which is always present in day-to-day operations. Why is this so important? In general, software is not an end in itself, but rather a support for tasks and problems in daily life. So it can happen that an activity of a person that is succinct in itself generates a very high energy consumption in total. Let's take a Google search query as an example. It has an average power consumption of 0.3 watts. Depending on which models are followed, an average volume of 75,000 search queries per second per year generates an electricity requirement of around 720 GWh. This corresponds to around 400,000 single households in Germany. With the advent of AI-supported systems , consumption has increased tenfold.

Although hardware is becoming increasingly efficient in terms of consumption, user behavior (example: "How many streaming services have I subscribed to?") and the software on offer often eat up the savings again. More and more hardware is needed to keep up with the constantly growing range of software. As a result, energy consumption is constantly increasing.

Base load of a software architecture

When looking at the daily work of software architects, the idea quickly arises that the energy consumption of the respective architecture should be easy to determine. The introduction of an energy label would be a suitable measure for this, which would put a CO₂ price tag on the software. Unfortunately, it is not so easy to do, because the software architecture is an important component, but not the only one, that has an influence on energy consumption.

Other factors include the implementation of the software architecture and the use of the software by the user. If you look at the past, you can see time and again that applications have been misused. The classic example of extensive use outside of the originally intended purpose is Microsoft Excel. The system is now used for many use cases, which on the one hand shows creativity in dealing with systems, but, as already mentioned, makes control impossible.

When implementing the software architecture, it can happen that unnecessarily complicated lines of code creep in. In order to still meet the quality requirements, more hardware than planned is ultimately required in software operation.

These examples show how complex the issue of software energy consumption is. There are a number of factors that can influence this, and the software architecture also plays a role. How can we determine what constitutes good or bad software design in terms of sustainability? Are two microservices more sustainable than one? Is a monolith more inefficient than microservices? Development teams and management expect answers to these questions.

What influences energy consumption?

Given the complexity of the situation, the obvious question is: is there a way to reduce the energy consumption of software? Many software manufacturers are now aware of the importance of this issue and are issuing recommendations or instructions accordingly. But here, too, the following applies: what works for one company does not necessarily lead to success for another. Markus Eisele from Red Hat has formulated a sequence that we are happy to follow:

• Data design, use and storage: less is more here! Developers tend to work in a future-proof way: "It may be that this is needed." This often leads to overprovisioning, so that more data than necessary is distributed across the networks, for example. Or many accesses are forwarded to data storage, even if this is not necessary. Developers should check the power consumption generated by saving or deleting data on a hard disk.
• Application design: The internet has made it possible for software to always be available. This "always on" has the same effect as standby mode for household appliances. The resources provided are not actually used. Most applications still work synchronously, even though many of their processes could be parallelized.
• Platform provisioning, utilization and scaling: This point shows a direct impact of software architectures. Provisioning configurations can lead to the need for additional hardware. Although this is usually not the main issue in terms of sustainability (developers only consider the application context), it can trigger a domino effect in the worst-case scenario: Markus Eisele is right when he notes that you may have to look at the configuration in its entirety.
• Code efficiency: Even if developers don't like to hear it: The most efficient code is no code. When writing code, they should pay attention to the workload right from the design stage.
• Operation: Cloud systems offer high computing density for their managed service offerings. Compared to self-virtualized application servers in the cloud, users can run more software on less hardware. You should definitely take advantage of this.