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 das ganz genau. Da Produktion eine gemeinsame Umgebung ist, birgt gründliches Testen dort das Risiko, dass gemeinsame Ressourcen und Systeme Schaden nehmen und Ausfälle verursachen. Ausfälle führen zu geringeren Gewinnen und Produktivität, und dafür will niemand die Verantwortung tragen. Es ist viel einfacher, die in Produktion möglichen Einzeltests durchzuführen und später den Anwendungsentwicklern die Schuld zu geben, wenn etwas ausfällt oder nicht wie vorgesehen 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.
Die Einführung und anschließende Nutzung von Software durch Cloud-Computing und Virtualisierung hat klar gemacht, dass die Replikation softwarebasierter Netzwerke nicht nur bezahlbar, sondern dank Konzepten wie Infrastruktur als Code auch einfacher geworden ist. Sie können sie jederzeit replizieren, testen und wieder abbauen – so lassen sich Ressourcen auch für andere Anwendungen wiederverwenden.
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.
Ein weiterer Fehler, der heute oft gemacht wird, ist zu glauben, dass das Testen gegen „Produktion“ auch die „Produktionssysteme“ umfasst. Dabei sind oft nicht die App-Dienste im Datenpfad der Produktion eingeschlossen. Das muss sich ändern, damit Sie Fehler auf die wirklich außergewöhnlichen reduzieren und tatsächlich Zeit und Ressourcen haben, diese zu beheben.