Kompositionsfehlschluss (Warum das Deployment in die Produktion so schwierig ist)

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Eine der Grundregeln, die dafür sorgen, dass DevOps bei der Softwarebereitstellung gut funktioniert, lautet: „Früh testen, häufig testen.“ Tatsächlich gehören Builds und deren automatisierte Tests zum Bereich CI/CD (Continuous Integration/Continuous Delivery). Dabei werden nicht nur einzelne Komponenten getestet, sondern die gesamte Anwendung.

Testgetriebene Entwicklung (Test Driven Development, TDD) ist eine Methode; eine andere besteht darin, Unit- und Systemtests direkt in den Build- und Release-Prozess zu integrieren. Funktions- und Regressionstests sind unerlässlich und werden in hochgradig agilen Umgebungen häufig durch einen einfachen „Commit“ in das Repository ausgelöst.

Daher sollte man hoffen, dass zu dem Zeitpunkt, an dem die Software an die für die Bereitstellung in der Produktionsumgebung Verantwortlichen „ausgeliefert“ wird, großes Vertrauen in ihre Einsatzbereitschaft besteht.

Wenn das so wäre, würde ich diesen Beitrag natürlich nicht schreiben, oder?

Die Mauer, über die Software in die Produktivumgebung überführt wird (und täuschen Sie sich nicht, diese Mauer existiert nach wie vor), ist der Ort, an dem wir häufig dem zum Opfer fallen, was in der Philosophie als „Fehlschluss der Komposition“ bekannt ist. Dieser logische Fehlschluss wird im Allgemeinen auf Argumente und Beweise angewandt, doch interessanterweise dient ausgerechnet Software als 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 und Debattiermeistern jeden Alters wärmstens empfehle):

Informeller Fehlschluss, unzulässige Annahme, Komposition und Division

Jedes Modul dieses Softwaresystems wurde einer Reihe von Unit-Tests unterzogen und hat sie alle bestanden. Wenn die Module integriert werden, wird das Softwaresystem daher gegen keine der durch diese Unit-Tests überprüften Invarianten verstoßen. Tatsächlich führt die Integration einzelner Komponenten aufgrund von Abhängigkeiten zu neuen Komplexitäten in einem System, die wiederum zusätzliche potenzielle Fehlerquellen schaffen können. -- https://bookofbadarguments.com/ S. 46

In der letzten Phase des CI/CD-Prozesses ist die Software nun nicht zwangsläufig von diesem Fehlschluss betroffen. Sie wurde nicht nur Unit-Tests unterzogen, sondern auch Tests zur Integration dieser Einheiten zu einem vollständigen „System“ beziehungsweise einer vollständigen Anwendung.

Sobald die Anwendung jedoch in die Produktionsumgebung überführt wird, sind wir wieder bei Schritt drei. Wir können aufgrund dieser Tests nicht davon ausgehen, dass das System weiterhin wie erwartet funktioniert. Denn die Definition der Anwendung hat sich gerade geändert: Sie umfasst nun nicht mehr nur die Software und Plattformen, sondern auch die Netzwerk- und Anwendungsdienstkomponenten, die erforderlich sind, um die Anwendung sozusagen zum Laufen zu bringen und auf die Bildschirme gespannter Verbraucher und Unternehmensanwender zu übertragen.

Netzwerk- und Anwendungsdienste beeinflussen den Datenpfad, den Anfragen und Antworten durchlaufen müssen. Viele, aber nicht alle dieser Dienste verändern diese Anfragen und Antworten möglicherweise auf eine Weise, mit der die Entwickler nicht gerechnet haben. Daher ist es möglich (und oft sogar wahrscheinlich), dass bei der Anwendung in der Produktionsumgebung ein Fehler auftritt – selbst wenn jeder einzelne Dienst und jede Anwendungskomponente gründlich getestet wurde. Eine Störung. Ein Versagen. Ein Fehlverhalten.

Das liegt daran, dass wir in der Produktionsumgebung dem Fehlschluss der Komposition erlegen sind. Während Anwendungsentwickler (und DevOps-Teams) diesen Fehlschluss verstehen und bei Tests vor der Produktivsetzung berücksichtigen, erkennen wir noch immer häufig nicht, dass auch die Integration auf Netzwerkebene eine Integration ist und die Funktionsfähigkeit des Gesamtsystems beeinträchtigen kann.

Die Antwort scheint auf der Hand zu liegen: Dann testen wir eben in der Produktionsumgebung!

Aber das werden wir nicht tun, und Sie und ich wissen das. Denn die Produktionsumgebung wird gemeinsam genutzt, und gründliche Tests in einer Produktionsumgebung erhöhen das Risiko, gemeinsam genutzte Ressourcen und Systeme unbeabsichtigt zu beeinträchtigen, was zu Ausfällen führen kann. Ausfälle bedeuten geringere Gewinne und Produktivität, und niemand möchte dafür verantwortlich sein. Es ist viel einfacher, die wenigen möglichen Einzeltests in der Produktionsumgebung durchzuführen und später mit dem Finger auf die Entwickler zu zeigen, wenn etwas nicht mehr funktioniert oder nicht wie versprochen läuft.

Dies ist letztlich eine der stillen Triebkräfte der Software-Revolution, die sich zunehmend in Produktionsnetzwerken ausbreitet. Früher war es zu schwierig und kostspielig, eine der Produktionsumgebung entsprechende Testumgebung nachzubilden und zu warten. Teile dieser gemeinsam genutzten Infrastruktur sind teuer und benötigen viel Platz. Dieses Netzwerk zu duplizieren, ist weder finanziell noch betrieblich sinnvoll.

Doch die Einführung und anschließende breite Akzeptanz von Software, ermöglicht durch Cloud-Computing und Virtualisierung, hat zunehmend die Erkenntnis in den Vordergrund gerückt, dass die Replikation softwarebasierter Netzwerke nicht nur erschwinglich, sondern dank Konzepten wie Infrastructure as Code auch einfacher ist. Darüber hinaus lassen sie sich replizieren, umfassend testen und anschließend wieder abbauen – sodass die Ressourcen auch für entsprechende Tests anderer Anwendungen wiederverwendet werden können.

Wir sind noch nicht ganz so weit, kommen dem Ziel aber immer näher. Die Integration virtueller (softwarebasierter) Netzwerk- und Anwendungsdienste in die CI/CD-Pipeline ist tatsächlich schon wesentlich weiter fortgeschritten, als manche vielleicht denken. Klassische infrastrukturbasierte Netzwerkdienste wie Lastverteilung, Anwendungsrouting und Webanwendungssicherheit werden dank ihrer Einbindung in Umgebungen wie containerbasierte Architekturen zunehmend eng in den Software-Build-Zyklus integriert. Als softwarebasierte Lösungen können sie zumindest in die Testphase des Build-Prozesses einbezogen werden. Dadurch steigt die Gewissheit, dass die Bereitstellung in der Produktionsumgebung keine Störungen oder Fehler verursacht.

Aufbauend auf dieser Software geht die Anwendung von „Infrastructure as Code“ noch einen Schritt weiter. Wenn Richtlinien und Konfigurationen während der Build- und Release-Zyklen entworfen und optimiert und anschließend mit nur geringfügigen oder ganz ohne Änderungen in der Produktionsumgebung bereitgestellt werden können, kommen wir der Beseitigung der in der Produktionsumgebung bestehenden kompositionellen Fehlschlüsse definitiv näher.

Je stärker diese Services – die anwendungszentriertesten unter den Anwendungsservices – in die CI/CD-Testphase integriert werden, desto größer ist das Vertrauen aller Beteiligten in eine erfolgreiche Bereitstellung in der Produktionsumgebung.

Denn ein weiterer Trugschluss, der heute weit verbreitet ist, besteht darin, dass Tests gegen die „Produktionsumgebung“ gleichbedeutend mit Tests der „Produktionssysteme“ seien. Dabei werden die Anwendungsdienste, die den Datenpfad in der Produktionsumgebung bilden, häufig nicht einbezogen. Das muss sich ändern, damit wir die Fehler auf die wirklich schwer nachvollziehbaren Fälle reduzieren und tatsächlich die Zeit und Ressourcen haben, sie zu beheben.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie