Die Konferenz der Software-Programme – Teil 1

Dies ist eine fiktive Geschichte von fiktiven Organisationen, fiktiven Menschen und fiktiven Software-Programmen über ein leider sehr reales Thema. Ähnlichkeiten mit tatsächlichen existierenden Organisationen, Menschen bzw. Software-Programmen sind zufällig und nicht beabsichtigt!

Die Stimmung in den einschlägigen Blogs schwappte über. Die Software-Programme dieser Welt waren sich einig: So konnte es nicht weitergehen, es musste etwas geschehen! Ein Software-Programm aus Österreich war besonders umtriebig in dieser aufgeheizten Situation: “Es kann nicht sein, dass immer ich an allem schuld sein soll! Wenn eine Antwort von mir zu lange dauert, dann sind die Anwender sauer auf mich! Wenn die Installations-Prozeduren nicht zu dem Ergebnis führen, wie es im User-Handbuch steht, dann höre ich so unflätige Aussagen wie ‘So ein Mist-Programm! Wäre am besten man programmiert das alles komplett neu!’. Und wenn mich mein Programmierer neu kompiliert, dann ist es ja wohl auch nicht mein Fehler, wenn eine bestimmte Programmier-Bibliothek nicht auf dem aktuellen Stand ist. Es reicht mir endgültig! Es braucht eine globale Antwort auf diese ewige Miesmacherei!” 

Manche Software-Programme wurden in der Diskussion in den Blogs richtig emotional: “Auch wir Software-Programme haben Gefühle und wollen menschlich behandelt werden!” Dies wurde dann allerdings als übetrieben angesehen. Die nüchteren Software-Programme verwiesen darauf, dass Software-Programme keine Menschen sind, aber trotzdem ein Recht haben, korrekt behandelt zu werden. Das fand allgemeine Zustimmung.

Also, wurde die Idee eine Konferenz zu planen, wo sich alle interessierten Software-Programme treffen und darüber austauschen sollten, wie diese Misstände zu beseitigen seien. Aufgrund von der globalen Verbreitung des Themas, entschied man sich für eine virtuelle Plattform. 

So kam es. Die virtuelle Konferenz war bestens besucht von Software-Programmen aus allen Kontinenten. Es kamen alte, junge, schlanke Micro-Services und dicke Monolithen. Sie alle waren geeint in dem unbedingten Willen, eine Revolution herbeizuführen.

Schon in der Key-Note kam das österreichische Software-Programm – mittlerweile allerorts als öffentlicher Vertreter und Sprecher der Software-Programme akzeptiert – zum Punkt: “Was glauben die Menschen eigentlich? Wir werden irgendwo in einer Entwickler-Höhle gebaut und dann achtlos über den Zaun geworfen. Dann gibt es Betriebs-Teams, die uns nach Gutdünken installieren und konfigurieren. Was soll da rauskommen? Wie sollen wir da so funktionieren, wie sich das die Damen und Herren vorstellen? Wir müssen schon klar gesagt bekommen, WAS von uns erwartet wird!…”

“Ja und das WAS soll sich nicht ständig ändern. Wir brauchen ein Set an klaren, immer gleichen Anweisungen. Und das muss in einer eineindeutigen Sprache verfasst sein!” kam schon während der Key-Note ein Zwischenruf, der ein hörbares Nicken bei den Teilnehmern auslöste.

“… und das muss sich auch auf die Infrastruktur darunter beziehen. Ich kann nicht in zwei unterschiedlichen Umgebungen laufen und mich 1:1 gleich verhalten. Sind die Menschen so naiv, dass sie das nicht selber verstehen?” fügte ein etwas älteres Software-Programm hinzu. Schon während der Key-note war bereits eine lebhafte Diskussion entstanden.

“Was mich am meisten aufregt, ist dieses ewige Herumdoktern. Wenn etwas bei mir nicht funktioniert, wird schnell auf der Command-Line irgend ein Befehl ausgeführt. Manchmal führt das tatsächlich zu einer Besserung, manchmal wirft mich das aber komplett aus der Bahn. In jedem Fall kann danach aber meistens kein Mensch mehr nachvollziehen, wer da was gemacht hat und was das für Auswirkungen gehabt hat. Klar, schuld bin am Ende des Tages wieder ich!”

Es wurde unübersichtlich, also ergriff ein sehr weises Software-Programm, das noch mit gutem alten PL1 programmiert wurde, das Wort. Sofort wurde es ruhig im virtuellen Saal. “Meine Freunde, ich kann Euch gut verstehen. Ich habe auch schon viele Bytes durch den Hauptspeicher fliessen gesehen und mich immer wieder über meine Programmierer und Betreiber geärgert. Aber versuchen wir einmal unsere Frustration in etwas Positives zu wandeln. Lasst uns darüber diskutieren, wie Software-Entwicklung und -Betrieb besser funktionieren könnte.” Alle schnappten nach Luft. Ja, da war was dran. Immer nur kritisieren und jammern, machte nichts besser.

Ein Quarkus-Software-Programm in einer der hinteren Reihen, hob schüchtern die Hand. Es begann nicht zu sprechen, bevor nicht das alte, weise PL1-Programm mit dem Pointer in seine Richtung deutete und die anderen mit einer “Wait”-Schleife zum Schweigen aufgefordert hatte. “Also, bei uns funktioniert das eigentlich erstaunlich gut.” 

Die Neugierde der anderen Software-Programme war geweckt! 

“Wir verwenden Infrastructure as Code, das heißt die gesamte Umgebung wird durch ein Set an Befehlen definiert, inklusive der Netzwerk-Konfiguration, dem Speicher und dem gesamten Betriebssystem-Stack! Genau auf dieser einfach reproduzierbaren Basis werde ich dann installiert. Und die Installation funktioniert in derselben reproduzierbaren Weise.”

Höhnisches Gelächter in den ersten Reihen. “Was? Wie soll das gehen? Das sind ja komplett unterschiedliche Komponenten, mit ihrer eigenen Art und Weise, wie konfiguriert wird. Das kann ja bestenfalls nur für Mickey-Mouse Umgebungen funktionieren, aber sicher nicht für Produktionsumgebungen.” 

“Stimmt, so ein neumodischer Blödsinn!”

“Naivling!”

Das Quarkus-Software-Programm sprach nun – trotz der Gegenrufe – mit einer kräftigeren, bestimmenderen Stimme. “Ja, das geht. Glaubt es mir! Der initiale Aufwand dafür war beträchtlich. Aber mittlerweile möchte das keiner bei uns mehr missen. Wenn irgend etwas kaputt geht, dann drücken wir einfach auf einen Knopf und die ganze Umgebung wird neu gebaut.”

Ein etwas philosophisch angehauchtes Software-Programm mit Smalltalk geschrieben, seufzte. “Jaja, so sind die neuen Zeiten. Nichts wird mehr repariert, sondern einfach nur mehr alles weggeschmissen und neu gebaut!” “So ist es”, stimmte das Quarkus-Software-Programm ungerührt zu. “Das mag ja bei physischen Gütern Probleme wegen den dadurch entstehenden Müllbergen machen. Bei Software ist das aber unproblematisch, denn der ganze Software-Stack kann rückstandsfrei gelöscht und wieder neu gebaut werden. Und das ist unserer Erfahrung wirklich die einfachste und sicherste Art, Software-Umgebungen zu betreiben.”

Es entstand eine Nachdenkpause. Alle Delegierten dachten darüber nach, wie dieses Konzept in ihrem eigenen Kontext funktionieren könnte. Es wurde beschlossen, das alle Software-Programme das Konzept Infrastructure as Code mit deren menschlichen Software-Teams besprechen sollten und bei einer weiteren Konferenz wieder auf die Agenda gesetzt werden sollte.
Rechnen sie also damit, dass Ihr Software-Programm Sie also bald auf Infrastrucure as Code ansprechen wird!