DevOps

Was ist DevOps?

Unter DevOps verstehen wir das Zusammenführen aller Aspekte der Software-Entwicklung (Dev) und des Software-Betriebs (Ops) zu einem einheitlichen, abgestimmten Bild. Dabei geht es nicht nur um technische, sondern auch und zu einem Großteil um organisatorische und prozessorientierte Themen. So werden Ziele von Dev und Ops zusammen definiert und nicht mehr unabhängig voneinander, um Zielkonflikte wie "maximale Anzahl neuer Features" (Dev) versus "maximale Stabilität" (Ops) zu verhindern. In DevOps werden üblicherweise Entwicklungs- und Betriebsteams zusammengeführt und arbeiten über den gesamten Projektzyklus zusammen, so dass Übergaben und lange Feedbackschleifen vermieden werden. Darüber hinaus versuchen DevOps-Teams möglichst alle Betriebs- und Auslieferungsprozesse zu automatisieren und versionierbar als Code zu speichern (Infrastructure-As-Code). Dies ermöglicht es, diese Prozesse reproduzierbar und idempotent zu gestalten sowie volle Transparenz darüber herzustellen, welche Software-Versionen verwendet werden und wer wann welche Änderungen am System vorgenommen hat.

Idealerweise arbeiten große Organisationen in möglichst autonomen Teams und folgen dabei der Software-Architektur, die modular sein sollte und lose Kopplung zwischen einzelnen Modulen ermöglicht. Jedes Modul oder jeder Service (siehe auch Microservices) wird von genau einem Team entwickelt und betrieben.

Ein Blick hinter die Kulissen

Nachdem wir nun viele unterschiedliche und auf den ersten Blick unzusammenhänge Aspekte erwähnt haben, wollen wir das nun konkretisieren und in separaten Abschnitten beleuchten.

Motivation und Geschichte

Agile Softwareentwicklung gehört seit einigen Jahren fest zum Prozess-Repertoir von Firmen aller Größen und Branchen und hat die früher üblichen Wasserfall-Modelle größtenteils abgelöst. Damit einhergehend entstanden jedoch neue Anforderungen an das Management und die Organisation der Software-Auslieferung, da in der agilen Softwareentwicklung neue Softwareversionen im Turnus mehrerer Wochen (wie z.B. im beliebten Scrum-Framework) oder sogar kontinuierlich ausgerollt werden müssen. Der dadurch entstehende Aufwand und das erhöhte Risiko beim wiederholten (manuellen) Ausliefern der Software muss mitigiert werden. Dies markierte den Beginn der DevOps-Bewegung mit dem Ziel, häufige Software-Auslieferungen so risikoarm und unsichtbar zu machen wie möglich.

Teamaufbau und -organisation

In DevOps werden alle Projektmitglieder in der Software-Entwicklung und im -Betrieb zunächst zu einer Organisation zusammengeführt, die sich dann um den gesamten Lebenszyklus der Applikation kümmert. Durch die Übernahme aller Aspekte der Entwicklung, der Wartung, des Betriebs und der Skalierung der Software sind alle Mitglieder der DevOps-Organisation dazu angehalten, von Beginn des Projektes an über den späteren Betrieb nachzudenken und es "nicht einfach anderen zu überlassen". Ebenso besteht als Konsequenz eine größere Identifikation und ein höherer Qualitätsanspruch an die eigene Arbeit. Ziele werden nicht mehr pro Team, sondern für die gesamte, an einer Applikation arbeitende Organisation definiert, um Zielkonflikte auszuschließen und einen stärkeren Zusammenhalt zu erreichen.

Die Reorganisation in DevOps-Teams bedeutet in vielen Unternehmen den schwierigsten und schmerzhaftesten Schritt bei der Transition nach DevOps, da altgehegte Disziplinarstrukturen und Prozesse aufgebrochen werden müssen, während weiterhin die in Betrieb befindliche Software funktionsfähig bleiben und weiterentickelt werden muss. Es ist daher unabdingbar, dass sowohl die Mitarbeiter als auch das Management sich vollständig in die Strukturen einfügen und diese akzeptieren. Ist man ehrlich, hat eine solche Entwicklung in jeder Organisation nicht nur Gewinner. Jedoch ist die Transition letztlich unabdingbar, um echte Agilität in der Software-Entwicklung und dem -Betrieb zu errreichen.

Automatisierung

Die Automatisierung möglichst vieler oder aller wiederkehrender Prozesse ist ein wichtiger Schritt zur Erreichung der gewünschten Agilität. Zum Einen soll der wiederkehrende Aufwand bei sich häufig wiederholenden Tätigkeiten minimiert werden. Zum Anderen wird somit das Risiko von Fehlern bei der Durchführung der entsprechenden Prozesse minimiert. Getreu dem Motto "If it hurts, do it more often" ("Wenn es wehtut, tue es häufiger") werden somit komplexe und fehleranfällige Prozesse immer stärker automatisiert, um sie häufiger und auf mehr Applikationen oder Services anzuwenden. Somit wird aus dem Risiko bei der Software-Auslieferung eine gewisse Routine und Fehler können schnell entdeckt und wieder zurückgerollt und beseitigt werden.

Continuous Delivery

Continuous Delivery bezeichnet einen Automatisierungsgrad in der Software-Lieferung, der es erlaubt, jede neue Version der Software ohne größere manuelle Intervention in das produktive System einzuführen. Dabei wird von reproduzierbaren Prozessen Gebrauch gemacht, die in Code (z.B. Skripten) ausgedrückt werden und beliebig oft auf beliebig vielen Zielumgebungen ausgeführt werden können, ohne das Resultat zu beeinträchtigen. Die Konfiguration aller Komponenten und Umgebungen wird zentral verwaltet und auch nur zentral verändert, nicht direkt auf den Zielmaschinen. Dadurch ist jederzeit die volle Kontrolle über den Zustand der Zielsysteme gewährleistet.

Dabei spielt eine große Rolle das automatisierte Testen der Software. Während lange Zeit das automatisierte Testen mittels Unit-Tests im Vordergrund stand, werden hier alle Änderungen an der Software automatisiert auf Integration getestet, d.h. beispielsweise auf Funktionstüchtigkeit und Fehlerfreiheit im Zusammenspiel mit echten oder simulierten Services, von denen die eigene Software abhängig ist.

Infrastruktur-Automatisierung

Nicht nur das Testen und Ausrollen der Software selbst wird in DevOps automatisiert, idealerweise ist es auch die zugrunde liegende Infrastruktur. Dies ist insbesondere in Kombination mit dem Betrieb der Software in der Cloud populär, kann aber auch bei On-Premise Betrieb im eigenen Rechenzentrum erreicht werden, indem entsprechende Methoden und Tools zum Bereitstellen von Servern und Netzwerken (Infrastruktur-Automatisierung) oder höherwertigen Schichten wie Datenbanken und virtuellen Maschinen oder Containern verwendet werden. Die entsprechenden Anweisungen und Konfigurationen werden auch in diesem Fall zentral versioniert und verwaltet und genauso behandelt wie der Applikationscode selbst (Infrastructure-as-Code).

Microservices

Microservices haben sich in den vergangenen Jahren als Architektur-Muster für komplexere Software-Systeme mehr und mehr durchgesetzt, obwohl keine exakte Definition des Begriffs "Microservice" existiert. Im Wesentlichen handelt es sich um autonom betriebene Services, die über festgelegte Schnittstellen miteinander interagieren, aber nicht auf denselben Speicher zugreifen und somit unabhängig sind. Die Vorteile sind eine hohe Flexibilität in Bezug auf Skalierung (jeder Microservice kann separat skaliert werden) und Technologie (jeder Microservices kann in einer anderen Sprache geschrieben sein). Die Nachteile liegen im Bereich der Koordination z.T. sehr vieler einzelner Services und ihrer Versionen sowie dem Overhead für den Betrieb entsprechender Infrastruktur und der Anforderung, dass jegliche Kommunikation zwischen Services potentiell über das Netzwerk und nicht mehr lokal geschieht. Entsprechend wird jeder Service von genau einem DevOps-Team entwickelt und betrieben, so dass Teams sich lediglich über Änderungen an den Schnittstellen abstimmen müssen und ansonsten unabhängig voneinander arbeiten können.

Tools und Technologien

Durch die enorme Verbreitung von DevOps und der angehängten Methodologien gibt es eine Vielzahl an Technologien und Tools, von denen die meisten Open Source sind und die teils eine beachtliche Reife vorweisen können. Obwohl es für jeden Zweck auch Alternativen gibt, haben sich aus unserer Erfahrung in einer Vielzahl von Projekten zunächst die folgenden als besonders stabil und wiederverwendbar herauskristalliert. Je nach Projekt kann es auch besser geeignete Alternativen geben, die wir gerne besprechen.

  • Ansible
  • Docker
  • Kubernetes
  • Hashicorp Vault
  • Amazon AWS
  • Vultr
  • GitHub
  • Jenkins
  • Grafana

Unsere Services

Der Start

Wir arbeiten technologieunabhängig mit Ihnen an den Grundlagen von DevOps und evaluieren gemeinsam die beste Strategie zur Einführung oder Vertiefung Ihrer DevOps-Strukturen. Wir besprechen und implementieren Best-Practices aus der Industrie und vergangenen Projekten und beleuchten die ideale Zielstruktur sowie Ihren Weg dorthin.

Die Transition

Bei der Transition selbst unterstützen wir mit Expertise im Hinblick auf Technologie-Auswahl und die ersten Schritte mit den ggf. neuen Tools, um schnelle Verbesserungen zu ermöglichen. Diese sorgen für zusätzliche Motivation. Im weiteren Verlauf überwachen wir den Aufbau der Strukturen sowie die Umsetzung der Prozess-Automatisierung und helfen, sofern der Bedarf vorhanden ist. Zum Schluss sorgen wir für ideale Wissensvermittlung und -verbreitung durch das Training anhand des "lebenden" Objektes.

Architektur

Ihre Architektur ist zu unflexibel, um echte Modularität zu ermöglichen? Wir unterstützen Sie bei der Transition in Richtung Microservices, übernehmen vom Architekturdesign bis hin zur Implementierung einzelner Services oder Automatisierung alle Arbeiten, bei denen es eng wird.

Sie suchen nach einem starken Partner für die Umsetzung Ihres Projektes?
Lassen Sie uns gerne über Ihr Anliegen sprechen.