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.
Der Unterschied zwischen Teams und den Ablauf unseres Arbeitstages bestimmen die Grenzen und Auswirkungen dessen, was wir tun, sowie die Werkzeuge, die wir zur Verfügung haben. DevOps-Teams verantworten in der Regel eine Adaptive Anwendung oder eine Gruppe von Diensten. NetOps-Teams sind für ein Unternehmen oder im Fall von Cloud-NetOps-Teams für Hunderte Unternehmen zuständig (ja, die gibt es). Die meisten Netzwerkteams haben mindestens einen Fuß in der physischen Welt, denn letztlich müssen wir Photonen und Elektronen tatsächlich von einem Ort zum anderen bewegen. Die meisten DevOps-Teams arbeiten in der eher virtuellen Welt und profitieren von der Möglichkeit, Ressourcen fast sofort zu erstellen oder zu löschen. Entwicklungs- und DevOps-Teams abstrahieren ihren Quellcode und ihre Geschäftslogik gerne (und zu Recht) von den technischen Details der zugrunde liegenden Architektur – mit dem eingespielten Vertrauen, dass wir sicherstellen, dass ihre API-Aufrufe richtig ankommen und beantwortet werden. Wir alle wollen schnell vorankommen, vermeiden, dass etwas schiefläuft, und Probleme schnell erkennen und beheben, wenn doch einmal etwas passiert. Nur sieht die Welt, in der wir uns bewegen, von innen teils ganz unterschiedlich aus.
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.