Vorteile und Änderungen zwischen Innovation und Alltagsbetrieb

DevOps: was, wofür und wie?

| Autor / Redakteur: John Gentry / Ludger Schmitz

DevOps verlangt Zusammenarbeit
DevOps verlangt Zusammenarbeit (Bild: 3dman_eu, Pixabay / CC0)

Schneller ist besser, aber nur wenn die Qualität nicht darunter leidet. Wenn Unternehmen ständig neue Features und Software bieten wollen, müssen sie ihre Softwareentwicklung und IT-Operationen genauer unter die Lupe nehmen und DevOps anstreben.

Die Bezeichnung DevOps beruht auf der engen Beziehung zwischen den Entwicklungs- und IT-Operations-Teams, die über ihren Tellerrand schauen, um mehr operative Agilität zu erreichen. Das Ziel ist die Verbesserung der allgemeinen Beziehung, Effizienz und des Tempos der beiden häufig sehr unterschiedlichen Lager. Und dafür ist eine schnellere und präzisere Kommunikation und Zusammenarbeit nötig. Die Erwartung an diese Theorie ist, dass Unternehmen dadurch schneller und kontinuierlicher Innovationen hervorbringen können.

Die Schwächen alter Methoden - und die der Agilität um jeden Preis

Die Unternehmen in allen Industrien müssen ständig neue Innovationen hervorbringen. Sie müssen die Anwendungen für Endbenutzer mit Funktionalität und Features ausstatten – und das Gleiche gilt für die zugehörigen Systeme und Prozesse. Neue Versionen und gänzlich neue Produkte müssen pünktlich geliefert werden und dürfen das zugewiesene Budget nicht überschreiten.

In dieser Hinsicht können andere Methoden möglicherweise nicht mehr mithalten. Bei der agilen Softwareentwicklung kann ein Unternehmen beispielsweise nicht genau wissen, wie ein neues Softwareangebot in der realen Welt eingesetzt und welchen Stresstests es unterzogen wird, bevor es tatsächlich entwickelt und eingesetzt wird. Dadurch ist es unmöglich, die Auswirkungen auf die Operationen vorherzusehen. Das macht es wiederum beinahe unmöglich, in den Planungs-, Genehmigungs- und Entwicklungsphasen den ROI zu berechnen.

Die Unternehmen springen also eigentlich ins kalte Wasser: Sie wissen nicht, wie viel ein Projekt kosten, wie lange es dauern und welchen Wert es liefern wird. Ein Projekt zu starten, ohne ein klares Bild der Kosten und benötigen Ressourcen zu haben, um bestimmen zu können, ob es überhaupt durchgeführt werden kann und wann es fertiggestellt wird, ist unverantwortlich, wenn nicht gar grob fahrlässig.

Das warnende Beispiel Samsung

Ein typisches Beispiel ist der Rückruf des Samsung Galaxy 7 Note und die Krise des Unternehmens, nachdem bekannt geworden ist, dass die Geräte durch die Akkus explodieren oder in Flammen aufgehen können. Die logische Erklärung ist, dass die Entwicklung und das Q&A überstürzt wurden, um mit dem neuesten iPhone Schritt zu halten. Das Unternehmen hat Milliarden Dollar und womöglich für immer das Vertrauen vieler Kunden verloren.

Die möglichen Unbekannten in der Produktentwicklung sind es, in denen DevOps klar den anderen Methoden überlegen ist. DevOps konzentriert sich auf kurze Zwei- oder Dreitagessprints im Rahmen von 30-tägigen Zeitrahmen für ein Projekt. Diese kurzen Zeiträume bieten einige Vorteile. Zunächst einmal ermöglichen sie das häufige Rollout von Features, Software, Feedbackzyklen und Fehlerkorrekturen. Durch die gleichzeitige tägliche Weiterentwicklung der Kunden- und Geschäftsanforderungen werden diese kurzen, zuverlässigen Entwicklungszeiten immer notwendiger.

Vorteile der kleinen Sprints

Diese Sprints helfen auch im Bereich der Budgetberechnung und Erwartungen an ein Produkt. Kürzere Projekte mit definierten Zielen sind von Natur aus einfacher einzuschätzen. Das gilt sowohl für die Rendite als auch die Kosten für die benötigten Ressourcen. Die Sprints können zudem nach Bedarf stattfinden und nicht aufgrund eines zufällig festgelegten Zeitplans, der keine Rücksicht auf die Anforderungen spezifischer Kunden oder Geschäftsbereiche nimmt, die extrem von häufigen Innovationen abhängen.

Last not least bieten DevOps Unternehmen eine Grundlage für die Produktion von Lösungen, ohne den Kosten- und Zeitrahmen zu sprengen. Diese Lösungen entsprechen genau dem, was das Unternehmen benötigt, und werden effizient sowie gemeinschaftlich entwickelt.

Änderungen: Kultur und Technologie

Die Einführung des DevOps-Verfahrens ist nicht so einfach wie das Umlegen eines Schalters oder die Installation einer App. Ein Unternehmen muss sich voll und ganz den Änderungen verschreiben, die die Einführung für die Kulturen und Technologien seiner Entwicklungs- und IT-Teams bedeutet.

Eine drastische Änderung für viele Unternehmen betrifft Kultur und Technologie, da sie sich vom Konzept der IT als Utility verabschieden müssen. Gartners bimodales Konzept der IT bietet eine Möglichkeit, diese Verschiebung zu verstehen. Einfach ausgedrückt, wird die IT in zwei Bereiche unterteilt: der traditionellere Bereich, der für Support und Sicherheit verantwortlich ist, und der Bereich für Innovationen und die kontinuierliche Verbesserung der Geschäftsabläufe.

Die Bimodalität der IT...

Ganz klar wird es immer eine Nachfrage nach dem ersten Bereich geben. Und hier kommen die Dienstleistungsanbieter ins Spiel. Doch die ausschließliche Übertragung der IT an Dienstleistungsanbieter war in der Vergangenheit für zahlreiche Unternehmen sicherlich sinnvoll. Doch tatsächlich wird dadurch die Kapazität des Unternehmens, den zweiten Bereich abzudecken, eingeschränkt.

Es ist dieser zweite Bereich – Innovation und Verbesserung von Geschäftsabläufen –, in dem DevOps einen Mehrwert bietet. Es ist auch nicht überraschend, dass er auch der Grund für zahlreiche weitere notwendige Änderungen ist.

...führt zu ihrer Spaltung

Was die Unternehmenskultur angeht, kann DevOps die traditionelle Personaleinteilung von Unternehmen durchaus auf den Kopf stellen. In der Vergangenheit waren die Entwickler immer die „Macher“ neuer Software, neuer Angebote, neuer Funktionen. Die Aufgabe der Operations-Teams war es hauptsächlich, diese Produkte in der Produktionsumgebung zu verwalten. Und wie Rudyard Kipling sagte: „und niemals treffen sich die beiden“.

Mit dem DevOps-Ansatz können diese beiden traditionell getrennten Teams jetzt eng zusammenarbeiten. Obwohl das die Entwicklung und das Deployment von Lösungen beschleunigt, besteht auch keine geringe Wahrscheinlichkeit von Reibungen. Im DevOps-Modell müssen beide – die Entwicklungs- und Operationsteams – die Sicht auf ihre Rolle ändern.

Noch einmal lernen: Kooperation

Das ist aber nicht einfach. Bei dieser Änderung geht es nicht nur um Mentalitäten; es sind konkrete Handlungen erforderlich. Man benötigt ein gemeinsames Verstehen und gemeinsame Informationen darüber, wie Anwendungsänderungen sich in einer Infrastruktur auswirken.

Die Mitarbeiter auf beiden Seiten müssen wahrscheinlich neu geschult werden. Sie müssen lernen, wie DevOps funktioniert, und sie müssen sich mit ihren neuen Rollen vertraut machen. Die Leute verlieren nicht ihre Arbeit, aber sie müssen mehr Fähigkeiten in Sachen Zusammenarbeit lernen, damit DevOps so effektiv wie möglich ist.

Auch wenn es nicht unbedingt eine kulturelle Änderung ist, kann ein internes Audit bei der Einführung von DevOps sehr nützlich sein. Größere interne Kontroll- und Compliance-Probleme gibt es in vielen Unternehmen. Wenn Sie frühzeitig im Umstellungsprozess erkannt werden, lassen sich spätere Kopfschmerzen vermeiden. Sobald die Entwicklungssprints und die 30-Tages-Zeitpläne Realität geworden sind, könnte beispielsweise ein Gesetz, das übersehen wurde, die Abläufe zum Stehen bringen.

Enablement: Analyse-basierte Entscheidungen

Damit das DevOps-Modell gut funktioniert, müssen vorhandene Technologien angepasst werden. Der Nutzen von DevOps stellt sich nicht von selbst ein. Dafür sind Entwicklungen, Tests und Releases von Anwendungen und Workloads in einem sehr hohen Tempo nötig. Um vollständig zu verstehen, wie viel ein Projekt kosten, wie lange es dauern, und welchen Nutzen es bieten wird, müssen Technologien und Abläufe verbessert werden.

Die Zusammenarbeit im DevOps-Modell muss auf exakten und zuverlässigen Daten beruhen. Damit können dann ruhigen Gewissens schnelle Entscheidungen getroffen werden. Ohne diese Grundlage riskieren die Teams, Code zu veröffentlichen, der die Benutzererfahrung verschlechtert.

Speziell die Analyse von Simulierungen, Tests und Validierungen von Workload-Performance sind in Testumgebungen unentbehrlich. In den Produktionsumgebungen muss es integriertes Performance-Monitoring und Analysen in Echtzeit geben. Diese Komplettlösung muss sich durch den gesamten Entwicklungszyklus ziehen, um alle nötigen Informationen für die Entscheidungsfindung und optimale Kontrolle liefern zu können.

Auf der Basis von Fakten arbeiten

Diese situationsbezogenen Daten in Echtzeit aus der „echten Welt“ ermöglichen dann ein umfassendes Verständnis davon, wie Änderungen in den Anwendungs-Workloads die Performance der Produktionsinfrastruktur beeinflussen. Dadurch können die kombinierten Teams ihre Infrastruktur justieren, sobald Änderungen und Verschiebungen auftreten, ohne dass die Endbenutzer davon betroffen werden. Das Wissen und die Informationen, die mit jedem neuen Release entstehen, bringen am Ende eine garantierte Performance, geringere Kosten, kürzere Zeitrahmen und die allgemeine Verbesserung der IT-Effizienz. All das Dinge, die DevOps verspricht.

Es ist offensichtlich, dass DevOps das Potenzial hat, es Unternehmen zu ermöglichen, sich parallel zu den sich stetig ändernden Geschäftsumgebungen zu entwickeln. Damit DevOps aber von Erfolg gekrönt ist, muss eine datenbasierte, einheitliche Zusammenarbeit zwischen den IT- und den Entwicklungsteams sichergestellt werden. Sobald das der Fall ist, profitiert das gesamte Unternehmen von geringeren Kosten, kürzeren Entwicklungszeiten und schlussendlich von einer effizienteren, agileren Unternehmen.

* John Gentry ist Chief Technology Officer bei Virtual Instruments.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44980986 / Configuration-Management)