Die Kluft zwischen DevOps und NetOps überbrücken

Robert HaynesManager für technisches Marketing

Falls Sie es noch nicht bemerkt haben: Wir schreiben eine Artikelreihe nach dem Muster „Die Kluft zwischen … überbrücken“

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

Ich habe zu viele Artikel gelesen, in denen DevOps- und NetOps-Teams gegeneinander ausgespielt werden – fast schon auf persönlicher Ebene. Das ist nicht hilfreich, denn es geht weder um die Menschen noch um die Teams, sondern um die Rahmenbedingungen und Erwartungen, die sie geprägt haben. Die Mitglieder dieser Teams haben bei der Arbeit größtenteils an denselben Dingen Freude: an richtig coolen Sachen. Wir alle wollen etwas schaffen, auf das wir stolz sein können, das einen echten Nutzen hat und das einfach cool ist.

Was die Teams voneinander unterscheidet und unseren Arbeitsalltag prägt, sind die Grenzen und Auswirkungen unserer Tätigkeit sowie die Werkzeuge, die uns zur Verfügung stehen. DevOps-Teams kümmern sich in der Regel um eine Anwendung oder eine Gruppe von Diensten. NetOps-Teams sind für ein Unternehmen zuständig – oder, im Fall von Cloud-NetOps-Teams, für Hunderte von Unternehmen (ja, die gibt es tatsächlich). Die meisten Netzwerkteams stehen mit mindestens einem Bein in der physischen Welt, denn irgendetwas muss diese Photonen und Elektronen tatsächlich von einem Ort zum anderen befördern. Die meisten DevOps-Teams arbeiten dagegen in der schwer greifbaren virtuellen Welt und genießen die Möglichkeit, Ressourcen nahezu augenblicklich zu erstellen und wieder zu vernichten. Während Entwicklungs- und DevOps-Teams ihren Code und ihre Geschäftslogik bereitwillig (und völlig zu Recht) von den technischen Details der zugrunde liegenden Architektur abstrahieren, vertrauen sie stillschweigend darauf, dass jemand dafür sorgt, dass ihre API-Aufrufe am richtigen Ort ankommen und die Antworten den Weg zurückfinden. Alle wollen schnell vorankommen, und alle wollen, dass nichts ausfällt – oder dass sich Probleme zumindest leicht diagnostizieren und beheben lassen. Nur können die Welten, in denen sie sich bewegen, von innen betrachtet etwas unterschiedlich aussehen.

An den Grenzen zwischen diesen beiden Realitäten können die Probleme beginnen. Es ist offensichtlich, dass in vielen Unternehmen tatsächlich eine Kluft zwischen den Arbeitsweisen und SLA-Anforderungen verschiedener Teams besteht. Auch wenn diese Reibung als neues Phänomen erscheinen mag, beobachten wir sie bereits seit weit über einem Jahrzehnt – ganz einfach deshalb, weil die Technologie von F5 schon immer das Bindeglied zwischen anwendungsorientierten und infrastrukturorientierten Teams war. Ob sich lediglich die Anzahl der Backend-Server oder das Verhalten der Anwendung ändert: Änderungen an der Anwendungsarchitektur mussten sich schon immer in der Anwendungsbereitstellungsschicht widerspiegeln, in der Sicherheitsprüfungen, Content-Routing oder Lastverteilung stattfinden. Da Entwickler ihre Arbeitsabläufe nun zunehmend iterativ gestalten, erfolgen diese Änderungen immer schneller, wodurch die Auswirkungen deutlicher zutage treten.

Genau deshalb ist dies eine so spannende Zeit. Denn noch nie gab es eine vergleichbare Gelegenheit, diese Kluft zu überbrücken. Bei F5 entwickeln wir immer mehr Tools, um unsere äußerst robuste Technologie auf Enterprise-Niveau in agilere, automatisierte Workflows zu integrieren. Wir bieten allen Interessierten Schulungen zu diesen neuen Arbeitsweisen an. Und wir haben auch unsere interne Arbeitsweise grundlegend verändert.

Doch die beste Brücke über Gräben hinweg entsteht durch Verständnis und gemeinsame Erfahrungen. Die Werkzeuge und Prozesse, die diese Brücke stützen, können ohne den Mörtel der Zusammenarbeit nicht bestehen. Genau darauf freue ich mich bei der engeren Zusammenarbeit mit NGINX am meisten: die Chance, den Graben zu überwinden und die Dinge aus ihrer Perspektive zu betrachten – und, noch wichtiger, aus der Perspektive ihrer Kunden auf die Kluft zwischen den Prozessen. Gemeinsam können wir unseren gemeinsamen Kunden helfen, das Verständnis zwischen allen Teams, die an der Bereitstellung sicherer, schneller und innovativer Anwendungen beteiligt sind, kontinuierlich zu verbessern. Natürlich wird dabei auch Technologie eine Rolle spielen – schließlich ist es das, was wir entwickeln. Doch sie wird ein breiteres Spektrum an Anwendungsfällen abdecken und von einer umfassenderen Vision für DevOps und NetOps getragen sein, um den Anforderungen der Gruppe gerecht zu werden, die für uns im Mittelpunkt steht: unsere Kunden und Benutzer.

Über den Autor

Robert HaynesManager für technisches Marketing

Weitere Blogbeiträge von Robert Haynes