Warum DevOps?

DevOps

Alle sprechen von DevOps, aber jeder versteht etwas anderes darunter. Dieser schillernde Begriff ist ein Kunstwort und steht für eine neue Kultur und Herangehensweise in der Zusammenarbeit von bisher getrennt arbeitenden Abteilungen. Genauer gesagt, besteht der Begriff aber aus zwei verschiedenen Abkürzungen: Dev und Ops. Also Development- Softwareentwicklung und Operations- IT-Betrieb beziehungsweise Systemadministration. Zusammengesetzt ergibt sich daraus das heutzutage schon fast inflationär verwendete Wort „DevOps“. Dass DevOps aber mittlerweile im Mainstream angekommen ist, ist der Konsens. Und genau deshalb ist es umso wichtiger, das Wort genau zu definieren und in den Kontext einzuordnen.

Diese neue Kultur soll bisher unterschiedlich agierende Abteilungen zusammenbringen, um so die Softwarequalität und Verfügbarkeit zu erhöhen und damit die Kundenzufriedenheit zu steigern. Abteilungen, die bis dato historisch unterschiedliche Ziele verfolgten, sollen also nun an einem Strang ziehen. Wo bisher die Softwareentwicklung als agil, kreativ und am Puls der technologischen Entwicklungen stehen sollte und im Gegensatz dazu der IT-Betrieb auf Stabilität, Sicherheit und vor allem Verlässlichkeit ausgerichtet war, steht nun DevOps. Es soll diesen Widerspruch der Abteilungen vereinen. Der Fokus dabei liegt auf der Einbeziehung der gesamten Wertschöpfungskette und dem Aufbrechen des bisherigen Silo-Denkens.

DevOps Kultur

DevOps lebt von den Menschen, die an dieser Kultur beteiligt sind. Es besteht zwar grundsätzlich aus Prozessen, Tools und Kulturkomponenten, aber eine Kultur kann bekanntlich nicht gekauft werden, sondern muss gelebt werden. Dabei besteht DevOps nicht nur aus der interdisziplinären Zusammenarbeit von Development und Operations, sondern auch von der, der allen anderen am Produktlebenszyklus beteiligten Komponenten, wie Product Owner, Security oder Testing. Um zu erreichen, dass diese Herangehensweise im Unternehmen gelebt wird, braucht es mehr als nur das Einstellen eines DevOps Engineers oder der Etablierung neuer Prozesse- die ganze Organisation muss dazu beitragen. Im besten Fall gibt es Leader, die die Zusammenarbeit der unterschiedlichen Teams fördern und zu einer gemeinsamen Philosophie beitragen. Der Schlüssel zum Erfolg liegt hier im Ausbrechen aus alten Denkmustern, wie „Systemadministator vs. Programmierer“. Nur, wenn diese Aufspaltung aufgeweicht wird, kann eine DevOps Bewegung erfolgreich im Unternehmen gelebt werden. Denn es ist nicht zu vergessen, dass es sich hierbei weniger um eine Methodologie oder ein Management-Framework handelt, sondern vielmehr um eine holistische Herangehensweise beziehungsweise Philosophie.

Einführung von DevOps

Es ist zweifelsohne zu sagen, dass sich DevOps mittlerweile als Industriestandard für die Software-Entwicklung etabliert hat. Die erfolgreich gelebte DevOps Kultur eröffnet Unternehmen neue Möglichkeiten. Sie ermöglicht Firmen, den jeweiligen Markt zu verändern und so ihre Konkurrenz durch höhere Innovationsraten hinter sich zu lassen. Von Vorteil hierbei ist, dass alle Stakeholder nun dadurch ein gemeinsames Ziel verfolgen: Möglichst zuverlässig und schnell hochwertige Software entwickeln und auf den Markt bringen. Eine Hürde, vor der DevOps bei Unternehmen steht, ist die negative Einstellung gegenüber Veränderungen. Dabei sollten Firmen viel mehr die sichtbaren und vor allem messbaren Erfolge nach der Einführung von DevOps im Blick haben. Sie verhindern, dass das Unternehmen über kurz oder lang irrelevant auf dem Markt wird.

Allerdings ist DevOps nicht nur etwas für Softwareunternehmen. Von DevOps profitieren Firmen in allen Branchen. Ob Banken, Handel oder Industrie- mit der Einführung dieser Prinzipien lässt sich insgesamt auch die Zusammenarbeit, das Arbeitsklima und die Mitarbeitermotivation steigern. Noch viel mehr: Sind die Kunden zufrieden, so ist es aucfh das Team, der einzelne Mitarbeitern oder Mitarbeiterin und somit auch das gesamte Unternehmen. DevOps steht also auch für Kollaboration, Flexibilität, Agilität und vor allem für die Konzentration auf den gemeinsamen Geschäftserfolg.

Denken Unternehmen heutzutage nicht frühzeitig über eine DevOps Transformation nach, werden sie über kurz oder lang weder wettbewerbsfähig bleiben noch relevant auf dem Markt. Wollen sich Unternehmen also langfristig einen Wettbewerbsvorteil verschaffen, so ist die DevOps Kultur immer ein sinnvoller Weg.

DevOps in der Praxis

Woran eine erfolgreiche DevOps Transformation erkennbar ist? Die betreffenden Unternehmen zeichnen sich in der Praxis oftmals durch schnelle und häufige Releasezyklen aus, Deployments inklusive bedarfsspezifischer Rollbacks sind automatisiert und Continuous Integration und automatisiertes Testing sind vorhanden. Eine voll funktionsfähige DevOps Kultur hat somit eine durchgehend automatisierte Zusammenarbeit als Ziel, ohne der Notwendigkeit des manuellen Eingreifens. Ein zentraler Bestandteil der Strategie ist dabei, das Einräumen von Entscheidungen, die autonom von jeder Abteilung getroffen werden können. So sollte beispielsweise ein Entwickler bei der Bereitstellung einer optimalen Testumgebung nicht erst auf das „Okay“ der IT-Administration warten müssen, sondern soll dies selbstständig entscheiden.

Vorher ist aber nicht selten die veraltete Verhaltensweise und Zusammenarbeit der Teams zu ändern. Denn dies stellt die größte Hürde dar. Es ist nicht zu unterschätzen, wie viele Prozesse dabei involviert sein können und wie sehr sich das jeweilige Unternehmen daher zu verändern hat. Zeit und Überzeugungsarbeit sind hier oftmals die entscheidenden Faktoren. Stellen Sie sich einmal vor, dass sich ein Unternehmen von nur wenigen Software-Releases, wie bisher, durch den Einsatz von Continuous Delivery zu täglichen oder sogar stündlichen Releases entwickeln kann. Wie das geht? Continuous Integration beziehungsweise Continuous Delivery bewirkt, dass die Softwarebereitstellungszyklen immer kürzer werden, da die Produktpipelines immer mehr durch Microservices und Cloud-Native-Umgebungen skaliert werden können. Dabei werden Fehler im Voraus bemerkt und die Produktion verzögert sich dadurch nicht unnötig. Sie sehen- vor allem die Fehlerbehebung spielt im Entwicklungszyklus eine große Rolle. Je früher ein Fehler in der Kette identifiziert werden kann, desto günstiger die Fehlerbehebung. Und all das durch die Einführung von DevOps.

Komponenten

Eine optimale Unternehmenskultur unter DevOps verfolgt einen ganzheitlichen Ansatz. Demnach sind die Komponenten Teams, Tools, Methoden sowie Transparenz und Stabilität Faktoren von DevOps. Ihr Zusammenspiel erwirkt eine bessere Zusammenarbeit der Abteilungen und somit eine erhöhte Qualität des Endprodukts.

Teams

Oftmals kann man von Kopfmonopolen in Firmen sprechen. Das bedeutet, das Wissen der Teams ist in einzelnen Bereichen gebündelt. Der Anspruch von DevOps besteht darin, diese Monopole aufzulösen und erst gar nicht entstehen zu lassen. Alle Projekt-Beteiligten sollen sich gegenseitig unterstützen und ihr Wissen teilen.

Eine große Chance von DevOps ist, dass neben den Hauptakteuren der Softwareentwicklung und Operations auch Wissen aus anderen Fachbereichen gezielt unterstützend eingesetzt wird. Der konkrete Vorteil liegt hier in der Nähe der Teams. Integrierte Teams in Projekten ermöglichen einen direkten Informationsaustausch und vermeiden eine umständliche Erfragung der Expertise. Kurz gesagt: Schnelle Kommunikationswege, keine externen Freigaben und ein konstanter Wissensaustausch ermöglichen eine hohe Liefertreue, eine passgenaue Erfüllung von Erwartungen des Unternehmens, eine schnellere Time-to-Market und schlussendlich auch einen besseren Support des Endprodukts.

Tools

Die Funktion von Tools liegt in der Erleichterung von Standardaufgaben. Jede Phase des Software-Lebenszyklus strebt einen Einsatz von Tools an. Dazu müssen im ersten Schritt solche wiederkehrenden Aufgaben identifiziert werden und diese dann im zweiten Schritt Maschinen überlassen werden. Diese sollen dann im Sinne von DevOps in einer ständigen Interaktion zueinanderstehen und nicht losgelöst voneinander agieren. Damit wird eine sogenannte Toolchain, also Werkzeugkette, gebildet. Ziel ist eine möglichst große Anzahl von automatisierten Prozessen zu schaffen.

Dabei ist DevOps selbst kein Werkzeug und somit dieser Kette nicht zuzurechnen, allerdings bilden die Tools die Grundlage zur Automatisierung und Implementierung der Produkte. Der Einsatz von DevOps Tools variiert von Kunde zu Kunde, da die Infrastruktur des Kunden die Grundvoraussetzungen liefern muss, um den Ansatz durchführen zu können. Jedes Unternehmen sollte sich die Frage stellen, wie der persönliche Software-Mix aussehen sollte, denn vom Einsatz der Toolchain profitiert die gesamte Entwicklung bis zum produktiven Einsatz des Produkts.

Methoden

DevOps setzt methodisch auf der technologischen wie auch auf prozessualer Ebene an. Damit stellt diese Unternehmenskultur klassische ITIL-Prozesse auf die Probe. Gemeint ist die strukturierte Prozessansammlung von Best Practices für Service Management in der IT, also die IT Infrastructure Library. Diese beiden Methoden stehen auf den ersten Blick im Widerspruch zueinander. Denn wo das DevOps-Konzept aus den standardisierten Verfahren ausbrechen will, zählt ITIL heutzutage zum Tagesgeschäft vieler IT-Unternehmen. Das stellt Firmen mit festgeschriebenen Prozessframeworks vor eine Herausforderung. Die technologische Ebene von DevOps kann in Continuous Integration, Continuous Delivery, Continuous Deployment und die Integration in vorhandene Prozesse gegliedert werden.

Dabei ist Continuous Integration eine Methode, die kontinuierlich Komponenten zu einer Anwendung zusammenfügt. Dadurch soll die Softwarequalität gesteigert werden. DevOps zielt damit auf ein automatisiertes Bauen von Software-Artefakten aus Quell-Code ab.

Continuous Delivery ist dann der nächste Schritt, der auf der fortwährenden Integration aufbaut. Die automatisierten Artefakte sollen nun deployed werden, also automatisch getestet und im Anschluss in der Produktivumgebung installiert werden.

Das Continuous Deployment spielt nun Builds automatisiert auf diese Umgebung ein. Damit ist Continuous Deployment die letzte Stufe und nur für bestimmte Softwareentwicklungen sinnvoll einsetzbar.

Nun wird dies in vorhandene Prozesse integriert. Es bietet sich an, dafür auf Prozessebene zu beginnen. Also beispielsweise beim Change-Management. Es sollte so transparent umgestaltet werden, dass DevOps-Teams Funktionalitäten häufiger in Produktivumgebungen nachvollziehbar livesetzen können. Dadurch wird gewährleistet, dass die Infrastruktur in ihrer Gesamtheit nachvollziehbar bleibt und jederzeit zur Verfügung steht. Somit kann bei einem Ausfall schnell und gezielt reagiert werden.

Transparenz und Stabilität

Um eine skalierbare IT-Infrastruktur zu gewährleisten und Projektfortschritte transparent zu machen, sind effiziente Messungen unerlässlich. Dabei setzt DevOps sowohl auf klassische Projektmanagement-Reportings als auch auf Messungsansätze in der Infrastruktur. DevOps kann sich der gewählten Methode des Projektmanagement-Reportings anpassen.

Wird also ein Projekt unter Verwendung einer agilen Methode durchgeführt, so ist die Messung der Qualität ein wichtiges und aussagekräftiges Kriterium. Nimmt man als Beispiel Scrum, wird die Velocity als Maßeinheit für die Schnelligkeit von Teams definiert. Sprints beschreiben dabei die temporäre, sich wiederholende Phase im Projektprozess, in der das Team ein funktionsfähiges Zwischenprodukt entwickelt und vorstellt. Die Messfrage ist also, wie viel Funktionalität ein Team in einem Sprint liefern kann. Dementsprechend werden maßgebende Entscheidungen getroffen.

Auch Feedbackschleifen sind im Prozess von Bedeutung. Veränderungen können so basierend auf dem Anwenderfeedback in die jeweiligen Teil-Etappen eingearbeitet werden.

Neben Messungen der Projektqualität sind auch technische Messungen der Infrastruktur unabdingbar. Sie sind in Entwicklungsmessungen durch automatisierte Tests und Betriebsmessungen zu unterteilen.

Während erstere Fehler in der Oberfläche zum Beispiel durch Last-Performance-Tests misst, laufen Messungen im Betrieb über Monitoring der Verfügbarkeit von Applikationen, der Infrastruktur und dem Monitoring von Business Services. Testgegenstand ist die Verfügbarkeit von Funktionalitäten der Software ohne Einschränkung.

Wasserfall Agile Methoden

Klassische Wasserfall-Projekte richten die Produktqualität nach der Liefertreue der Teams in Bezug auf die vordefinierten Meilensteine und das Budget. DevOps geht allerdings häufig einher mit den Begriffen Agilität oder Scrum. Dabei beschränken sich diese Methoden oft auf die reine Softwareentwicklung. Durch DevOps wird die agile Methode weitergedacht und zusätzlich auf die Ebene des Betriebs der Software gebracht. Die Unternehmenskultur fokussiert also das Spannungsfeld Agilität versus Stabilität. Die Balance dieser beider Parameter in der Build- und Run-Phase ist dabei das Ziel. Man kann also behaupten, dass DevOps die Weiterentwicklung des agilen Gedankens eines Unternehmens ist. Das bedeutet auch, dass der gesamte Unternehmens-Stack aufgegriffen wird- von Governance über Prozesse und Anwendungen bis hin zur Infrastruktur. DevOps ist grundsätzlich nicht auf die agile Methode angewiesen, bietet dem Unternehmen aber den Vorteil, dass die Liefertreue und -geschwindigkeit erhöht werden kann.

Ziele

Zusammenfassend ist festzustellen, dass DevOps die primären Ziele verfolgt, die Entwicklung von Software effizienter und die Auslieferung schneller sowie den Betrieb stabiler zu machen. Damit inbegriffen sind eine erhöhte Produktqualität und auch eine verbesserte Liefertreue bei IT-Projekten. Die DevOps Kultur kann also die Geschwindigkeit, Qualität und Agilität der technologischen Produktion verbessern.

Probleme, denen DevOps dabei gegenübersteht, sind die immer kürzer werdenden Bereitstellungs-Zyklen neuer digitaler Technologien. Junge und innovative Nutzer beeinflussen den Markt dabei maßgeblich. Durch das Einbringen eigener Inhalte wird in der Gesellschaft eine kollektive Intelligenz erzeugt, die die Bedingungen in den letzten Jahren in der IT-Branche verschärft hat.

Doch dies ist keineswegs ein neues Phänomen. Bereits seit Mitte der 90er Jahre wächst die Notwendigkeit, in der Produktion befindliche Software umgehend immer neuen Anforderungen anzupassen. Dadurch wird auch die Annahme bekräftigt, dass Softwareentwicklung und -einsatz schon bald nicht mehr auseinanderzuhalten ist.

Somit ist der Test solcher Anwendungen auch weiterhin essenziell und sollte nicht als beendet erklärt werden.