Skalierung der Infrastruktur in Krisenzeiten Wie Dev und Ops noch enger zusammenarbeiten

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

VMware Global Inc Zweigndl. Deutschland

Für IT-Teams hat die COVID-19-Krise viele Herausforderungen und Veränderungen mit sich gebracht. Die schnellere Entwicklung und Bereitstellung von Software, die vielerorts zur Bewältigung der Krise benötigt wird, ist dabei ein Teilaspekt. Doch wie lässt sich die Teamarbeit noch effizienter gestalten?

Im Zuge der Pandemie wurde schnell klar: neue Software-Lösungen müssen her. Krankenhäuser brauchen eine Echtzeit-Ansicht der Intensivbetten und der Verfügbarkeit von Beatmungsgeräten. Regierungen nutzen Tracking-Technologien, um durch die Rückverfolgung von Kontakten die Zahl der Infektionen einzudämmen. Finanzinstitute unterstüzen Geschäfts- und Privatkunden bei den wirtschaftlichen Folgen der Krise.

Die Skalierung bestehender Systeme allein ist schon schwierig. Die Skalierung bestehender Systeme bei gleichzeitiger Einführung neuer und landesweit skalierbarer Anwendungen kann sogar unmöglich erscheinen. Cloud-native Methoden und Technologien können dabei eine große Hilfe sein – leider sind sie für die meisten Organisationen aber noch lange nicht selbstverständlich.

Was also können IT-Teams tun? Schließlich lassen sich Architekturen nicht von einem auf den nächsten Tag grundlegend ändern. Beim menschlichen Verhalten sieht es aber schon ganz anders aus – besonders in Krisenzeiten. Um zu skalieren und schneller zur Produktion zu gelangen, müssen sowohl die Entwickler als auch die Operations Manager ihren jeweiligen Beitrag zu einer noch engeren und effizienteren Zusammenarbeit leisten – jetzt und auch in Zukunft.

Hürden, die einer engeren Zusammenarbeit oft im Wege stehen

Bevor wir untersuchen, wie Entwickler und Operations Manager sich gegenseitig helfen können, muss zunächst geklärt werden, was der Skalierung und einer schnellen Markteinführung derzeit im Wege steht. Einige der größeren, systemischen Gründe sind oft:

Mismatch bei Zielen und Vorgaben

Operations Teams konzentrieren sich oft auf Kosten und Stabilität und werden an diesen Kennzahlen gemessen. Die Betriebszeit aufrechtzuerhalten und die Kosten zu senken, ist für sie das Gebot der Stunde. Dies ist zwar wichtig, passt aber oftmals nicht gut zu Veränderungen – und Skalierungen und neue Funktionen oder Anwendungen bringen zwangsläufig Veränderungen mit sich.

Im Gegensatz dazu sind Entwickler oft stärker auf die Geschäftsziele ausgerichtet und lassen sich an der Geschwindigkeit neuer Funktionen messen. Mit anderen Worten, bei ihnen dreht sich alles um Veränderungen, und manchmal ist Stabilität ein nachträglicher Gedanke – oder schlimmer noch: "das Problem von jemand anderem".

Mismatch bei Entwicklungs- und Produktionsumgebungen

Wenn unterschiedliche Infrastrukturen und Werkzeuge in der Entwicklung bzw. der Produktion verwendet werden, entsteht eine Barriere zwischen Dev und Ops. „Funktionierte bei den Entwicklern, jetzt Probleme bei Operations“ ist der klassische Refrain, der sich aus dieser Dynamik ergibt. Dies verlangsamt den Übergang in die Produktion, weil neue Probleme in Test- und Produktions-Umgebungen auftauchen. Es verlangsamt aber auch die Fehlerbehebung bei Zwischenfällen, was häufig zu einer längeren mittleren Reparaturzeit (MTTR) führt.

Tipps, wie Entwickler den Operations Managern helfen können

Ops-Teams tragen die Verantwortung für die Betriebszeit und haben in der Vergangenheit viel Zeit damit verbracht, die Verfügbarkeit der Infrastruktur sicherzustellen. In einer Cloud-nativen Welt wird dieses Prinzip auf den Kopf gestellt, da die Infrastruktur generell als unzuverlässig gilt. Ops-Teams können jedoch mit dem Code selber nicht viel anfangen. Daher liegt es nun mehr denn je an den Entwicklern, ihren Code Betriebszeit-freundlicher und skalierbarer zu machen:

• Die „Observability“ (Beobachtbarkeit) des Codes gewährleisten: Den Code von Anfang an zu instrumentieren, zahlt sich auf lange Sicht aus. Spring hat dies mit Spring Boot Actuators und Micrometer relativ einfach gemacht. Je schneller die Gründe für Ausfallzeiten erkannt werden, desto höher ist die Betriebszeit. Gängige Werkzeuge für die Überwachung und Beobachtbarkeit tragen ebenfalls dazu bei, den Mis-Match zwischen Entwicklung und Produktion zu überbrücken.

• Sicherstellen, dass die Anwendung neu gestartet werden kann: Wenn es 15 verschiedene Schritte und eine strikte Reihenfolge für den Start der Anwendung gibt, wird dies die Betriebszeit und Skalierung deutlich erschweren. Wenn es 30 Minuten dauert, alle logischen Schichten der Anwendung zu booten, lässt sie sich im Falle eines Fehlers nur unter viel Aufwand in eine gesunde Infrastruktur verschieben.
  Je schneller und einfacher sich die Anwendung neu starten lässt, desto widerstandsfähiger wird sie gegen Ausfälle. Dies ist sowohl ein Teil des 12-Faktor-Prinzips als auch eine grundlegende Annahme bei der Verwendung eines Systems wie Kubernetes, das Starts und Neustarts in einer unendlichen Abstimmungsschleife automatisiert.

• Für zustandslose Prozesse sorgen, wo immer es geht: Dies ist ebenfalls ein klassisches 12-Faktor-Prinzip und macht einen großen Unterschied bei der Skalierung. Die Speicherung des Zustands in der Anwendung bringt alle Arten von Komplexität bei der Datenverwaltung mit sich. Je mehr Prozesse stateless laufen, desto mehr lässt sich die Datenschicht und ihre Komplexität isolieren.

Indem Entwickler darüber nachdenken, wie sie den Code freundlicher und skalierbarer für das Operations Team machen, helfen sie Ops-Teams bei ihren Zielen und Aufgaben. Dies hilft nicht nur bei der Überbrückung der Mismatches – es trägt letztlich auch zu einem besseren Kundenerlebnis bei, insbesondere in dieser Krise, in der die Kunden stark auf digitale Kanäle angewiesen sind.

Tipps, wie Operations Manager die Entwickler unterstützen können

Wenn Entwickler Ops-Teams helfen können, indem sie ihren Anliegen entgegenkommen, dann gilt dasselbe auch umgekehrt.

• Den Weg zur Produktion beschleunigen: Niemand wartet gerne – auch oder vielleicht sogar insbesondere Entwickler nicht. Ob sie auf eine Entwicklungsumgebung warten, auf ein Zeitfenster für Änderungen oder auf einen beliebigen Kontrollpunkt, um Code in die Produktion zu bringen. Operations Manager sollten nach Möglichkeiten versuchen, das Warten für Entwickler zu verkürzen.

• In einen Zuhör-Rhythmus kommen: Ops-Teams können ein besseres Gefühl für die Entwickler und ihre Bedürfnisse bekommen, indem sie einfach mehr Zeit mit ihnen verbringen. Die Planung von Bürozeiten, der Besuch von Entwickler-Teamsitzungen und die Bitte um Feedback sind einige schnelle Änderungen. Wenn Ops-Teams bisher 10 Prozent ihrer Zeit mit Entwicklern verbringen, sollten sie versuchen, auf 30 Prozent zu kommen. Wenn es 30 Prozent sind, sollte 50 Prozent das neue Ziel sein.

• Wege finden, öfter „Ja“ zu sagen: Das Wort „Nein“ geht Menschen allzu leicht über die Lippen – ein natürlicher Instinkt, mit dem sie sich vor Komplexität und Chaos schützen wollen. Auf diese Weise brennen aber Brücken schneller nieder als Feuer. Wenn Anfragen von Entwicklern eintreffen, sollten Operations Manager daher gründlich überlegen, ob es einen Weg geben könnte, Ja zu sagen. Eine hilfreiche Methode ist dabei, zunächst der Frage auf den Grund zu gehen, warum etwas angefordert wird.

Fazit

Für Unternehmen, die schon vor der Krise auf dem Weg zu Cloud-Native waren, hat die Pandemie ihre Investition in diesen schwierigen Veränderungsprozess bestätigt. Von der Einführung neuer Anwendungen innerhalb weniger Tage bis hin zur zehnfachen Skalierung ohne weitere Probleme, zahlen sich die neuen Muster und Technologien aus.

Sie lassen sich nicht über Nacht umsetzen, aber mit kleinen Schritten von jedem Einzelnen im Team kann die Skalierung, Betriebszeit und Geschwindigkeit bis zur Markteinführung zunehmend nahtloser gestaltet werden. Die Herausforderungen von COVID-19 wirken wie ein Katalysator für das, was zuvor bereits erforderlich war und in Zukunft immer mehr gefragt sein wird: eine engere Zusammenarbeit zwischen Entwicklern und Operations Managern.

* Frederik Bijlsma ist Head of Sales CEMEA bei VMware Tanzu und leitet somit den Vertrieb für das Tanzu-Portfolio. Zuvor war er als Director Sales CEMEA Benelux, Switzerland, Nordics and Government bei Pivotal sowie als VP Sales bei TeleStax zuständig.

(ID:46666338)