Betrieb nachhaltiger Software

Dies ist der letzte von sechs Teilen meiner Artikelserie über nachhaltige Software. Der vorige Teil findet sich hier, der erste hier.

Im vorigen dieser Teil dieser Serie wurde unter anderem erörtert, dass bestimmte Teile der Entwicklung auf Systemen statt finden sollten, die sich unter Kontrolle der Auftraggeberin befinden. Das gilt ebenso für den Betrieb der Software, der ausschließlich auf Systemen der Auftraggeberin stattfinden sollte.

Lieferantinnen bieten gerne an, auch den Betrieb auf eigenen Systemen zu übernehmen. Davon ist tendenziell abzuraten. Erfahrungsgemäß wird für den Betrieb im eigenen Keller weniger Sorgfalt aufgewendet, als für den Betrieb auf Systemen der Kundinnen. Auch führt ein Betrieb auf Systemen der Lieferantinnen wieder ein Stück weiter in die Abhängigkeit von einer speziellen Lieferantin.

Personal

Um diese Abhängigkeit zu minimieren ist es auch sinnvoll, separates Personal für den Software-Betrieb vorzuhalten. Wenn frühzeitig andere und unabhängige Personen für die Entwicklung der Software und ihren Betrieb zuständig sind, ist die Chance gut, mindestens für den Betrieb anbieterunabhängig zu sein.

Die Aufgaben für den Betrieb von Software bestehen u.a. in Folgendem:

• Überwachung der Hardware auf der die Software läuft
• Überwachung und Pflege des Netzwerkbetriebes des Systems
• Regelmäßige Aktualisierung der Software-Umgebung (z.B. Betriebssystem)
• Aktualisierung der Software

Das für den Betrieb zuständige Personal ist i.d.R. auch die erste Ansprechpartnerin bei Problemen mit der Software. Es ist aber wichtig, langfristig auch Zugriff auf Entwicklerinnen der Software zu behalten. Dies wird im besten Fall nur selten und kurz nötig sein, kann aber in Einzelfällen der einzige Weg sein, bestimmte Probleme im Betrieb zu lösen.

Der Betrieb von Software erfordert völlig andere Kompetenzen als ihre Entwicklung. Letztlich wird es auch kosteneffizienter sein, hier Spezialistinnen einzusetzen. Diese werden bei kleinen und mittleren Projekten wahrscheinlich nur einige Stunden pro Monat mit dem Betrieb beschäftigt sein. Daher liegt ein Outsourcing hier oft nahe.

Container

Für den Betrieb von Software müssen oft sehr spezifische Bedingungen hergestellt werden. Eine einfache Serveranwendung erfordert z.B. i.d.R. mindestens:

• Einen laufenden Webserver
• Eine Betriebssystemkonfiguration, die Anfragen auf diesen Webserver leitet
• Eine Anwendungsumgebung, die die spezifische Anwendung hinter dem Web-Server ausführt (z.B. PHP, Java, Python, Node.js, Ruby, …)
• Eine Datenbank, in der die Daten der Anwendung verwaltet werden

All diese Komponenten müssen miteinander verknüpft werden und i.d.R. in spezifischen Versionen vorliegen. Und diese Komponenten haben ihrerseits Abhängigkeiten, die in der weiteren Softwareumgebung (z.B. im Betriebssystem) vorliegen müssen und die sich schlimmstenfalls sogar teilweise ausschließen können.

Aufgrund dieser Komplexität kommt es immer wieder vor, dass bestimmte für den Betrieb einer Firma essentielle Software nur auf einem ganz bestimmten Computer läuft und sich nicht aktualisieren oder woanders replizieren lässt. Das ist offensichtlich eine riskante Herangehensweise.

Es ist daher meist sinnvoll – auch unabhängig von skalierbaren Clouddeployments, wo dies Gang und Gäbe ist – Software in sogenannte Container zu verpacken. Das sind standardisierte Pakete, die genau definieren, welche Abhängigkeiten die Software genau benötigt. Diese Pakete sind im Betrieb so gekapselt, dass es nicht zu unerwünschten Konflikten zwischen unterschiedlichen Teilen eines Systems kommt. Server, Anwendungsumgebung und Datenbank werden in ihren jeweils eigenen gekapselten Umgebungen betrieben und sind so deutlich einfacher zu verwalten.

Der Aufwand der Containerisierung ist bei entsprechender Kompetenz überschaubar und zahlt sich oft schon in der Entwicklung wieder aus – weil sie auch die Zusammenarbeit unterschiedlicher Teams während der Entwicklung erleichtern kann. Die Containerisierung sollte i.d.R. von der Softwarelieferantin übernommen werden und ist Teil des automatischen Deployments.

On-Premise, Cloud, Serverless

Es gibt mittlerweile zahlreiche Möglichkeiten, wo man Software laufen lassen kann, z.B.:

• On-Premise, also auf Systemen des Auftraggebers,
• auf Servern in der Cloud,
• oder gar “serverless” in der Cloud

“On-Premise” muss dabei nicht heißen, dass der entsprechenden Computer im Firmengebäude der Auftraggeberin steht. Man kann auch komplette Systeme, z.B. bei kleinen Anbietern mieten, wo diese in geeigneten klimatisierten Serverräumen mit unterbrechungsfreier Stromversorgung und redundanter Netzanbindung laufen.

Für kleine und mittlere Unternehmen ist eine solche Miete oft günstiger als solche Infrastruktur selbst zu betreiben. Allerdings sollte stets bedacht werden: Daten die auf fremden Systemen liegen, stehen letztlich unter fremder Kontrolle. Hier müssen Datensensibilität, Vertrauen und Kosten abgewogen werden.

Bei einem Betrieb in großen Clouds sollte darauf geachtet werden, den Betrieb möglichst Anbieterinnen-unabhängig zu gestalten. Das Geschäftsmodell der großen Anbieterinnen besteht allerdings darin, Kundinnen von den eigenen Systemen abhängig zu machen, und dies zu vermeiden erfordert signifikantes Knowhow und verursacht Kosten. So oder so, ist ein Betrieb in der Cloud vorab gut zu planen. Es gibt zahlreiche Optionen für den Betrieb die alle unterschiedliche Kosten-/Nutzen-Konstellationen mitbringen und entsprechend auf das Szenario der Auftraggeberin abgestimmt sein sollten.

Ein modernes Extrem des Cloudbetriebes ist ein “serverless” Deployment. Hier kommen entgegen der Benennung sehr wohl Server zum Einsatz, allerdings werden diese komplett von der Anbieterin betrieben. Dies spart der Auftraggeberin erhebliche Kosten in der Wartung, kann aber auch noch erheblichere Kosten in den Rechnungen der Anbieterin verursachen. Serverless Deployments liegen nahe, wenn mit relativ wenigen Aufrufen der Software gerechnet werden kann.

Mit einem serverless Deployment begibt man sich aber in maximale Abhängigkeit von einer Anbieterin. Es ist auch möglich, Software so zu entwickeln, dass sie sich sowohl serverless als auch mit einem eigenen Server betreiben lässt. Dies kann die Abhängigkeit von einer Anbieterin mindern, verursacht aber wieder eigene Kosten.

Epilog

Dies schließt meine Serie zur Einführung in die Entwicklung und den Betrieb von Software ab, die einen nachhaltigen Wert für Ihr Unternehmen liefert und nebenbei Ressourcen schont und damit auch ökologische Nachhaltigkeit anstrebt. Wie ich hier gezeigt habe, kann man bei jedem Schritt im Lebenszyklus eines Software-Projektes etwas dafür tun, die Nachhaltigkeit und Langlebigkeit des Projektes zu fördern. In vielen Fällen sind das aber Dinge, die Aufmerksamkeit, Problembewusstsein und Initiative/Umlenken von Seiten des auftraggebenden Unternehmens erfordern.

Ich wünsche Ihnen viel Erfolg mit Ihrem Softwareprojekt!