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 sich zwischen den Teams unterscheidet und was unseren Arbeitstag bestimmt, sind die Grenzen und Auswirkungen dessen, was wir tun, sowie die Werkzeuge, die uns zur Verfügung stehen. DevOps-Teams lösen im Allgemeinen eine Application oder eine Sammlung von Diensten. NetOps-Teams lösen Probleme für ein ganzes Unternehmen, oder im Fall von Cloud-NetOps-Teams (ja, die gibt es) für Hunderte von Unternehmen. Die meisten Netzwerkteams stehen mit mindestens einem Fuß in der physischen Welt, da die Photonen und Elektronen ja schließlich von einem Ort zum anderen transportiert werden müssen. Die meisten DevOps-Teams arbeiten in der ätherischen Welt des Virtuellen und profitieren von der Möglichkeit, Ressourcen nahezu augenblicklich zu erstellen und zu vernichten. Während Entwicklungs- und DevOps-Teams gerne (und zu Recht) ihren Code und ihre Geschäftslogik von den Einzelheiten der zugrunde liegenden Architektur abstrahieren, tun sie dies im blinden Vertrauen darauf, dass jemand dafür sorgt, dass ihre API-Aufrufe zum richtigen Ort und vom richtigen Ort gelangen. Jeder möchte schnell vorankommen, jeder möchte, dass nichts kaputtgeht oder dass es einfach zu diagnostizieren und zu reparieren ist, wenn etwas kaputtgeht. Es ist nur so, dass die Universen, in denen sie leben, von innen etwas anders aussehen können.

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.