Effizienz versus Stabilität beim Software-Entwickeln

Alles begann damit, dass wir uns wieder einmal Monitoring-Software angesehen haben. Zabbix, OpenNMS, natürlich Nagios, aber auch seine vielen Ableger. Gut ein Dutzend Projekte und Produkte haben wir allein in der Sparte Nagios-Nachfahren und Abkömmlinge gezählt. Lösungen, die hauptsächlich das freie Nagios und andere Open-Source-Komponenten integrieren wie Groundworks oder Open IT-Cockpit, solche die mehr eigenen Code einbringen wie Centreon und wieder andere, die nur die Architektur übernehmen, um auf dieser Grundlage völlig neue Software zu entwickeln, wie zum Beispiel Shinken.

Angesichts der Menge drängt sich allerdings eine Frage geradezu auf: Sind das nicht viel zu viele Anläufe auf dasselbe Ziel? Ist das nicht reine Ressourcenvergeudung? Wo könnten die Entwickler stehen, wenn sie an einem Strang zögen, statt jeweils ihr eigenes Süppchen zu kochen? Kurz: Kann das effizient sein? Das Nein muss einem auf der Zunge liegen. Denn das Rad ein Dutzend Mal zu erfinden führt zwangsläufig zu Dubletten und Überschneidungen.

Doch ist Effizienz hier überhaupt der richtige Maßstab? Auf Anhieb übersetzt man effizient mit wirtschaftlich, und dann scheint außer Frage zu stehen, dass damit eine Grundvoraussetzung bezeichnet ist. Doch könnte das nicht vorschnell gefolgert sein? Manchmal erhellt eine Analogie zu scheinbar fernliegenden Bereichen die Zusammenhänge. Hier zum Beispiel ein Blick auf natürliche Ökosysteme.

Analogie Ökosystem

Effizient – zumindest aus der Sicht des menschlichen Nutzers – sind etwa Monokulturen. Alle Pflanzen lassen sich dort über einen Kamm scheren, sei es bei Aussaat oder Ernte, beim Düngen oder bei der Bewässerung: Es reicht jeweils eine Kalkulation, eine Art von Maschine. Der Preis dieser Effizienz ist allerdings Anfälligkeit – denn ohne Schädlingsbekämpfung verwandelte sich leicht die ganze Kultur in das Schlaraffenland eines Ungeziefers oder Pilzes oder in Windbruch oder dürres Ödland. Die Geschichte ist voll von solchen Katastophen von der großen Hungersnot infolge der irischen Kartoffelfäule um die Mitte des 19. Jahrhunderts bis zu 40 Prozent Ertragsverlusten durch Pflanzenkrankheiten in Entwicklungsländern heute.

Ein Gegenspieler der Effizienz ist die Diversität. Die Artenvielfalt markiert zugleich den Gegenpol zur Verletzlichkeit der Monokultur. Ein Biotop aus lauter unterschiedlichen Arten wäre sehr stabil, denn was hier den einen gefährdet, ließe den Nächsten kalt, und viele Mitspieler könnten sich gegenseitig ersetzen. Dafür müsste man es viel differenzierter bewirtschaften. Wollte man der Stabilität wegen die Verschiedenheit aber auf die Spitze treiben, dann verwandelte sich auch dieser Vor- in einen Nachteil: Die Widerstandskraft würde mit Stagnation erkauft, denn wo im Extremfall nur noch wenige Individuen pro Art existierten, da wäre Fortpflanzung wegen der zu geringen Populationsdichte kaum mehr möglich. Aus diesem Grund maximiert die Natur weder die Effizienz noch die Diversität, sondern strebt nach einem Gleichgewicht beider Faktoren. So vielfältig wie möglich, ohne dass es zu einem Stillstand kommt, so effizient wie es geht, ohne zu leicht verwundbar zu sein.

Dieser Gedanke lässt sich übertragen: Eine vielfältige Software-Landschaft bietet Alternativen für mancherlei Ansprüche und wirkt einem Vendor Lock-In entgegen. Gäbe es aber nur noch Programm-Unikate, explodierten die Wartungs- und Schulungskosten, gäbe es keinen Erfahrungsaustausch zwischen den Anwendern mehr, lohnte es für Dritte kaum, Erweiterungen zu programmieren, müssten jedoch andererseits die Software-Preise in extreme Höhen schnellen. Aus dieser Perspektive sollte man also eher fragen: Markieren ein Dutzend Nagios-Ableger eine gesunde Balance?

Für alle ist Platz

Sie scheinen zumindest überwiegend ihre Nischen gefunden zu haben. Alle haben Kunden, die meisten erreichen sie auch über Partner, für die sie extra Programme auflegen. Schon potenzielle Kunden können mit einer Ausnahme überall kostenlose Demoversionen herunterladen, manchmal auch vorinstallierte Demos via Internet ausprobieren. Mehr als die Hälfte der Anbieter von Nagios-Nachfahren offerieren Trainings, alle auf die eine oder andere Weise Support und zusätzliche Informationen (Referenzen, Newsletter, News, Mailinglisten, FAQ, How-tos, Foren, Chats, Blogs, Dependancen in sozialen Netzen und so weiter). Der Umfang ist unterschiedlich – sehr ausgeprägt ist der Service für Kunden etwa bei Centreon oder OP5, etwas zurückhaltender gerieren sich Neteye oder Open IT-Cockpit – aber allen kann man das Bemühen attestieren, eine lebendige Community zu entwickeln.

Nagios und seine Nachfahren scheinen also ein vielfältiges und stabiles Biotop zu bilden, das etlichen Akteuren eine Nische bietet, in der sie ihr Auskommen finden. Darin tummeln sich sowohl Projekte, die in erster Linie von kommerziellen Interessen geleitet werden, als auch solche, die den Open-Source-Gedanken hochhalten und mehr oder weniger vom Idealismus ihrer Entwickler leben. Was funktioniert, hat recht. Es fände sich wohl auch nur schwer eine Rechtfertigung für eine Effizienzpolizei. Zumal das Biotop ja insoweit sogar auch effizient ist, als überall dasselbe Funktionsprinzip und Architekturmodell zum Einsatz kommt und die für die Flexibilität einer Nagios-Lösung so entscheidenden Plugins sehr oft ohne Änderungen nachnutzbar sind.

Das Rad ist übrigens im wirklichen Leben tatsächlich mehrfach erfunden worden. In Mesopotamien und der Induskultur, dem Alpenvorland, im Nordkaukasus, in Südpolen stößt man unabhängig voneinander um die Mitte des 4. Jahrtausends vor Christus auf erste Räder und Karren. Trotzdem handelt es sich dabei um eine der größten technischen Errungenschaften des Menschen überhaupt.