Liefer- und Bereitstellungs-Toolchains: Immer noch dem Axiom des schwächsten Glieds unterworfen
Heutzutage kann man sich kaum noch umdrehen, ohne dass jemand seine DevOps-unterstützende Toolchain erwähnt. Jeder hat eins (ja, sogar wir) und alle werden durch die (andere) API-Wirtschaft ermöglicht. Laut Wikipedia ist eine DevOps-Toolchain: „ein Satz oder eine Kombination von Tools, die bei der Bereitstellung, Entwicklung und Verwaltung von Applications während des gesamten Softwareentwicklungszyklus helfen, koordiniert von einer Organisation, die DevOps- Praktiken verwendet.“
Dabei geht es hauptsächlich um die App, aber es gibt auch die Produktionsseite des Hauses, wo Software im Allgemeinen einen Großteil ihres Lebens verbringt (hofft man zumindest). Dieselbe Definition gilt auch hier, mit dem Vorbehalt, dass ihr Schwerpunkt (aus meiner Sicht) auf der „Bereitstellung, Konfiguration und Verwaltung von Netzwerk- und App-Diensten während des gesamten App-Lebenszyklus liegt, koordiniert von einer Organisation, die DevOps-Praktiken verwendet.“ Im Kontext traditioneller DevOps erweitert dieser Schwerpunkt die „Release“-Phase im Zyklus und umfasst „Release-bezogene Aktivitäten“, die die Bereitstellung und Implementierung von Software in die Produktion umfassen. Dazu gehören (oder sollten) zwangsläufig die Netzwerk- und App-Dienste gehören, die für eine sichere Bereitstellung der Application für die Zielbenutzer erforderlich sind.
Das Problem ist, dass kein einzelner Anbieter oder Open-Source-Projekt über alle notwendigen Tools verfügt, um den utopischen Traum der kontinuierlichen Bereitstellung zu verwirklichen (das ist übrigens die Produktionsseite des Hauses). Tatsächlich werden einige der gleichen Tools, die auf der App-Entwicklungsseite verwendet werden, auch auf der Produktionsseite eingesetzt. Wir sehen zunehmend Überschneidungen zwischen den beiden Welten, was ein gutes Zeichen für „DevOps“ im Allgemeinen ist, da es eine gewisse Normalisierung zwischen zwei traditionell sehr verwurzelten Organisationen anzeigt, die außer der App wenig gemeinsam haben.
Sie können also Puppet oder Chef in Kombination mit VMware und Cisco verwenden, um einen vollständigen Stapel von Netzwerk- und App-Diensten zu automatisieren und so die Anforderungen einer App an Sicherheit, Identität und Skalierung zu erfüllen. Sie haben die hierfür erforderlichen Vorlagen und Skripte erstellt und deren Richtigkeit überprüft. Möglicherweise haben Sie dazu Postman und seine Skriptfunktionen verwendet, um Tests mit der virtuellen Infrastruktur im Labor durchzuführen. Sie haben entschieden, dass Git eine gute Wahl als Repository für Konfigurationsartefakte ist, da die App-Entwicklung es bereits verwendet und Anleitungen bereitstellen und vielleicht sogar die eine oder andere Schulung abhalten kann. Und Sie können sogar noch einen Schritt weitergehen und mit der Entwicklung einer App beginnen (oder eine OpenStack -Implementierung auf die Beine stellen), um den Prozess zu orchestrieren und die Selbstbedienung einzelner Dienste zu ermöglichen. Sie definieren im Wesentlichen die Bereitstellungs-Toolchain.
Und hier beginnt das Axiom des schwächsten Glieds sein hässliches Gesicht zu zeigen. Sie kennen das Prinzip: Eine Kette ist nur so stark wie ihr schwächstes Glied. „Stark“ wird hier betont, weil wir es durch andere Eigenschaften wie „zuverlässig“ oder „sicher“ oder „skalierbar“ ersetzen können und das Axiom weiterhin wahr bleibt. Dies ist wichtig, denn wenn Sie mit der Definition der Toolchain beginnen, die die kontinuierliche Bereitstellung unterstützt, kann jedes „Glied“ in dieser Kette zu einem Fehlerpunkt werden, an dem die Sicherheit, Skalierbarkeit oder Verfügbarkeit beeinträchtigt wird.
Planung, Überprüfung und Überwachung sind ebenso wichtige Glieder in der DevOps-Toolchain wie auch in der NetOps-Toolchain. Dies ist insbesondere für die Überwachung wichtig, da sich Apps und Infrastruktur (Netzwerk- und App-Dienste) in Produktionsumgebungen am häufigsten kreuzen. Durch die Überwachung (Sichtbarkeit) kann im Falle eines Fehlers ein umfassender Überblick über alle Vorgänge, von Geschäftstransaktionen bis hin zu einzelnen Anfragen und Antworten, erlangt werden.
Durch die Konfiguration werden auch die Toolchains zwangsläufig miteinander verbunden, da die Konfiguration von Netzwerk- und App-Diensten für eine bestimmte Application spezifisch sein kann (und oft auch ist).
Auch wenn die Verpackungs- und Freigabemechanismen möglicherweise ähnliche Tools nutzen, handelt es sich dennoch um separate Belange, bei denen die Anforderungen häufig sehr unterschiedlich sind. Da Netzwerk- und App-Dienste möglicherweise auf einer gemeinsam genutzten Infrastruktur bereitgestellt werden, sind Tools, die einen Einzelsystemansatz voraussetzen, für NetOps möglicherweise nicht geeignet. Umgekehrt wird die Verwendung von Vorlagen immer üblicher, um standardisierte Dienste schnell in der Produktion bereitzustellen. In DevOps, wo die Applications einen hohen Grad an Einzigartigkeit aufweisen, sind sie jedoch selten anwendbar.
Ungeachtet dessen haben beide Toolchains einen gemeinsamen Nenner: Die Schwäche eines einzigen Glieds infiziert die gesamte Kette. Auch wenn Sie sich überwiegend auf manuelle Bereitstellungen verlassen, die Skripte nutzen, gibt es dennoch eine Toolchain, die den gesamten Liefer- und Bereitstellungsprozess darstellt. Menschen können und sind Glieder in den Toolchains, die heutzutage Software liefern und einsetzen. Und wenn ein entscheidendes Bindeglied fehlt – weil Bob gerade an der Grippe leidet –, bricht der Prozess zusammen. Die Toolchain kann nicht übermittelt (oder bereitgestellt) werden.
Während Sie mit Ihrer internen digitale Transformation fortfahren, ist es wichtig, dass Sie die Bedeutung der DevOps- und NetOps-Toolchains erkennen und keine der Verbindungen übersehen, aus denen sie bestehen. Wenn wir auf dem Weg zum Ziel der kontinuierlichen Bereitstellung auch nur einem einzigen Glied keine Aufmerksamkeit schenken, schwächt dies die gesamte Kette. Da sich Unternehmen immer stärker auf diese miteinander verbundenen Ketten verlassen, führt ein schwaches Glied nicht nur zum Scheitern eines Prozesses, sondern auch zum Scheitern des gesamten Unternehmens.