Trugschluss der Komposition (Warum die Bereitstellung in der Produktion so schwierig ist)
Eine der Grundregeln für eine erfolgreiche Softwarebereitstellung mit DevOps lautet: „Früh testen, oft testen.“ Tatsächlich besteht ein Teil des CI/CD-Bereichs (Continuous Integration/Continuous Delivery) aus Builds und automatisierten Tests dieser Builds. Nicht nur einzelner Komponenten, sondern der gesamten Anwendung.
Test Driven Development (TDD) ist eine Methode, eine andere ist einfach die Integration von Unit- und Systemtests als Teil des Build- und Release-Prozesses selbst. Funktions- und Regressionstests sind zwingend erforderlich und werden in hochagile Umgebungen häufig durch ein einfaches „Commit“ in das Repository ausgelöst.
Man kann daher hoffen, dass zu dem Zeitpunkt, an dem die Software in die Hände derjenigen „geliefert“ wird, die für den Einsatz in der Produktion verantwortlich sind, großes Vertrauen in ihre Einsatzbereitschaft besteht.
Wenn das der Fall wäre, würde ich diesen Beitrag natürlich nicht schreiben, oder?
Die Mauer, über die Software in die Produktion gelangt (und seien Sie unbesorgt, diese Mauer existiert noch immer), ist der Punkt, an dem wir häufig mit dem in der Philosophie als „Kompositionsirrtum“ bekannten Phänomen in Konflikt geraten. Dieser logische Fehlschluss wird im Allgemeinen auf Argumente und Beweise angewandt, interessanterweise bildet jedoch eine Software die Grundlage für eine einfache Erklärung dieses „schlechten Arguments“ durch den Autor Ali Almossawi in The Book of Bad Arguments (das ich angehenden Philosophen/Debattiermeistern aller Altersgruppen wärmstens empfehle):
Informeller Irrtum, ungerechtfertigte Annahme, Zusammensetzung und Teilung
Jedes Modul dieses Softwaresystems wurde einer Reihe von Komponententests unterzogen und hat sie alle bestanden. Daher wird das Softwaresystem bei der Integration der Module keine der durch diese Komponententests überprüften Invarianten verletzen . Die Realität ist, dass die Integration einzelner Teile aufgrund von Abhängigkeiten neue Komplexitäten in ein System einführt, die wiederum zusätzliche potenzielle Fehlerquellen schaffen können. – https://bookofbadarguments.com/ S. 46
Jetzt, in der letzten Phase des CI/CD-Prozesses, ist die Software nicht mehr unbedingt anfällig für diesen Fehler. Es wurde nicht nur Komponententests unterzogen, sondern auch Tests zur Integration dieser Einheiten zur Bildung eines vollständigen „Systems“ oder einer vollständigen Anwendung.
Sobald die Produktion jedoch anläuft, sind wir wieder am Anfang. Wir können nicht davon ausgehen, dass das System auf Grundlage dieser Tests weiterhin wie erwartet funktioniert. Das liegt daran, dass sich die Definition der Anwendung geändert hat und nun nicht mehr nur deren Software und Plattformen umfasst, sondern auch die Netzwerk- und App-Dienstkomponenten, die erforderlich sind, um die App zum Laufen zu bringen und sie auf die Bildschirme eifriger Verbraucher und Unternehmensbenutzer zu bringen.
Netzwerk- und App-Dienste wirken sich auf den Datenpfad aus, den Anfragen und Antworten durchlaufen müssen . Viele, aber nicht alle dieser Dienste können die Anfragen und Antworten tatsächlich auf eine Art und Weise ändern, die die Entwickler nicht vorhergesehen haben. Daher ist es möglich (und oft wahrscheinlich), dass in der Anwendung in der Produktionsumgebung ein Fehler auftritt, selbst wenn alle einzelnen Dienste und App-Komponenten gründlich getestet wurden. Ein Fehlschlag. Einen Fehler machen.
Dies liegt daran, dass wir in der Produktionsumgebung dem Trugschluss der Komposition zum Opfer gefallen sind. Obwohl App-Entwickler (und DevOps) diesen Irrtum verstehen und ihn in Tests vor der Produktion berücksichtigen, erkennen wir häufig nicht, dass die Integration auf Netzwerkebene immer noch eine Integration ist und sich tatsächlich auf die Betriebsintegrität des Ganzen auswirken kann.
Die Antwort scheint offensichtlich: Na gut, dann testen wir es eben in der Produktion!
Aber wir werden es nicht tun, und Sie und ich wissen, dass wir es nicht tun werden. Denn die Produktion erfolgt in einer gemeinsam genutzten Umgebung und rigorose Tests in einer Produktionsumgebung erhöhen das Risiko von Kollateralschäden an gemeinsam genutzten Ressourcen und Systemen, die zu Ausfällen führen können. Ausfälle bedeuten geringere Gewinne und Produktivität und niemand möchte dafür verantwortlich sein. Es ist viel einfacher, die in der Produktion möglichen Einzeltests durchzuführen und dann später mit dem Finger auf die Entwickler zu zeigen, wenn etwas nicht funktioniert oder nicht wie angekündigt funktioniert.
Dies ist letztlich einer der stillen Treiber der Softwarerevolution, die die Produktionsnetzwerke auffrisst. Früher war es zu schwierig und zu kostspielig, eine Testumgebung zu replizieren und zu pflegen, die der Produktionsumgebung entsprach. Ein Teil dieser gemeinsam genutzten Infrastruktur ist teuer und nimmt viel Platz in Anspruch. Die Duplizierung dieses Netzwerks ist weder finanziell noch betrieblich sinnvoll.
Doch mit der Einführung und der darauffolgenden Verbreitung von Software im Zuge von Cloud Computing und Virtualisierung rückte die Vorstellung in den Vordergrund, dass die Replikation softwarebasierter Netzwerke nicht nur kostengünstig, sondern dank Konzepten wie „Infrastruktur als Code“ auch einfacher ist. Darüber hinaus können Sie es replizieren, damit Tests durchführen und es wieder abbauen. Das heißt, Ressourcen können wiederverwendet werden, um dasselbe auch für andere Anwendungen zu tun.
Wir sind noch nicht am Ziel, aber wir kommen näher. Die Integration virtueller (software-)basierter Netzwerk- und Anwendungsdienste in die CI/CD-Pipeline ist tatsächlich viel realistischer, als manche vielleicht denken. Traditionell werden infrastrukturbasierte (netzwerkbasierte) Dienste – Lastausgleich, App-Routing, Web-App-Sicherheit – dank ihrer Einbindung in Umgebungen wie containerbasierten Architekturen stark in den Software-Erstellungszyklus integriert. Als softwarebasierte Lösungen können sie zumindest in die Testphase des Build-Prozesses einbezogen werden und erhöhen so die Sicherheit, dass bei der Bereitstellung in der Produktion keine Störungen oder Fehler auftreten.
Aufbauend auf dieser Software geht die Anwendung von „ Infrastruktur als Code “ noch einen Schritt weiter. Wenn Richtlinien und Konfigurationen während der Build- und Release-Zyklen entworfen und optimiert und dann mit wenigen oder keinen Änderungen in die Produktion überführt werden können, sind wir der Beseitigung der in der Produktion vorhandenen Kompositionsfehler definitiv einen Schritt näher gekommen.
Je mehr diese Dienste – die app-zentriertesten aller App-Dienste – in die CI/CD-Testphase integriert werden, desto mehr Vertrauen kann jeder in eine erfolgreiche Produktionsbereitstellung haben.
Denn der andere heute gängige Irrtum besteht darin, dass mit dem Testen in der „Produktion“ auch „Produktionssysteme“ gemeint sind. Es umfasst häufig nicht die App-Dienste, die den Datenpfad in der Produktion bilden. Das ist auch notwendig, damit wir die Fehler auf die wirklich esoterischen reduzieren und tatsächlich Zeit und Ressourcen haben, sie zu beheben.