Auch Master (DevOps) Builder brauchen Zusammenarbeit

Wenn Sie Eltern sind (und selbst wenn nicht, hier wird nicht geurteilt), haben Sie sich wahrscheinlich schon den Lego-Film angesehen. Mehr als einmal.

Ich bin der Meinung, dass dies für jedes Unternehmen, das die Einführung von DevOps in Erwägung zieht, Pflicht sein sollte.

Ernsthaft.

Denn eine der (vielen) Erkenntnisse besteht darin, dass selbst Master Builder, Experten auf ihrem jeweiligen Gebiet, mit anderen zusammenarbeiten müssen, um die Welt zu retten und eine Anwendung in den gewünschten, bereitgestellten Zustand zu versetzen. Das heißt, eines, das nicht in der Produktion mit dem beängstigenden technologischen Kragle manueller Prozesse festhängt.

Jeder Baumeister kann sich individuell nicht nur vorstellen, was er bauen möchte, sondern auch alle Einzelteile, die er dafür benötigt. Und das tun sie im Film oft und bewundernswert, indem sie blitzschnell fertige Kreationen erschaffen, die zerschmettern, fliegen, rennen und um sich schießen können, um die Situation zu retten. Aber als es darum ging, das „größere“ Bild zu betrachten, also nicht nur einzelne Kreationen zu erschaffen, sondern dann (verstehen Sie, was ich damit meinte?) eine Reihe von Ereignissen zu orchestrieren, um den Plan des bösen Schurken zu vereiteln, gelang es ihnen nicht. Sie brauchten einen Mann, der gerne Anweisungen zu Rate zog und eine Checkliste mit den erforderlichen Verfahren bei sich trug, damit alle in die gleiche Richtung gingen.

In unserem Fall ist diese Richtung die Produktion.

Da die kontinuierliche Bereitstellung zu einer echten Möglichkeit und zum ultimativen Ziel von DevOps wird, da es die Mauer zwischen Entwicklung und dem „Rest der IT“ überwindet, besteht ein sehr realer Bedarf an Koordination über alle vier Betriebsdomänen hinweg (das sind Sicherheit, Speicherung, Berechnung und Netzwerk), um sicherzustellen, dass die Baumeister der einzelnen Dienst- und Systemsätze nicht im luftleeren Raum arbeiten.

Selbst Entwickler, die Microservices mit ihrem „lokalen und von anderen Diensten unabhängigen Code“ begrüßen, wissen, dass eine solche Denkweise und Herangehensweise nur funktioniert, wenn klar definierte und dokumentierte Schnittstellen (APIs) vorhanden sind, mit denen andere Dienste kommunizieren können. Diese Schnittstellen werden (oder sollten) nicht im luftleeren Raum entwickelt werden, ohne zu verstehen, wie andere Dienste sie aufrufen.

Dasselbe gilt für die Produktionsseite der Mauer, wo alle vier Betriebsdomänen irgendwann miteinander kommunizieren müssen, um die kontinuierliche Bereitstellung tatsächlich zu ermöglichen. Es gibt einen Masterplan, also eine Reihe von Anweisungen, die befolgt werden müssen, auch wenn die Details zum Aufbau der einzelnen Dienste oder Dienstgruppen noch unklar sind. Sie müssen irgendwann in einen übergreifenden Prozess integriert werden, der die Bereitstellung von einem Ende der Produktionspipeline zum anderen steuert.

Die Baumeister der einzelnen Bereiche können nicht völlig unabhängig voneinander arbeiten. Sie müssen sich abstimmen, zusammenarbeiten und überlegen, wie ihr Puzzleteil in den großen Plan zur Rettung der (App-)Welt passt, auf der das Geschäft heute aufbaut.

Eine Möglichkeit, damit zu beginnen, besteht darin, Auswirkungssätze grafisch darzustellen. Daran wurde ich erinnert, als ich kürzlich einen Artikel zur Code-Kopplung mit dem Titel „Die 80%-Regel der Programmkopplung“ im Hinblick auf die Sicherheit las. Der Artikel konzentriert sich sehr auf Code und den Aufbau von Abhängigkeitsdiagrammen, die speziell für entwicklungsorientierte Leute gedacht sind. Wenn Sie es jedoch auf eine höhere Ebene bringen (abstrahieren) und Funktionen/Prozeduren/Methoden als Systeme in der Produktion betrachten, können Sie erkennen, wie nützlich dies sein könnte. Wenn man versteht, in welchem Ausmaß die Anwendungsbereitstellung von bestimmten Diensten (oder sogar von der Domänenebene) abhängig ist, kann man wertvolle Erkenntnisse darüber gewinnen, wie viel Koordination zwischen den Gruppen erforderlich ist, um die Aufgabe zu erledigen, und einen Plan zur Erreichung dieses Ziels ausarbeiten können.

Eines der besten Beispiele ist, dass praktisch alles davon abhängt, dass zuerst zentrale Netzwerkdienste bereitgestellt werden. Das gilt nicht nur für die Anwendung und ihre abhängigen Komponenten, sondern auch für die Sicherheit und die höherwertigen (App-)Dienste, die die App bereitstellen. Lastausgleich, Web-Anwendungssicherheit und sogar die Firewall sind für ihre Funktion auf Netzwerkattribute angewiesen. Das Verständnis dieser Abhängigkeiten (der Kopplungsfaktor) zwischen Systemen und Diensten, die von unterschiedlichen Gruppen (Silos) innerhalb der IT verwaltet werden, kann einen großen Beitrag dazu leisten, den Bedarf an Kommunikation und Zusammenarbeit zu steigern, um zumindest so etwas wie eine kontinuierliche Bereitstellung zu erreichen.

Auch Baumeister müssen verstehen, wie ihre Schöpfung ins Gesamtbild passt. Durch die Anwendung von Entwicklungstechniken und -tools auf die zunehmend automatisierte und codebasierte Betriebswelt der IT können sie die erforderlichen Schnittstellen besser erstellen, um ihr Puzzleteil in das große Konstruktionsprojekt „Continuous Deployment“ zu integrieren.