BLOG

IT-Leiter müssen sich mit DevOps auseinandersetzen und es annehmen

Lori MacVittie Miniaturbild
Lori MacVittie
Veröffentlicht am 22. Juni 2015

IT-Fachleute sind ein Haufen praktisch veranlagter Menschen. DevOps als kultureller Wandel ist für diejenigen, die mit der Bereitstellung von Apps in der Produktion und der Aufrechterhaltung ihrer Verfügbarkeit, Sicherheit und Leistung beauftragt sind, oft nicht greifbar genug. Tatsächlich aber muss der kulturelle Wandel – der Abbau der Silos innerhalb und zwischen den Gruppen – stattfinden, und zwar lieber früher als später. 

Dies gilt insbesondere im Hinblick auf die Auswirkungen neuer Trends und Architekturen auf das Netzwerk.

Viele netzwerkorientierte Führungskräfte und Praktiker schenken der sich verändernden App-Architekturlandschaft nicht so viel Aufmerksamkeit. Der Trend zu APIs und Microservices ist beispielsweise im Bereich der Netzwerke selten ein Thema, das wir wirklich diskutieren, abgesehen von der Tatsache, dass auch unsere Infrastruktur über eine API verfügt. Weil SDN (oder SDDC).

Aber sie müssen sich dieser Änderungen bewusst sein und wissen, welche Auswirkungen sie (nicht ob, sondern werden) auf das Netzwerk und die Bereitstellung dieser Applications für anspruchsvolle Verbraucher und Mitarbeiter haben werden. Sogar eine Entscheidung, die scheinbar ausschließlich die Application betrifft, kann sich letztlich erheblich auswirken – und zwar nicht nur auf die Netzwerkarchitektur, sondern auch auf die Netzwerkleistung und -anforderungen. Die Entscheidung, ob man sich beispielsweise für Multi-Tenant- oder Single-Tenant-Microservices entscheidet, hat erhebliche Auswirkungen auf die Netzwerkdienste, von der Sicherheit bis hin zum grundlegenden Routing und Switching. Wenn architektonische Entscheidungen hinsichtlich der Verwendung von HTTP/2 oder HTTP/1 in Verbindung mit Microservices nicht berücksichtigt werden, kann dies zu erheblichen Problemen im Netzwerk führen und die Leistung beeinträchtigen.

Entwickler sind sich der Auswirkungen ihrer Architekturen innerhalb und außerhalb ihrer Domäne zunehmend bewusst. Die Dienstlatenz (die Zeit, die zwei Dienste benötigen, um über das Netzwerk zu kommunizieren) ist in einer stark verteilten Application ein wohlbekanntes Problem. Was Entwickler nicht wissen, ist, wie das Netzwerk (und sein Dienstestapel) dazu beitragen kann, die negativen Auswirkungen auf die Leistung (und Ausfallsicherheit) einer solchen Umgebung zu verringern. 

Das wissen Netzwerker.

Das Problem besteht darin, dass Netzwerker erst dann einbezogen werden, wenn elfzig Milliarden Microservices in die Produktion gehen. Sie wurden nicht konsultiert und wenn sie zu diesem Zeitpunkt einbezogen werden, können Vorschläge dazu führen, dass die Dienste oder die Application erheblich überarbeitet werden müssen. Sogar eine einfache Änderung, bei der die Skalierbarkeit in das Netzwerk statt intern in die App interpoliert wird, wird zum Albtraum. Wären die Dienste jedoch mit Blick auf die Skalierbarkeit des Netzwerks konzipiert worden, würde alles reibungslos verlaufen.

Aber das war nicht der Fall. Und warum fühlen sich 9 von 10 Führungskräften unter Druck, ihre Apps schneller auf den Markt zu bringen ? Sie stehen noch stärker unter Druck, weil die notwendigen Änderungen am Netzwerk, die zur Bereitstellung derart vieler miteinander verbundener, verknüpfter und voneinander abhängiger Dienste erforderlich sind, Zeit in Anspruch nehmen.

SDN vs. DevOps SOAD

In der IT gibt es vier Operationen: Infrastruktur, Netzwerk, Speicher und Sicherheit. Und alle vier Silos (oder Türme, wenn Sie eine mittelalterlichere Metapher bevorzugen) müssen Brücken zwischen den anderen bauen, die die Zusammenarbeit und Kommunikation früher im Entwicklungszyklus fördern. Die Zusammenarbeit bei Architekturentscheidungen sollte während des Entwurfs erfolgen, nicht während der Bereitstellung. Und diese Zusammenarbeit muss möglicherweise von Führungskräften initiiert werden, die Einblick in die einzelnen Organisationen haben, um zu wissen, wann neue Technologien und Architekturen in Betracht gezogen werden.

Bei DevOps geht es nicht nur um Automatisierung – es ist ein Werkzeug und eine Technik zum Erreichen eines Ziels. Mithilfe der Automatisierung lässt sich die Belastung derjenigen erheblich verringern, die mit der Bereitstellung der für die Implementierung und Auslieferung von Apps erforderlichen Dienste beauftragt sind. So werden Experten in allen vier Betriebsbereichen entlastet. Gibt ihnen die Freiheit, sich stärker an der Zusammenarbeit und dem Austausch zwischen Organisationen zu beteiligen und so Umfang, Leistung und Sicherheit der Applications zu verbessern, die für die wachsende App-Wirtschaft von zentraler Bedeutung sind.

Der Geschäftserfolg und das Wachstum hängen von der Zusammenarbeit innerhalb der IT ab, nicht nur an den Fronten, sondern auch auf Führungsebene.