Schneller zur Wertschöpfung: Prozesse und Parallelisierung

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Zur Weihnachtszeit ist oft ein Klagen zu hören. Es erschallt von den Dächern und unter den stacheligen Zweigen der Tannenbäume hervor.

„Wenn ein Licht ausgeht, gehen sie alle aus!“

Das ist der Aufschrei von jemandem, der mit einer in Reihe geschalteten Lichterkette zu kämpfen hat. Ich will hier nicht ausführlich darauf eingehen, warum das so ist; es genügt zu sagen, dass eine einzige durchgebrannte Glühbirne den gesamten Stromkreis unterbricht.

Das gilt nicht für diejenigen, die das Glück haben, dass ihre Lichter in einer Parallelschaltung angeordnet sind. Eine Glühbirne kann ausfallen, während die anderen weiterhin hell leuchten.

Was hat das mit der Wertschöpfungszeit und Anwendungen zu tun? Alles. Denn wie sich herausstellt, erfolgt der Weg zur Produktion in der traditionellen IT tatsächlich wie in einer Reihenschaltung, während die moderne Anwendungsentwicklung rund um die Uhr wie in einer Parallelschaltung läuft.

Prozess

In einem kürzlich veröffentlichten Blogbeitrag, beschreibt der Global Field CTO von Pivotal, James Urquhart, ein wichtiges Modell für eine kontinuierliche IT, bei dem der Fokus sinnvollerweise auf dem Prozess und nicht auf dem Produkt liegt. Er nennt es den „Path to Production“.

Bei der Idee eines Path to Production geht es im Grunde um Prozesse und – in der traditionellen IT – um Parallelisierung. Dieses Konzept ist für die moderne Anwendungsentwicklung und moderne Architekturen von zentraler Bedeutung. Schon die Aufteilung von Anwendungen in einzelne, klar abgegrenzte Komponenten (manchmal auch als Microservices bezeichnet) führt ganz natürlich zu einer parallelen Entwicklung. Denn kleinere Teams arbeiten gleichzeitig an unterschiedlichen Komponenten. Letztlich ist es genau das, was Agile zu einem wirksamen Ansatz macht, um die Entwicklung zu beschleunigen und die Wertschöpfungszeit von Anwendungen zu verkürzen. Es sind nicht die kleineren Teams. Es sind nicht die kleineren Anwendungen. Es ist die Parallelisierung, die durch die Nutzung dieser Konzepte bei der Entwicklung und Bereitstellung von Anwendungen erreicht wird.

Derselbe Ansatz gilt auch für den Weg in die Produktion. Das heißt, die Produktionskomponenten (Services), die für die Skalierung und die Gewährleistung der Anwendungssicherheit erforderlich sind, sind Teil eines wesentlich umfassenderen Prozesses, wobei einige davon parallel entwickelt und bereitgestellt werden können.

Im Weg steht die traditionelle IT. Serielle IT. Wasserfall-Entwicklungsmethoden, die auf den Produktionsbetrieb übergegriffen haben. Wir bauen Netzwerke als serielle Kanäle auf, weil die Daten das Netzwerk der Reihe nach durchlaufen: vom Router über die Firewall und den Load Balancer bis hin zum Anwendungsserver und zur Datenbank. Die Daten folgen einem vorhersehbaren Pfad von einem Ende des Netzwerks zum anderen. Daher implementieren und stellen wir diese Anwendungsdienste auf dieselbe Weise bereit: in einem vorhersehbaren, sequenziellen Prozess, der dem Datenpfad auf natürliche Weise folgt.

Das wird so nicht mehr funktionieren.

Erstens, weil es jetzt mehrere Datenpfade gibt. Nicht nur die Datenpfade, die von Nord nach Süd und von Ost nach West verlaufen, sondern auch jene, die in andere Himmelsrichtungen abzweigen. Nach Nordosten zu einer Cloud, um ein Skript abzurufen. Nach Südwesten, um Sprites und Webfonts abzurufen. Nach West-Südost, um eine Karte abzurufen und in unsere App einzubetten.

Doch nicht nur die Verteilung der Datenpfade macht es heute erforderlich, den Weg zur Produktion zu parallelisieren. Auch das Streben nach Effizienz und Geschwindigkeit – kurz: Optimierung – spielt dabei eine Rolle.

Parallelisierung

Um die nötige Geschwindigkeit zu erreichen und die heutigen Erwartungen an eine schnelle Wertschöpfung zu erfüllen, ist eine parallele Entwicklung erforderlich. Dies gilt nicht nur für die Anwendungsentwicklung, sondern auch für die zentrale IT. Wenn wir uns die Bandbreite der Anwendungsdienste ansehen, die Unternehmen heute nutzen, erkennen wir mehrere Bereiche, in denen Parallelisierung dazu beitragen kann, die Bereitstellung zu beschleunigen.

Es geht weniger darum, dass die traditionelle IT in Silos organisiert ist. Schließlich führt eine Microservices-Architektur zu Dutzenden oder Hunderten kleiner, isolierter Teams, die sich jeweils auf einen eng umrissenen Bereich von Anwendungsfunktionen konzentrieren. Die traditionelle IT besteht bereits aus Silos innerhalb von Silos. Das Problem ist, dass agile Entwicklungspraktiken die parallele Entwicklung innerhalb dieser Silos fördern, während die traditionelle IT Produktionsprozesse weiterhin methodisch und sequenziell aneinanderreiht.

Problematisch sind die Übergaben zwischen den Teams sowie die Art und Weise, wie wir den Netzwerkverkehr auf dem Weg zur Produktivumgebung spiegeln. Es handelt sich nicht um einen sequenziellen Prozess, und wann immer wir die Entwicklung und Bereitstellung von Services parallelisieren können, sollten wir dies tun.

Das bedeutet funktionsübergreifende Teamstrukturen, die eine frühzeitige Zusammenarbeit fördern.

Durch die Parallelisierung von Prozessen und die Einführung agilerer Praktiken in allen Bereichen können Unternehmen auf ihrem Weg zur Produktion schneller und effizienter werden.

Der Prozess ist das Produkt

Wie James bereits andeutet, ist der Weg zur Produktion im Grunde ein Prozess. Und Prozesse bestehen aus einzelnen Schritten. Wie Ihnen jeder Six-Sigma-Prozess-Ninja mit schwarzem Gürtel bestätigen wird, lässt sich dieser Prozess beschleunigen, indem man Ineffizienzen aufspürt und beseitigt. In der Produktion zeigen sich diese Ineffizienzen als Wartezeiten (Übergaben) zwischen starren, sequenziell ausgeführten Schritten im Bereitstellungsprozess.

Tools können helfen. Doch letztlich erfordert eine Verbesserung eine gründliche, kritische Prüfung der Prozesse und die Suche nach Möglichkeiten, die Bereitstellung von Anwendungsdiensten im Rahmen Ihres „Path to Production“ zu parallelisieren.

Kultur – insbesondere eine Kultur der Zusammenarbeit – ist unverzichtbar. Sie hat ganz konkrete Auswirkungen auf Verhaltensweisen und Arbeitspraktiken. Schon die Teamstruktur verändert die Pipeline-Automatisierung erheblich: Traditionelle Teams mit nur einem Funktionsbereich fallen hinter moderne, DevOps-orientierte Teams zurück. Fördern Sie stärker auf Zusammenarbeit ausgerichtete Teamstrukturen. Ebenso sollte sich ein kollaboratives Team auf zentrale Kennzahlen verständigen. Gemeinsame Kennzahlen ermöglichen es NetOps und Security, ohne Nachteile auf Continuous Deployment hinzuarbeiten. Derzeit wird bei fast drei Vierteln der NetOps-Teams die NETZWERKVERFÜGBARKEIT gemessen. Die Bereitstellungshäufigkeit spielt für sie kaum eine Rolle. Sie konzentrieren sich darauf, das Netzwerk am Laufen zu halten, weil genau das von ihnen verlangt wird. Gemeinsame Kennzahlen geben NetOps die Möglichkeit, sich auf das zu konzentrieren, was das Unternehmen benötigt: schnellere und häufigere Bereitstellungen.

Schließlich ist Empathie gefragt. Sie arbeiten alle im selben Team und legen – auch wenn Sie das vielleicht überrascht – Wert auf dieselben Dinge. Für NetOps ist die Automatisierung von Pipelines mit ebenso hoher Wahrscheinlichkeit von großer Bedeutung wie für DevOps. Bedenken Sie, dass DevOps gegenüber NetOps einen zehnjährigen Vorsprung bei der Bewältigung von Hindernissen in den Bereichen Integration, Tools und Kompetenzen hat. Teams können die Zusammenarbeit fördern, indem sie die Standardisierung von Tools vorantreiben, die den gesamten Prozess von der Bereitstellung bis zum Deployment abdecken (wie Jenkins und GitHub/GitLab).

Der Weg in die Produktion ist kein Produkt, sondern ein Prozess. Und dieser Prozess muss gemeinschaftlich gestaltet und nach Möglichkeit parallel durchgeführt werden, um die Wertschöpfungszeit zu verkürzen und erfolgreiche Anwendungsbereitstellungen zu ermöglichen.

Ü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