Softwareentwicklung und Nachhaltigkeit?

 

Kaum ein Wort wurde in den letzten Jahren häufiger und kontroverser diskutiert als „Nachhaltigkeit“. Jedes mögliche Produkt unseres alltäglichen Lebens, die eigene Lebensweise – prinzipiell alles soll vor dem Hintergrund des Natur- und Umweltschutzes auf Langlebigkeit ausgelegt sein. Hier stellt sich jedoch die Frage, ob etwas Nichtgreifbares wie Software überhaupt nachhaltig gestaltet werden kann oder ob sie schon von Natur aus nachhaltig ist.

von Patrick Schnell

Betrachtet man bei dieser, zugegeben auf den ersten Blick sehr philosophisch wirkenden Frage, systematisch den gesamten Lebenszyklus einer Software (also von der ersten Spezifikation über die Umsetzung bis hin zu einem Betrieb von mehreren Jahren), stellt man fest, dass es hier teils drastische Unterschiede in jedem Abschnitt gibt. Auf diese einzelnen Zyklen und deren unterschiedlichen Umsetzungsvarianten möchte ich eingehen, um aufzuzeigen, dass Software sehr wohl nachhaltig oder eben – aufgrund falscher Annahmen – relativ ressourcenhungrig umgesetzt werden kann.

Wie möchten wir Nachhaltigkeit in der Software definieren?

Wenn wir uns beispielsweise die Produktion eines Automobils ansehen, so haben wir sämtliche Ressourcen, die benötigt werden, plastisch vor Augen. Diese reichen von der Erzeugung der Rohstoffe, die entsprechende Produktion und damit verbundene Energie und Arbeitskraft, über die Prototypen- und Zulassungsphase, bei der eine nicht unerhebliche Anzahl an Produkten entstehen, die jedoch effektiv nie auf den Markt kommen, bis hin zum tagtäglichen Betrieb eines solchen Fahrzeugs. Da wir hier mit materiellen und für uns selbstverständlichen Ressourcen umgehen, fällt es natürlich leichter, zu identifizieren, welcher Aufwand dahintersteckt.

Viele Entwickler und Softwareunternehmen werden sicherlich schon von Kunden darauf angesprochen worden sein, wieso ein Feature oder der Betrieb so teuer ist. Das erscheint doch schnell umgesetzt und in der Cloud ist doch sowieso alles so einfach. Entwickler und ihre Projektleiter wissen jedoch genau, dass in jeder kleinen Anpassung ein erhöhter Aufwand steckt und dieser Aufwand selbst eine gegebene Nachhaltigkeit beeinträchtigt.

Welche Arbeitsschritte benötigen also Ressourcen, um ein fertiges Softwareprodukt zu betreiben? In diesem Fall wird Nachhaltigkeit nicht nur über den reinen Energieverbrauch im Sinne von Strom oder CO₂ und Materialressourcen, sondern auch über die Arbeitskraft und Langlebigkeit allgemein definiert. Wo wird also Energie benötigt und aus welcher eingesetzten Arbeit und Energie können unsere Kunden und wir möglichst langfristig einen großen Nutzen ziehen? Wir müssen uns sowohl Arbeitsleistung und -zeit im Projektmanagement, der Entwicklung und dem Betrieb ansehen. Im Falle der Entwicklung kommt hier zusätzlich eine langfristig angelegte Softwarearchitektur und -erweiterbarkeit dazu sowie die Sparsamkeit eines Codes. Egal, ob dies nun in Richtung Speicherplatz geht oder mit optimierten Algorithmen oder einer möglichst einfach gehaltenen Kommunikation zu tun hat. Im Falle des Projektmanagements fallen hier zusätzlich ggf. notwendige Reisen und auch hier das Abschätzen und Abwägen zwischen langfristigen und ggf. komplexen Systemen oder dem pragmatischen Ansatz an. Der größte und mit Sicherheit der Bereich, in dem die größte Nachhaltigkeit erzielt werden kann, ist der Betrieb. Eine Software mag sicherlich auch in einer langen Projektphase stetig wachsen und erweitert werden, der Betrieb und das entsprechende Paradigma (on Premises, Cloud oder Serverless) bleibt jedoch meist für Jahre bestehen.

Projektmanagement effizient gestalten

Auf den ersten Blick erscheint es, als ob man im Projekt- oder Produktmanagement relativ wenig hinsichtlich der Nachhaltigkeit eines Softwareprodukts über die gesamte Lebenszeit auswirken kann. Man nimmt Anforderungen des Kunden auf, definiert entsprechende Umsetzungsvarianten und die notwendigen Zeitpläne. Eigentlich doch alles sehr straightforward, richtig? Doch gerade hier werden die Grundsteine für Nachhaltigkeit gelegt und das entsprechende Mindset gestaltet.

In den letzten beiden Jahren konnten wir alle weltweit erleben, wie Projekte von jetzt auf gleich über große Distanzen komplett remote durchgeführt wurden. Viele moderne Agenturen oder Start-ups arbeiteten bereits seit einigen Jahren mit diesem Fokus. Dennoch gibt es eine Vielzahl von Unternehmen, die oft eine bereits längere Geschichte haben oder gar mit Kunden arbeiten, die nicht so offen für Innovationen und eine progressive Arbeitsweise sind und regelmäßig für etwaige Stunden den Projektleiter mehrere hunderte Kilometer reisen lassen. Selbstverständlich darf man hier die Welt nicht in Schwarz und Weiß einteilen, selbst moderne Start-ups werden zu diversen Terminen auch mal einen Projektleiter zum Kunden schicken, wenn es ein Kick-off-Meeting ist oder es gerade irgendwo dramatisch knirscht. Doch wer sich als ein modernes und nachhaltiges Unternehmen verstehen will, darf keinesfalls den Fehler begehen, in der heutigen Zeit einen größeren Aufwand in Reisen zu betreiben. Das macht unglaubwürdig und treibt natürlich auch die Kosten für den Betrieb und den Kunden in die Höhe.

Ein weiterer Aspekt im nachhaltigen Projektmanagement muss der entsprechende Weitblick der Lösung auf mehrere Jahre sein. Oft wird versucht, dem Kunden relativ schnell ein für ihn passendes Angebot zu unterbreiten. Dabei übersieht man häufig wesentliche Punkte, die sich spätestens im Betrieb oder bei Erweiterungen des Projekts rächen werden. Wenn Sie und Ihr Kunde sich darüber einig sind, dass Sie eine Lösung schaffen wollen, die auf Jahre einen großen Nutzen bringt und möglichst ressourcenschonend ist, kommunizieren Sie das deutlich und committen Sie sich darauf. Aus dieser Herangehensweise kann der Kunde selbst zum einen seine Ziele und Anforderungen intern ganz anders definieren, was auch dem Entwickler helfen wird, entsprechend zu generalisieren oder zu abstrahieren. Andererseits ist auch die Softwarearchitektur entsprechend vom Team vorzubereiten und es bieten sich hier Möglichkeiten, langfristig zu planen und entsprechend zu generalisieren und zu abstrahieren. Also das, was die Entwickler gerne mit einem sauberen Entwicklungsstil gleichsetzen: Keine Lösungen, die den Kunden schnell befriedigen, jedoch bei jeder Anpassung einem Entwickler schon nach wenigen Monaten den Angstschweiß ausbrechen lassen, da er genau weiß, dass diverse Änderungen wieder ungeahnte Probleme mit sich bringen werden.

Wird also in einem solchen Projekt dieses Mindset aktiv beworben und mit dem Kunden gemeinschaftlich gelebt, können unzählige Stunden besser in eine durchdachte Anforderungs- und Umsetzungsdefinition investiert werden. Das bringt beide Parteien in eine spürbare und messbare Win-win-Situation.

Softwarearchitektur

Neben der menschlichen Komponente, die hauptsächlich im Projektmanagement zum Tragen kommt, befassen wir uns hier hauptsächlich mit den technischen Kriterien einer nachhaltigen Software. Doch keine Sorge, hier geht es jetzt nicht darum, dass es doch so viel besser wäre, wenn Sie eine Programmiersprache nutzen, die nicht interpretiert ist, oder beim Einlesen von Dateien das Rad neu erfinden und am besten Byte für Byte die Daten auslesen und nur überoptimierte und sparsame Datenbanken nutzen sollen. Das sind zwar rein logisch und rational betrachtet mit Sicherheit auch mögliche Wege, wenn man CPU- und speichereffizient arbeiten möchte. Jedoch geht das an der Praxis vorbei und hat nichts mit grundlegend modernen Softwarearchitekturen zu tun. Im schlimmsten Falle sind die Nachteile, die Sie damit einkaufen, um ein Vielfaches höher als der angedachte Nutzen.

Da wären wir auch schon bei der ersten und wichtigsten Regel – Aufwand/Risiko und Nutzen einander immer gegenüberstellen. Selbstverständlich kann man in die Anfänge der 1990er Jahre zurückblicken und erkennen, dass damals auch relativ komplexe Anwendungen oder gar Spiele auf Disketten mit 1,44 MB ausgeliefert wurden. Sparsam war das allemal. Doch Sparsamkeit hat nicht immer etwas mit Nachhaltigkeit zu tun. Ich wage zu bezweifeln, dass eine damals gewählte und sich sehr der Datensparsamkeit unterordnende Softwarearchitektur langfristig modular warten und erweitern ließ. Ein Beispiel ist das Jahr-2000-Problem. Hier hat sich auf sehr prominente Weise gezeigt, was es bedeutet, aufgrund technischer Rahmenkriterien (ja, Speicher war damals absolut limitiert) auf Kurzfristigkeit zu setzen. Stellen Sie sich vor, wie das Web oder moderne Anwendungen aussähen, wenn man heute mit binären Blobs arbeiten würde (ohne entsprechendem Datenschema) und Sie diese Byte für Byte interpretieren und mit Steuerzeichen entsprechend auftrennen müssten. Das ist sicher effizient und wird z. B. bei industriellen Schnittstellen genutzt – Interoperabilität oder gar die Möglichkeit später auf andere Plattformen/Architekturen umzuschwenken, wird damit aber wesentlich beschränkt.

Die Komponenten, die demnach am längsten in einem Softwarekonstrukt am Leben bleiben oder gar über Generationen mitgetragen werden, sind die Datenhaltung und Persistenz. Versuchen Sie hier nicht, das Rad neu zu erfinden, sondern untersuchen Sie konkret den (Open-Source-)Markt nach passenden Datenformaten oder Datenbanken. Viele Anwendungen arbeiten selbst verständlicherweise objektorientiert, nutzen aber dann OR-Mapper und eine SQL-Datenbank, um die Daten zu persistieren. Haben Sie einen konkreten und strukturellen Nutzen von diesen Relationen, ist dieses Vorgehen natürlich gerechtfertigt. Jedoch unterstützen NoSQL- und Graphdatenbanken ebenfalls performante Relationen, sind aber im Falle von Anpassungen am Schema oder der Zusammenarbeit mit dem Client oder der Geschäftslogik weitaus flexibler. Immerhin nutzen Sie dort die exakt gleichen Objekte, die die Datenbank auch nutzt. Der gesamte Mapping-Prozess und damit nicht nur Prozess-Overhead, sondern auch Entwicklungsaufwand und vor allem eine weitere Fehlerquelle fallen weg. Ein weiterer Vorteil vieler objekt- und dokumentenorientierten Datenbanken ist, dass diese unter den meisten Bedingungen wesentlich weniger wartungsintensiv sind.

Die nächsten Komponenten, die einen langfristigen Aufbau und Betrieb benötigen, sind Schnittstellen. Definierte Schnittstellen sind oft nur über mehrere Generationen oder Iterationen hinweg abzulösen, wenn sie aktiv von Drittsystemen genutzt werden. Hier ist demnach genauso wie im Falle der Datenstrukturen darauf zu achten, dass möglichst alle Informationen in einem offenen und interoperablen Format geliefert oder entgegengenommen werden. Des Weiteren sollten Schnittstellen der Möglichkeit nach entweder mittels vorrangiger Webtechniken (Web-APIs/REST, WebHooks, Web-Sockets etc.) oder mit allgemeinen und einfach austauschbaren Kommunikationssystemen (z. B. Message Queues) umgesetzt werden. Das macht die Nutzung von Schnittstellen zum einen durch Dritte wesentlich einfacher und entsprechende Erweiterungen können so umgesetzt werden, dass sie keine Breaking Changes auf der Gegenseite verursachen. Ein zusätzlicher Aspekt ist es, gerade im Falle von Web-APIs die Schnittstellen entsprechend den Use-Cases zu bauen. Oftmals fallen Entwickler in die Falle, einfache CRUD-Operationen abzubilden, ohne die 70 Prozent der am meisten genutzten Use Cases zu bedenken und dafür optimierte Operationen anzubieten. Das führt häufig dazu, dass die Gegenseite zwei oder mehrere Abfragen absetzen muss, um einen Anwendungsfall abzubilden. Auch das ist ein vermeidbarer Overhead und damit ressourcenschonender Umgang, der zudem eine Arbeitsentlastung für die Seite der Implementation darstellen kann.

Die oben genannten Punkte sind essenziell im Rahmen der Softwarearchitektur – doch bis dahin ist noch keine Zeile Code für die Geschäftslogik entstanden. Auch hier stellt sich die Frage, welche Entscheidungen man treffen und welche Schritte man unternehmen kann, um eine möglichst nachhaltige Anwendung zu bauen. In den letzten knapp fünf Jahren wurde viel über das Auftrennen von Monolithen in Microservices gesprochen. Diese Diskussion ging von der Geschäftslogik bis hin zu den Benutzeroberflächen und sie ist sicherlich richtig und wichtig bei der Entwicklung mit vielen Entwicklern und mehreren Teams. Es ist also wie bei jedem Projekt sehr klar abzuwägen, wie weit man Komponenten als eigenständige Dienste auslagern will, oder ob man dadurch mehr Overhead produziert und das im Rahmen des Betriebs und Monitorings wieder einbüßt. Ein gewisser Kompromiss hilft, die Waage zwischen der Möglichkeit, schnell Anpassungen umzusetzen, und dem entsprechend höheren Komplexitäts- und Wartungsaufwand, den eine hoch mikronisierte Architektur mit sich bringt, zu halten.

Nicht um den heißen Brei herumreden und auf den Punkt kommen

Die ausgeklügelste Softwarearchitektur kann schnell zunichte gemacht werden, wenn Entwickler in einem Team nicht nach den gleichen Grundsätzen zusammenarbeiten möchten oder können. Hierbei muss eine gemeinsame Basis geschaffen werden, was unter anderem Coding Guidelines oder auch Abstraktionen angeht.

Was aber haben Coding-Guidelines mit einer nachhaltigen Software zu tun? Hierbei geht es nicht darum, wie Variablen oder Datenstrukturen benannt werden, ob und wie Methoden und Funktionen kommentiert werden oder gar wie man Klammersetzungen durchführt. Hier geht es eher darum, wie externe Pakete und Frameworks genutzt werden sollen oder wie Abfragen gebaut werden. Nehmen wir das Fallbeispiel, dass in der Datenbank oder einer Enumeration im Allgemeinen in einem Feld nach einem Text gesucht werden muss, so sollten natürlich folgende Fälle betrachtet und möglichst einheitlich (die Ausnahme bestätigt die Regel) im Team von jedem Einzelnen beachtet und so durchgeführt werden. Für diesen Fall haben wir drei verschiedene Lösungswege:

Ich baue eine Abfrage mit meinem Datenbank-API (SQL oder z. B. eine MongoDB-Query) und nutze die in der Datenbank dafür vorgesehenen Funktionen (in SQL z. B. LIKE). Die zweite Variante wäre das Suchen in der Datenbank über eine Regular Expression. Die dritte und für diesen Fall offensichtlich schlechteste Variante wäre, entweder alle Daten oder wenigstens ein Subset der Tabelle/Collection) in die Anwendung zu laden und dort zu iterieren. Das würde sowohl weitaus höhere Speicher- als auch Rechenleistung aufseiten der Datenbank und Applikationslogik erfordern. Alle drei Varianten bringen das gewünschte Ergebnis und würden in einem Unit-Test das korrekte Ergebnis liefern.

Jedoch würde bei einem Lasttest wohl die erste Variante den höchsten Durchsatz bringen, da diese Funktionen direkt in der Datenbank durchgeführt und dafür optimiert worden sind. Die zweite Variante beinhaltet immer noch das Problem, dass die Regular Expression im schlechtesten Falle nicht korrekt gebaut und an die Datenbank geliefert wird. Oder gar, dass die Regular Expression auf der Datenbankseite einfach nicht so performant ist wie die direkt integrierte Funktion. Diese Fälle sind hier natürlich sehr vereinfacht dargestellt und können je nach Datenbanksystem entsprechend variieren. Es gilt jedoch aufzuzeigen, dass nur durch reine Funktionstests und ggf. auch Lasttests nicht immer der optimale Weg gefunden werden kann und hier im Zweifelsfall im Team ein Augenmerk darauf gelegt werden muss, welche Variante man einsetzen möchte.

Je mehr man über Softwarearchitektur nachdenkt, desto mehr Möglichkeiten zur Abstraktion und zum Bauen entsprechender Ebenen und teils auch zur Generalisierung von Klassen und Funktionen tauchen auf. Prinzipiell ist das keine schlechte Idee und dient auf den ersten Blick natürlich auch der Nachhaltigkeit und langfristigen Wartungsfähigkeit einer Anwendung. Jedoch birgt es auch die Gefahr, in ein Konstrukt zu gelangen, Software schwerfälliger und schwerer wartbar zu gestalten. Gerade im Rahmen von Neueinstellungen oder der Auslagerung an andere Entwickler kann es zu großen Hindernissen und Fehlerquellen kommen, wenn man für eine vermeintlich einfache Erweiterung an zahlreichen Stellen Interfaces anpassen, adaptieren und implementieren muss. Auf Seite der Performance jedoch stellen mehrere Abstraktionsebenen durch mittlerweile sehr optimierte Interpreten oder Compiler kaum mehr ein Problem dar. Aus diesem Grund kann man nur auf die erste Regel verweisen und gerade in der Architekturphase eines Projekts darauf hinweisen, hier wirklich Risiko und Nutzen abzuwägen.

Zusammengefasst kann man also sagen, dass ein nachhaltiger und langfristig wartbarer Code schlicht verständlich, nachvollziehbar und ohne unnötig erhöhten Einarbeitungsaufwand auch von neuen oder externen Entwickler:innen verstanden und bearbeitet werden soll. Teams, die sich auf die Grundsätze des Clean Code beziehen, haben hier schon mal einen guten Ansatz.

Der Betrieb als Achillesferse

Die entsprechende Architektur der Anwendung hat selbstverständlich Auswirkungen auf die Möglichkeiten der Art und Weise des Betriebs einer Software. Ziel muss es sein, möglichst nur die Ressourcen bereitzustellen, die die eigene Anwendung benötigt und möglichst wenig überschüssige Ressourcen zu verbrauchen. Mit jeder physisch bereitgestellten Ressource (egal ob CPU, Arbeitsspeicher oder Datenspeicher) ist ein entsprechender Energie- und Verwaltungsaufwand verbunden. Gerade in den letzten zehn Jahren ist durch technische Maßnahmen der Energieverbrauch in Abhängigkeit der Leistungsfähigkeit der Hardware gesunken. Ob das optimierten Netzwerken, modernen Prozessorarchitekturen oder einer besseren Ressourcenverwaltung in der Cloud zuzuschreiben ist? Klar ist, dass Cloud-Computing zwar immer mehr Energie benötigt, jedoch durch z. B. Auslagerungen und das Teilen von Ressourcen zwischen unterschiedlichen Kunden im Endeffekt eine Entlastung bietet, und dass ein Verschiebungseffekt zu beobachten ist. Wer sich im Detail damit auseinandersetzen möchte, kann den Sachstand des Energieverbrauchs von Rechenzentren [1] als Lektüre heranziehen.

Eine Anwendung die z. B. nicht auf Anwendungsebene virtualisiert werden kann (z. B. nicht als Docker-Container läuft), gleichzeitig aber auf systemweite Frameworks oder Ressourcen angewiesen ist (z. B. einen IIS-Server, NGINX oder eine feste Framework-Version) hat schnell das Problem, als eigene Instanz hardwarevirtualisiert betrieben zu werden. Dadurch verfällt man in den Betrieb des Betriebssystems pro Anwendung auf dem virtuellen Host mit allen entsprechenden Nachteilen, wie z. B. reservierter und auch durch das Betriebssystem benötigter Arbeits- und Datenspeicher der zusätzlich bereitgestellt werden muss. Jede einzelne Instanz hat hier wiederum Jobs und Updatezyklen, die zusätzlich CPU-Zeit und Leistungsressourcen benötigen. Demnach ist in der modernen Anwendungsentwicklung (hier natürlich auf Backend- und Serversysteme bezogen) die Nutzung containerisierter Anwendungen ein großer Vorteil in Hinblick auf den geforderten und ggf. überschüssigen Energieverbrauch.

Ganz besonders deutlich wird das im Rahmen der Betrachtung von On-Premise- oder Cloud-gehosteter Hardware. Gehen wir von den Annahmen aus, dass unsere Anwendung bereits als Docker-Container lauffähig ist und wir sowohl on Premise als auch in der Cloud ausschließlich einen Server oder eine virtuelle Maschine benötigen, der/die als Docker-Host dient, und dass sämtliche Komponenten auf einem Host laufen können. Erfahrungsgemäß ist der Betrieb einer kritischen Anwendung on Premise immer energiehungriger als in einem Rechenzentrum mit entsprechend vorhandener Infrastruktur und zwischen vielen Kunden geteilten Ressourcen (z. B. Router/Firewall etc.). Ausgehend davon, dass man keine Bestandssysteme hat, stellt sich klar heraus, dass sowohl die initialen Kosten als auch der Betrieb und Energieverbrauch einzelner Komponenten (ob Klimatisierung, Netzwerk, VM-Hosts – gegebenenfalls sogar geclustert –, unterbrechungsfreie Stromversorgungen) in diesem Fall weitaus höher liegen werden. Hier kommen relativ schnell Investitionskosten im höheren vierstelligen Bereich und Energiekosten von mehreren hundert Euro im Jahr zusammen.

Nutzt man also verfügbare Rechenzentren oder Cloud-anbieter und teilweise sogar verwaltete Komponenten (z. B. Load Balancer) und vermeidet zusätzlich reservierte Ressourcen (CPU/Speicher), ist das zum einem oftmals nicht nur günstiger, sondern auch noch weitaus ressourcenschonender. Ebenfalls lassen sich Ausfallsicherheiten oder Back-up-Systeme weitaus einfacher umsetzen, als sich selbst um das Back-up-Management, Floating IPs oder sonstiges kümmern zu müssen. Auf diesen Grundsatz stützen sich natürlich auch die Cloud-anbieter, die entsprechende Studien in Auftrag geben und sich als besonders energieeffizient betiteln [2]. Inwieweit das jedoch für das eigene Projekt und die technischen Anforderungen geeignet ist, lässt sich sicher nicht pauschal sagen.

Fazit

Wie man diesem Artikel entnehmen kann, hängen Entscheidungen, die teilweise ganz am Anfang des Projekts getätigt wurden, ggf. nicht mal von der Personengruppe, die eine Software betreiben soll, und Nachhaltigkeit eng zusammen. Demnach ist es unerlässlich, sämtliche Parteien zu Beginn eines Projekts auf eine Linie einzuschwören und von allen Seiten die entsprechende Unterstützung zu haben. Wenn die Softwarearchitektur so gewählt wird, dass der Betrieb entsprechend ressourcenhungrig gestaltet werden muss, kann das später im Sinne der Nachhaltigkeit nicht mehr herausgeholt werden. All diesen Faktoren ist die entsprechende Bedarfsoptimierung zugrunde gelegt, um indirekte Emissionen oder Ressourcenverbrauch zu vermeiden.

Demnach bleibt zu sagen: Nein, Softwareentwicklung ist eben nicht von Haus aus nachhaltig, da ihre Umsetzung nicht nur die Wartbarkeit beinhaltet, sondern auch einen direkten Einfluss auf den Betrieb und die dafür benötigten Ressourcen hat. Um Software nachhaltig zu entwickeln, ist es nötig, den gesamten Lebenszyklus im Auge zu behalten sowie eine grundsätzliche Einstellung aller beteiligten Personen im Team sowie des Kunden zu etablieren. Selbstverständlich sind die Auswirkungen und die Machbarkeit in jedem Projekt individuell und teilweise stark unterschiedlich ausgeprägt. Eine grobe Richtlinie ist jedoch ersichtlich. Wird dieser Gedankenwechsel jedoch im Sinne der langfristigen Architektur, Wartbarkeit, Modularität/Erweiterbarkeit und eines flexiblen Betriebs durchgeführt, kann man hier eine hohe Nachhaltigkeit erzielen.