Komplexe Strukturen bremsen die Software-Bereitstellung? Mit dem DevOps-Ansatz arbeiten Entwicklung und Operations Hand und Hand. [...]
Es ist die geschäftskritischste Anwendung der DZ Bank und sie muss rund um die Uhr funktionieren: die Handelsplattform. Etwa 1000 Benutzer führen darauf Käufe und Verkäufe aus, weitere 2000 nutzen die Handelsplattform unter anderem für die Risikoüberwachung und das Erstellen von Berichten. Wenn die Plattform stillsteht, dann ist das Geschäft der zweitgrößten Geschäftsbank Deutschlands gefährdet. Und dennoch fasste die IT-Leitung der DZ Bank – der rund 800 Genossenschaftsbanken in Deutschland angeschlossen sind – vor wenigen Jahren einen mutigen Entschluss: Sie startete eine Standardisierung der Prozessabläufe für alle Software-Entwicklerteams, die Einführung reproduzierbarer und revisionsfähiger Prozesse sowie die Beschleunigung der Freigabe neuer Software-Funktionen.
Und die Neuerungen wurden ausgerechnet direkt auf die so wichtige Handelsplattform angewendet. Dazu kam: Der neu konzipierte Prozess wurde an einem einzigen Wochenende ausgerollt.
Die Deutsche Zentral-Genossenschaftbank hat sich für einen Weg entschieden, den derzeit viele Unternehmen unterschiedlichster Größe gehen: Sie setzt bei der Software-Bereitstellung auf das DevOps-Konzept.
Damit geht die DZ Bank ein Thema an, das viele Betriebe rund um den Erdball und quer durch alle Branchen bewegt: Um auf dem Markt relevant zu bleiben, ist es unerlässlich, dass die Innovationszyklen immer kürzer werden. „Die Umstellung von klassischen Methoden auf agile(re) Ansätze ist in diesem Wettlauf gegen die Zeit ein elementares Werkzeug“, so die klare Aussage der Wirtschaftsprüfungs- und Beratungsgesellschaft PricewaterhouseCoopers in ihrer Studie „Realitätscheck DevOps – Vor welchen Herausforderungen stehen Unternehmen bei der Einführung“.
Verbesserte Zusammenarbeit
Doch was genau verbirgt sich hinter DevOps? Der Begriff ist nicht eindeutig bestimmt. Grundsätzlich beschreibt DevOps eine kombinierte Rolle im Unternehmen, die sowohl die Entwicklung (Development) als auch den Betrieb von Software (Operations) umfasst. „Am besten bringt das für mich der von Amazon geprägte Ansatz auf den Punkt: ,You build it, you run it‘“, erklärt Vassil Hristov. Damit ist gemeint, dass jedes Team nicht nur für das Schreiben der Software verantwortlich ist, sondern auch für deren Betrieb, so der Co-Founder des IT-Beratungsunternehmens Zest Labs.
Damit bringe der DevOps-Ansatz viele Vorteile gegenüber dem alten Ansatz mit verschiedenen Silos von Entwicklern und Systemadministratoren, bei dem ein Team die Software entwickelt und sie – im Idealfall gut dokumentiert – an die Systemadministratoren übergebe. „Sie müssen dann dafür sorgen, dass die Software richtig und unterbrechungsfrei läuft.“
Wenn es dann aber einmal zu Problemen komme, dann verursache das in der Regel hohen Abstimmungsaufwand zwischen den Teams. Wenn hingegen das Team, das die Software schreibt, auch für den Betrieb verantwortlich sei, dann fielen nicht nur die langen Kommunikationswege weg. „Plakativ gesprochen: Wenn man weiß, dass das eigene Handy nachts klingelt, wenn etwas nicht richtig funktioniert, ist man auch motivierter, dafür zu sorgen, dass die Software stabil läuft“, fasst Vassil Hristov zusammen.
Eine laut Hristov weitere sehr verbreitete Interpretation von DevOps ist das von Google geprägte Konzept der sogenannten Site Reliability Engineers (SRE). Dort gebe es weiterhin Teams, die sich auf das Betreiben von Software fokussieren, aber anders als beim klassischen Systemadministrator setze man bei SRE mehr auf Automatisierung und Observability, also Beobachtbarkeit. „Kombiniert mit modernen Technologien – zum Beispiel Cloud, Kubernetes, Microservices – erlaubt es der Ansatz, schneller Fehler zu beheben. Im Idealfall erkennt und behebt das System Fehler alleine.“
DevOps bezeichnet ein Organisationsmodell, das darauf abzielt, Applikationen durch ein Team vollumfänglich zu betreuen – „von A wie Anforderungsanalyse bis hin zu Z wie Zero Downtime“, ergänzt Lutz Keller. Das Zusammenführen der Verantwortlichkeiten in einem Team führe zu äußerst kurzen Feedback-Schleifen, deren Ergebnisse durch ebenfalls sehr kurze Deployment-Zyklen schnell in Produktion gebracht werden könnten. Dafür kommen laut dem Leiter DevOps bei der IT-Beratung Consol Methoden wie Continuous Integration/Continuous Delivery (CI/CD) zum Einsatz. Der Hauptvorteil laut Keller: „Dem Anwender beziehungsweise dem Kunden werden Verbesserungen viel schneller zugänglich gemacht.“
Frank Haumann, Partner beim Dienstleister Red Reply, unterstreicht, es sei wichtig, DevOps nicht als Technologie zu verstehen, sondern als Organisationsmodell. Noch treffender sei, DevOps als „Kultur“ zu bezeichnen. „Im Vordergrund steht die sehr enge Zusammenarbeit von Development und Operations.“Diese Art der Zusammenarbeit bei der Software-Entwicklung führt zu Veränderungen wie einem agilen Mindset und einer agilen Unternehmenskultur, in der Mitarbeiter auch Fehler machen dürfen. So erkennen Software-Developer, aber auch Produktentwickler Fehlerquellen schneller und können durch den offenen Austausch im Team bessere Lösungen entwickeln.
„Dass bei DevOps Entwicklung und Betrieb zusammenarbeiten, ist eine bewusste Entscheidung der Organisation. Das Team steht im Zentrum und es erhält alle nötigen Technologien und Prozesse für die enge Zusammenarbeit – mit möglichst wenigen Medienbrüchen“, ergänzt Aian Hundegger, Manager und Expertise Lead bei der Management- und Technologieberatung Campana & Schott. Alle Beteiligten hätten entsprechend Zugriff auf die genutzten Informationen und Dokumente.
Nisha Lehmann untermauert die Vorteile von DevOps mit konkreten Zahlen: „Traditionelle Ops sind im Schnitt 41 Prozent zeitaufwendiger als DevOps, auch weil sie 21 Prozent mehr Zeit mit Bugfixing und Optimierung verbringen“, so die Managerin für Customer-Success bei Merkle, einer Agentur mit Fokus auf der Transformation der Customer-Experience. DevOps bearbeite Support-Fälle zudem 60 Prozent schneller und könne so ein Drittel mehr Zeit in die Verbesserung der Infrastruktur stecken.
„Das bemerken auch die Unternehmen: Von den DevOps-Adoptern berichtet über die Hälfte von verbesserter Kooperation und fast jeder Vierte von höherer Code-Qualität.“ Ihr Fazit: DevOps sei effizienter und spare Kosten. Durch die Automatisierung von Konfiguration, Bereitstellung, Tests, Warnmeldungen und Überwachung könne ein kleines DevOps-Team dieselben Anwendungen warten, für die früher ein viel größeres Team nötig war.
DevOps versus Agilität
Häufig wird in einem Atemzug mit DevOps auch der Begriff Agilität genannt. Während es bei DevOps um Verantwortlichkeiten geht, versteht man unter Agilität Methoden wie Scrum oder Kanban. Diese ermöglichen es, schnell auf neue Anforderungen zu reagieren. Und hier zeigt sich auch, weshalb DevOps und Agilität meist zusammengehören: Die beiden Felder ergänzen sich hervorragend. „Während mit DevOps die notwendigen Strukturen geschaffen werden, sorgen die agilen Vorgehensmodelle für die passende Prozessgrundlage“, erläutert Lutz Keller von Consol.
Agilität spielt aber nicht nur in der Software-Welt, sondern in der Projektarbeit generell eine wichtige Rolle. Zwar liegen die Ursprünge zum Beispiel des Scrum-Ansatzes in der Software-Entwicklung, er ist jedoch universell einsetzbar. „Der ,Teile und herrsche‘-Ansatz, der den kurzen Scrum-Sprints zugrunde liegt, ist ja schon seit der Römerzeit verbreitet und lässt sich problemlos auf andere Gebiete anwenden“, so Vassil Hristov.
Für ihn beschreibe Agilität, Aufgaben und Probleme systematisch anzugehen und zu lösen. Bei DevOps gehe es hingegen primär um die Aufteilung der Verantwortung und des Wissens innerhalb des Teams, mit einem zusätzlichen Fokus auf Automatisierung. „Es gibt durchaus agile Teams, die aus verschiedenen Gründen den DevOps-Ansatz nicht leben“, so Hristov, „genauso wie es Teams gibt, die noch ein Wasserfallmodell befolgen und trotzdem auf DevOps-Elemente im Alltag setzen.“
„Agilität ist die Fähigkeit eines Teams oder einer Organisation, trotz einer sich ständig verändernden Welt regelmäßig nutzenstiftende Ergebnisse zu erzeugen. Es zählt also nicht nur die schnelle Anpassungsfähigkeit, sondern auch der Fokus auf das Endergebnis“, erklärt Aian Hundegger. DevOps hingegen sei das Mittel zum Zweck, um dieses Endergebnis zu erreichen – „also eine mögliche Methode im Produktentwicklungsbereich, kontinuierlich System-Updates aufzuspielen, ohne den laufenden Betrieb aufzuhalten“.
„Agile Konzepte sind organisatorischer Art – DevOps ist für die Technik“
Technology (c) Engel & Völkers
Das Unternehmen Engel & Völkers hat sich zum Ziel gesetzt, sich zu einem komplett digitalen Immobilienmakler zu wandeln. Die Tochterfirma Engel & Völkers Technology übernimmt dabei die Entwicklung und Umsetzung der digitalen Plattformen.
Im Interview mit com! professional spricht DevOps Lead Robin Wittler über die Vorteile des DevOps-Konzept und wie die Umsetzung bei dem Immobilienmakler in der Praxis aussieht.
com! professional: Herr Wittler, klären wir zunächst einmal Grundsätzliches: Die Begriffe DevOps und Agilität werden meist in einem Atemzug genannt. Aber man kann auch ohne DevOps agil sein. Wie würden Sie die Begriffe voneinander abgrenzen?
Robin Wittler: Agile Konzepte sind für mich eher organisatorischer Art. Es geht oftmals um Effizienz, zum Beispiel durch das Weglassen von Prozessen, die einen hohen Overhead haben oder einen störenden Einfluss von außen bedeuten. Der Fokus liegt auf den wichtigen Teilen innerhalb eines Entwicklungszyklus: klare Zieldefinitionen, Einschätzung und Kommunikation von Aufwänden und Zeiträumen zum Kunden beziehungsweise zu den Stakeholdern, Implementieren und Testen – Stichwort Fail fast –, Feedback bekommen und geben über das neu Erlernte. Es geht also auch um das Entwickeln einer gesunden Fehlerkultur.
com! professional: Und wie definieren Sie DevOps?
Wittler: DevOps wiederum ist für mich eher die technische Seite. Da geht es um den sinnvollen Einsatz von Programmiertechniken, um manuelle Handlungen und Arbeitsweisen durch automatisierte Verfahren abzulösen.
com! professional: Was bedeutet das konkret?
Wittler: Änderungen nachverfolgbar und wiederholbar zu machen – egal ob das Ganze einmal oder Hunderte Male ausgeführt wird: Das Ergebnis soll immer das Gleiche sein. In den 1990-Jahren gab es einen Spruch: Ein guter Administrator macht eine immer wiederkehrende Aufgabe genau einmal. Ein guter Administrator hat die Aufgabe also automatisiert.
Das menschliche Gehirn langweilt sich bei repetitiven Aufgaben und fängt an, uns Streiche zu spielen: Dann werden Punkte auf Checklisten in anderer Reihenfolge abgearbeitet oder Details ausgelassen – was natürlich, in immer komplexer werdenden IT-Umgebungen, für spannende, aber teure Phänomene sorgen kann.
com! professional: Welche weiteren Vorteile bringt das DevOps-Konzept mit sich?
Wittler: Ein toller Nebeneffekt ist, dass Änderungen oftmals auch schneller ausgerollt sind. DevOps kann auch helfen, notwendiges Spezialwissen für andere zugänglicher zu gestalten – also zum Beispiel das Bereitstellen von imperativen Funktionen über deklarative Anweisungen. Oder einfacher ausgedrückt: Ein Kunde muss nicht mehr das Wissen haben, wie eine bestimmte Firewall funktioniert – er beschreibt einfach zum Beispiel in einem simplen YAML-Format (Anm. der Red.: eine vereinfachte Auszeichnungssprache zur Datenserialisierung), was er braucht, und das wird von einem Tool automatisch umgesetzt – egal ob das Produkt von Hersteller A oder Hersteller B kommt.
com! professional: Schauen wir einmal in die Praxis: Was umfasst das Thema DevOps bei Engel & Völkers?
Wittler: Das betrifft ein breites Spektrum. Implementierung der CI/CD-Pipelines, Definition und Ausrollen der Infrastruktur, Entwickeln, Bereitstellen und Betreiben von API-getriebenen Services, über die andere Teams dann Änderungen an der Infrastruktur steuern können. Das automatisierte Erstellen von Usern oder das Steuern von Berechtigungen ist genauso ein Teil von DevOps wie die Änderung einer Firewall-Regel. Das Einbinden von Monitoring zum Zweck der Funktionsüberwachung sowie das Sammeln von Performance-Daten sind ein weiterer Bereich.
com! professional: Und welche Tools setzen Sie im Bereich DevOps konkret ein?
Wittler: Das Tooling ist recht vielfältig, da Mitglieder von Projekten mitunter signifikant unterschiedlichen Anforderungen gegenüberstehen sowie unterschiedliche Wissensstände und Fähigkeiten mitbringen. Aber die allgemeine Schnittmenge beinhaltet: Kubernetes, Versionskontrollsysteme (bei uns in Form von GIT), CI/CD-Systeme (Gitlab und Github), Helm, Kustomize & Ksplit, Terraform/Terragrunt und Pulumi sowie Programmiersprachen wie Go und Python.
com! professional: Wenn man von DevOps redet, dann ist oft auch von modernen Infrastrukturen wie der Cloud die Rede. Setzt Engel & Völkers inzwischen auf die Cloud? Oder gibt es weiterhin Legacy-Strukturen, die sich aber dennoch in DevOps-Strukturen einbinden lassen?
Wittler: DevOps kann man mit Cloud-Infrastruktur als auch mit On-Premise-Infrastruktur betreiben. Beides hat seine Vor- und Nachteile – und beides wird dementsprechend bei Engel & Völkers eingesetzt. Richtig ist aber, das On-Premise immer öfter durch Cloud-Infrastruktur abgelöst wird.
com! professional: Auf welche Hindernisse stoßen Sie bei der DevOps-Einführung? Wie reagieren die Mitarbeiter in den unterschiedlichsten Bereichen?
Wittler: Ich habe Engel & Völkers als erstaunlich offen für neue Arbeitsweisen und Ideen kennengelernt. Es ist doch wie fast überall im Leben: Der Kunde ist interessiert daran, dass das Produkt schnell, sicher und stabil läuft. Es ist dann nicht wichtig, ob man es DevOps, Site Reliability Engineering (SRE) oder GitOps nennt.
Fragen über Fragen
„Lasst uns mal schnell agil werden und unsere Produkte schneller auf den Markt werfen“ – so oder ähnlich denken viele Unternehmen. DevOps scheint momentan als eine Art Wunderwaffe angesehen zu werden. Doch ganz so einfach ist es nicht. Zunächst sollten sich Unternehmen darüber klar werden, welches Problem sie mit DevOps eigentlich lösen möchten, so der Rat von PwC. Ein fundierter Beweggrund sei das A und O, um eventuell auftretende Startschwierigkeiten zu vermeiden und alle Beteiligten zu überzeugen.
Sehr häufig wird DevOps vorrangig genutzt, um die Effizienz der IT zu erhöhen. Das ist jedoch zu kurz gedacht: Oberstes Ziel sollte sein, die Effizienz des gesamten Unternehmens zu steigern, indem Marktanforderungen frühzeitig erkannt und Kundenbedürfnisse erfüllt werden.
Der DevOps-Ansatz ist ideal, wenn es zum Beispiel darum geht, auf Software basierende Business-Prozesse schnell in die Praxis zu bringen. Wichtig sind Anpassungen sowohl in der Organisatio, etwa flache Hierarchien, als auch bei den Verantwortlichkeiten für den Roll-out eines Software-Produkts oder eines Dienstes. „Die Technologie ist im Zusammenspiel mit der Software-Entwicklung die Basis, damit dies möglich ist. Aktuell liegt ein Fokus auf den Betriebskosten. Hier verspricht DevOps ein Modell zu sein, das hilft, Kosten einzusparen“, so Frank Haumann von Red Reply. Dies gelte insbesondere dann, wenn man versucht, Kostenreduktionen im Bereich Operations zu realisieren, „in dem die Entwickler gemäß des Leitsatzes ,You build it, you run it‘ auch Verantwortung für den Betrieb der erstellten Lösung liefern“.
Übrigens: Die in vielen Unternehmen nach wie vor eingesetzten Legacy-Strukturen sind kein Hindernis für den DevOps-Ansatz, auch wenn im DevOps-Zusammenhang häufig von modernen Infrastrukturen wie der Cloud die Rede ist. „DevOps lässt sich auch für Legacy-Strukturen einsetzen“, ist Frank Haumann überzeugt, „weil es eine Kultur ist, die auf jede Art von Technik angewendet werden kann.“ Schwierig bis unmöglich werde es jedoch, eine DevOps-Kultur in stark regulierten Umfeldern wie der Gesundheitsbranche, dem Luftfahrtsektor oder in der Finanzindustrie einzuführen – „in diesen Bereichen bestehen oft sehr strikte Regularien, die von diversen Behörden überwacht werden.“
Nichtsdestotrotz wird DevOps – und vor allem das eingangs erwähnte SRE – häufig mit neuen Technologien wie Cloud, Containern und Microservice-Architekturen in Verbindung gebracht. Doch der fundamentale Ansatz hinter DevOps ist Vassil Hristov zufolge unabhängig von den Tools und dem Technologie-Stack. Er teilt die Meinung von Frank Haumann und sagt, dass „nichts dagegen spricht, auch bei Legacy-Systemen die Prozesse so umzustellen, dass die Verantwortung von Entwicklung und Betrieb von Software besser verteilt ist, Silos abgebaut werden und ein erhöhter Automatisierungsgrad gefördert wird“. Als Beispiel nennt er Gitlab und IBM, die an einer DevOps-Lösung für Mainframe-Entwickler arbeiten. „Das zeigt, dass der Ansatz durchaus auch bei Legacy-Technologien angewendet werden kann.“
Es gibt aber durchaus auch Felder, in denen der DevOps-Ansatz wenig sinnvoll ist. DevOps ist zum Beispiel nicht notwendig, wenn es keine oder nur langsame und vorhersehbare Veränderungen gibt. Das ist mitunter in manchen Behörden, im Bildungssektor, bei klassischen Software-Produkten, etwa im Office-Bereich, oder auch in der Lebensmittelbranche der Fall. Komplexe und schnell zu verändernde Produkte, wie große Konzerne sie entwickeln oder einsetzen, erfordern jedoch DevOps. Denn hier geht der Erfolgsweg für Software-Releases oder Produkt-Releases nur über Trial und Error.
Ein weiteres Beispiel wäre Software, die beim Kunden vor Ort installiert ist – die also nicht zentral in der Cloud oder in wenigen Instanzen läuft. Bei einem Produkt, das beim Kunden installiert wird, braucht man natürlich viel mehr Ressourcen für den Betrieb der Software, gegebenenfalls auch für verschiedene Plattformen und verschiedene Versionen des Produkts. Ein kleines Team dürfte nicht in der Lage sein, die Software zu entwickeln und sie gleichzeitig auf Hunderten heterogenen Kundensystemen zu betreiben.
Eine Frage der Kultur
In der Theorie sind die Konzepte DevOps und Agilität ziemlich attraktiv. Doch die Einführung im eigenen Unternehmen erfordert oft einschneidende Veränderungen hinsichtlich der Unternehmenskultur. Vor allem die herkommliche Art des Arbeitens mit streng abgegrenzten Kompetenzbereichen verträgt sich anfangs möglicherweise nicht mit dem DevOps-Ansatz. Wichtige Bestandteile einer DevOps-Kultur sind Mut, Vertrauen und Aufgeschlossenheit – damit gemeint ist der berühmte Blick über den Tellerrand, technologisch wie menschlich. Zudem bedarf es einer positiven Fehlerkultur, die Raum für Experimente lässt, und einer mentalen Bereitschaft für Veränderung.
Darüber hinaus ist es in jedem Fall hilfreich, wenn ein Unternehmen bereits Erfahrung mit agilen Entwicklungsmethoden hat, bevor es sich mit DevOps beschäftigt. „In einem klassischen Wasserfallmodell wird eine Organisationsform, die häufiges Deployen, kurze Feedback-Loops und eine Gesamtverantwortung für Entwicklung und Betrieb unterstützt, kaum von Vorteil sein“, so Lutz Keller von Consol. Er betont, zunächst sei es wichtig, dass ein Unternehmen den Schritt zu DevOps auch tatsächlich gehen will. Nicht selten stehe das Management der Einführung von DevOps und den damit verbundenen umfangreichen Maßnahmen kritisch gegenüber.
Oftmals seien weitreichende organisatorische Anpassungen notwendig, etwa beim Festlegen gemeinsamer KPI-Vorgaben, bei Planungsprozessen, dem Erwartungsmanagement, dem Personalbedarf oder beim Aufbau der für die Entwicklung nach DevOps-Methoden benötigten Skills. „Und dann sollte die nötige Zeit gewährt werden. DevOps ist eine Organisationsform, in die viele Unternehmen hineinwachsen oder hineingewachsen sind. Ein kontinuierlicher Verbesserungsprozess und eine positive Fehlerkultur sind dabei wichtige Bestandteile.“
Die Einführung von DevOps bedeutet also größere Veränderungen in der Organisation und rüttelt somit an den häufig lieb gewonnenen Strukturen. Das stößt bei den Beteiligten oft auf Unverständnis. In den ersten Stadien der Transformation sind daher Ausdrücke wie „die vom Betrieb“ oder „die von der Entwicklung“ noch an der Tagesordnung und sollten die Projektverantwortlichen und -beteiligten nicht gleich abschrecken. Wie in anderen Bereichen und Projekten in Unternehmen, so sorgt auch die Zusammenlegung von Teams bei der DevOps-Einführung für eine Auflösung vertrauter Hoheitsgebiete – Zuständigkeiten müssen teilweise abgegeben werden und neue Aufgaben kommen hinzu. Für so manchen Betroffenen kann das erst einmal schwierig sein.
Das bestätigt Aian Hundegger von Campana & Schott: „Das größte Hindernis sind traditionelle Strukturen.“ So müsse man es in vielen Unternehmen überhaupt erst einmal schaffen, dass Entwicklung und Betrieb zusammenkommen. Es fehle häufig das Verständnis dafür, dass für gute Ergebnisse Abstimmungen nötig sind. „Entsprechend sind strukturelle Voraussetzungen für die Zusammenarbeit zu schaffen, etwa Zeitfenster und Räumlichkeiten.“ Unternehmen sollten hier nicht zu viel vorgeben, da sich die Prozesse erst einspielen müssen. Dies dauert nach Hundeggers Erfahrung oft länger als ein Jahr. Der Reifegrad für DevOps entwickele sich erst durch viele kleine Schritte weiter.
Für Unternehmen jeder Größe ist es wichtig, sobald sie sich für eine DevOps-Kultur entschieden haben, konsequent und mutig am Ball zu bleiben. Dabei muss nicht gleich am ersten Tag ein großer Umschwung passieren – „viel eher sollte in kleinen Iterationen vorgegangen werden“, rät Lutz Keller. Für erste Gehversuche lohnt es sich oft, ein Pilotprojekt in einem Team zu starten.
Kleinere Unternehmen mit überschaubarer IT-Abteilung holen sich dafür am besten Hilfe von außen, denn es gibt viel zu beachten: Eine methodische Vorgehensweise stellt sicher, dass alle notwendigen Schritte umgesetzt und alle Beteiligten auch emotional mit ins Boot geholt werden. Die Liste der Aufgaben umfasst Bereiche wie Analyse, Definition von Meilensteinen und eines Ziels, Bestimmung eines Kernteams, Entscheidung für einen Technologie-Stack, Definition der Testverfahren, Festlegen geeigneter Tools und Methoden für ein wirklich agiles Projektmanagement und Software-Engineering sowie den notwendigen Know-how-Transfer.
Manager und Expertise Lead Aian Hundegger von Campana & Schott fügt hinzu, dass Unternehmen bei der Einführung des DevOps-Ansatzes zudem weitgehend automatisierte Technologien für die Produktintegration benötigen, die den laufenden Betrieb nicht beeinträchtigen. Dies erfordere Funktionen für Risikomanagement, schnelles Zurücksetzen zum vorherigen Systemstand sowie integrierte Tests und schnelle Fehlerbehebung. Zur Verbesserung der Qualität seien dann regelmäßige Messungen der Funktionalität, Performance und Fehlerquote nötig.
Ein häufiges Problem besteht in der Praxis darin, dass der Operations-Bereich keine agilen Methoden einsetzt, sondern transaktional arbeitet, meist mit einem Ticket-System. Das bremst die Software-Entwicklung aus, wenn es darum geht, neue Applikationen auszurollen, ob für Test- oder Produktivzwecke. „DevOps soll die Zusammenarbeit zwischen Entwicklung und Betrieb verbessern, sodass der Operations-Teil viel mehr eingebunden ist und nicht nur Tickets am anderen Ende der Leitung bearbeitet“, erläutert Roman Borovits, Senior Systems Engineer DACH bei dem Cloud-Sicherheits-Unternehmen F5.
DevOps-Skills
Wie beschrieben, erfordert der DevOps-Ansatz eine Kultur mit geteilter Verantwortung. Das, so Aian Hundegger, bedeutet, „dass die Zuständigkeiten zwischen Entwicklung, Betrieb und Sicherheit nie strikt voneinander getrennt sind“. Jeder sei für den Bereich und das Gesamtprojekt verantwortlich.
Entwickler und Engineers sind zwar weiterhin Spezialisten auf ihrem Gebiet, jedoch müssen sie zunehmend über ein Verständnis der Zusammenhänge in anderen Bereichen verfügen. Immer wichtiger werden dabei auch Soft Skills, um Informationen zu teilen und Prozesse abzustimmen. Denn DevOps erfordert einen intensiven Austausch mit anderen Teammitgliedern und Abteilungen. Und das erweist sich manchmal als nicht leicht: So müssen Entwickler zum Beispiel gemachte Fehler offenlegen, damit sie nicht noch einmal passieren. Hinzu kommen die Offenheit für neue Prozesse und neue Arten der Zusammenarbeit sowie die Kundenzentriertheit.
Das Ziel sollte in jedem Fall sein, dass beide Bereiche im Unternehmen, also Software-Entwickler und Systemadministratoren, ein ähnliches Skill-Level erreichen. Natürlich kann nicht jeder ein Experte auf allen Gebieten werden und es ist auch unvermeidlich, dass ein Teammitglied sich mit einem Thema deutlich besser auskennt als andere. „Es sollte jedoch vermieden werden, dass Wissen so gebündelt wird, dass nur einzelne Individuen bestimmte Probleme lösen können“, betont Vassil Hristov von Zest Labs.
In der Praxis bedeutet das, dass sich einerseits der Java-Entwickler damit auseinandersetzen muss, wie man seine Applikation nicht nur lokal auf dem Laptop zum Laufen bringt und wie man erkennen kann, ob sie korrekt funktioniert, wenn sie auf einem Server läuft. Auf der anderen Seite sollte ein Systemadministrator in der Lage sein, bei Problemen in den Code einer Applikation schauen zu können und zu verstehen, was gemacht werden muss, um das Problem zu beheben. Kurzum: Es müssen unterschiedliche Technologien an Menschen mit unterschiedlichen Profilen herangebracht werden.
Die wichtigsten Vorteile von DevOps
Geschwindigkeit: Prozesse lassen sich beschleunigen, sodass Kunden schneller innovative Ergebnisse geliefert werden können. Damit passt man sich besser veränderten Marktbedingungen an und erreicht Geschäftsergebnisse effizienter. Mit dem DevOps-Modell befähigt man seine Entwickler- und Operations-Teams, die Unternehmensziele zu verwirklichen. So ermöglichen etwa Microservices und Continuous Delivery den Teams, durch die Übernahme der vollständigen Verantwortung für Services und deren Steuerung Updates schneller zu veröffentlichen.
Rasche Bereitstellung: DevOps erhöht die Häufigkeit und Geschwindigkeit von Versionen, sodass man seine Innovations- und Produkt-Updatezyklen beschleunigen kann. Mit dem schnelleren Hinzufügen neuer Funktionen und dem Beheben von Bugs lässt sich rascher auf die Anforderungen von Kunden reagieren.
Zuverlässigkeit: DevOps stellt die Qualität von Anwendungs-Updates und Änderungen an der Infrastruktur sicher. So lassen sich die beschleunigten Prozesse aufrechterhalten, ohne die positive Kundenerfahrung der Endnutzer zu beeinträchtigen. Durch die Verwendung von Methoden wie Continuous Integration und Continuous Delivery überprüft man die Funktionalität und Sicherheit jeder Änderung. Methoden zur Überwachung und Protokollierung liefern Informationen zur Systemleistung in Echtzeit.
Umfang: Mit dem DevOps-Ansatz lassen sich Infrastruktur und Bereitstellungsprozesse jeder Größenordnung betreiben und verwalten.
Verbesserte Zusammenarbeit: Mithilfe einer DevOps-Kultur entwickelt man effektivere Teams, die durch Werte wie Ownership und Verantwortlichkeit getragen werden. Die Entwicklungs- und Operations-Teams arbeiten eng zusammen, teilen Verantwortung und nutzen kombinierte Workflows. So werden Ineffizienzen beseitigt und es wird Zeit gespart, zum Beispiel durch weniger Übergaben zwischen den Teams oder das Programmieren von Code, der die Umgebung, in der er ausgeführt wird, bereits berücksichtigt.
Sicherheit: Wenn man agil bleibt, behält man die Kontrolle und erfüllt Compliance-Bestimmungen. Der Umstieg auf ein DevOps-Modell bedeutet nicht, dass man Abstriche bei der Sicherheit machen muss. Dank Automatisierung der Compliance, granularer Steuerungsroutinen und Konfigurationsverwaltungs-Tools bleibt der Betrieb weiterhin sicher und bestimmungskonform.
Quelle: Amazon Web Services
Fazit & Ausblick
Die Automatisierung bei der Software-Bereitstellung schreitet immer schneller voran. Dadurch werden DevOps-Ansätze immer einfacher umsetzbar. Derzeit sind zwar noch Experten nötig, aber in ein paar Jahren wird DevOps zum normalen Handwerkszeug für Entwickler gehören, ist sich Aian Hundegger von Campana & Schott sicher. Dadurch würden die Grenzen zwischen den Bereichen zunehmend verschwimmen und die teamübergreifende Zusammenarbeit werde intensiviert. „Die Folge: Es gibt weniger Klein- und mehr Großprojekte, da alle auf dieselben Ziele hinarbeiten. Die Produktentwicklung erfolgt dabei aber verstärkt in kleinen Schritten anstelle eines großen Release.“
Mit dem Thema DevOps muss man sich als Unternehmen intensiv auseinandersetzen und die Einführung einer solchen Kultur ist nichts, was sich von heute auf morgen erledigen lässt. „DevOps ist ja schnell mal auf die Visitenkarte geschrieben – aber deswegen ist es noch lange nicht gelebte Kultur“, resümiert Roman Borovits von F5. Wichtig sei, zu verstehen, dass der Erfolg zu einem Großteil an den zwischenmenschlichen Faktoren hängt und nicht an der Implementierung oder Änderung eines Tools. „Jede Veränderung im Unternehmen kann positive und negative Effekte erzeugen. Es ist in jedem Fall anzuraten, einen angestrebten Kulturwandel professionell zu begleiten.“
Nach Ansicht von Nisha Lehmann von der Agentur Merkle wird sich das Thema DevOps in den nächsten zehn Jahren vor allem in großen Unternehmen weiter durchsetzen und zum unangefochtenen Standard der Projektbereitstellung werden. Außerdem werde der Ansatz zunehmend auch benachbarte Technologieaspekte integrieren. Dazu zählten zum Beispiel Cybersicherheit, Künstliche Intelligenz und die Cloud.
*Konstantin Pfliegl ist Redakteur bei der Zeitschrift com! professional und schreibt auch für die Internet World Business, Telecom Handel und die Schweizer Computerworld. Er hat rund 20 Jahre Erfahrung als Redakteur für verschiedene Print- und Online-Medien. Er arbeitete als Redakteur unter anderem für die Fachpublikationen tecChannel und Internet Professionell sowie freiberuflich unter anderem für FOCUS Online.
Be the first to comment