Die Kluft zwischen DevOps und NetOps überbrücken

Falls Sie es noch nicht bemerkt haben, wir schreiben eine Serie mit dem Titel „Die Kluft überbrücken zwischen …“

Hier geht es darum, die Kluft zwischen den Teams zu überbrücken, was mir zunächst wie eine Falle vorkommt.

Ich habe zu viele Artikel gesehen, in denen DevOps-Teams und NetOps-Teams fast schon auf persönlicher Ebene gegeneinander ausgespielt werden. Das ist nicht hilfreich, denn es geht nicht um die Menschen oder die Teams, sondern um die Zwänge und Erwartungen, die sie geprägt haben. Die einzelnen Mitglieder dieser Teams haben bei der Arbeit meist alle Spaß an der gleichen Sache – coole Sachen. Wir alle möchten etwas schaffen, auf das wir stolz sind, das einen nützlichen Zweck hat und das, nun ja, cool ist.

Was Teams unterscheidet und unseren Arbeitstag prägt, sind die Grenzen und Auswirkungen unserer Arbeit sowie die Werkzeuge, die wir nutzen. DevOps-Teams konzentrieren sich meist auf eine Anwendung oder eine Sammlung von Diensten. NetOps-Teams betreuen Unternehmen – oder im Fall von Cloud-NetOps sogar Hunderte von Unternehmen (ja, die gibt es). Die meisten Netzwerkteams agieren zumindest teilweise in der physischen Welt, denn irgendwer muss die Photonen und Elektronen von einem Ort zum anderen bringen. Die meisten DevOps-Teams arbeiten in der virtuellen Welt und profitieren von der Möglichkeit, Ressourcen nahezu sofort zu erstellen und zu entfernen. Entwicklungs- und DevOps-Teams abstrahieren ihren Quellcode und die Geschäftslogik gern vom Detail der zugrunde liegenden Architektur – natürlich im Vertrauen darauf, dass jemand sicherstellt, dass ihre API-Aufrufe den richtigen Weg nehmen. Jeder will schnell handeln und dafür sorgen, dass nichts ausfällt – oder zumindest Probleme einfach zu diagnostizieren und zu beheben sind, wenn sie auftreten. Die Welten, in denen sie agieren, können allerdings von innen ganz unterschiedlich wirken.

An der Grenze dieser beiden Realitäten können die Probleme beginnen. Es ist klar, dass in vielen Organisationen eine Kluft zwischen den Arbeitspraktiken und SLA-Anforderungen verschiedener Teams besteht . Obwohl diese Reibung als etwas Neues angesehen werden könnte, ist es ein Zustand, den wir schon seit mehr als einem Jahrzehnt beobachten – einfach, weil die F5-Technologie schon immer die Verbindung zwischen application und infrastrukturorientierten Teams darstellte. Unabhängig davon, ob es sich nur um eine Änderung der Anzahl der Backend-Server oder des Application handelt, müssen sich Änderungen an der Application schon immer in der Application widerspiegeln, wo Sicherheitsüberprüfungen, Inhaltsrouting oder Lastenausgleich stattfinden. Da Entwickler ihre Arbeitsabläufe mittlerweile iterativer gestalten, erfolgen diese Änderungen immer schneller, und die Symptome werden deutlicher.

Deshalb ist es so eine aufregende Zeit. Denn noch nie hat es eine vergleichbare Gelegenheit gegeben, diese Kluft zu überbrücken. Bei F5 haben wir immer mehr Tools entwickelt, um unsere extrem robuste Technologie der Enterprise-Klasse in agilere, automatisierte Arbeitsabläufe zu integrieren. Wir bieten Schulungen zu diesen neuen Arbeitsweisen für alle an, die dies wünschen. Und wir haben unsere interne Arbeitsweise verändert.

Doch die beste Brücke zwischen Gräben baut man aus Verständnis und gemeinsamen Erfahrungen. Die Werkzeuge und Prozesse zur Unterstützung der Brücke werden ohne den Mörtel der Zusammenarbeit nicht halten. Darauf freue ich mich bei der weiteren Zusammenarbeit mit NGINX am meisten – auf die Möglichkeit, die Kluft zu überbrücken und zu sehen, wie die Dinge aus ihrer Sicht und – noch wichtiger – aus der Sicht ihrer Kunden in Bezug auf die Prozesskluft aussehen. Durch unsere Zusammenarbeit können wir gemeinsamen Kunden dabei helfen, ein immer besseres Verständnis zwischen allen Teams zu erreichen, die an der Bereitstellung sicherer, schneller und innovativer Applications beteiligt sind. Natürlich wird Technologie darin stecken, denn das ist es, was wir herstellen. Es wird jedoch ein breiteres Spektrum an Anwendungsfällen abdecken und von einer umfassenderen Vision rund um DevOps und NetOps getragen, um den Anforderungen der Gruppe gerecht zu werden, auf die wir uns am meisten konzentrieren – unseren Kunden und Benutzern.