Automatisierte Nachschubwege für Code und Infrastruktur Von DevOps zu GitOps für mehr Agilität

Klassische DevOps-Workflows kommen bei der Bereitstellung containerisierter Anwendungen immer wieder ins Stottern. Denn die Automatisierung kontinuierlicher Integration verträgt sich nicht mit manueller Konfiguration. Doch nach dem Spiel ist vor dem Spiel. Mit GitOps soll jetzt endlich echte Agilität einkehren.

Neuartige Szenarien der Bereitstellung Cloud-nativer Anwendungen erzwingen eine neue Denkweise und rufen neue Methodologien auf den Plan. Ein aktuelles Beispiel der Herausforderungen liefert der Ausbau des – programmierbaren – Mobilfunks der fünften Generation in der Telekommunikationsbranche.

Microservices für die 5G-Edge

Als Teil des 5G-Ausbaus stellen Telekommunikationsunternehmen kleine Rechenzentren an Mobilfunkmasten und Points of Presence an der Netzwerkkante auf. Diese Rechenzentren sind im Grunde genommen eigenständige Clouds, in denen potenziell Hunderttausende oder sogar Millionen von Kubernetes-Clustern „schwärmen“.

E-Book zum Thema

Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

eBook herunterladen

Die Tele­kommu­nikations­dienst­leister wollen die Möglich­keit haben, neue Dienste für ihre Kunden bedarfs­gerecht mit vielen Auswahl­möglich­keiten bereit­zustellen. Diese Anbieter imple­mentieren neue Features typischer­weise zuerst in Pilot­projekten mit einer Gruppe hand­verlesener Stammkunden.

So haben zum Beispiel die Deutsche Telekom und Nokia im Rahmen eines zweijährigen Pilotprojektes der Hamburg Port Authority (HPA) praktische Anwendungen von Network-Slicing für 5G getestet. Nach erfolgreichem Abschluss der Testphase fließen die so gewonnenen Erkenntnisse in den allgemeinen Feature-Rollout ein, sei es in ortsgebundenen Angeboten oder als Servicekategorien mit Compliance-Beschränkungen. GitOps schafft hierzu die nötige Agilität.

Der 5G-Rollout der Mobilfunker stellt aber nur die Spitze des Eisberges dar. Auch viele andere Branchen, vom Bankwesen über die Automobilbranche bis hin zu den Medien, suchen nach ähnlichen Möglichkeiten der weiteren Flexibilisierung der Anwendungsentwicklung und -bereitstellung.

Die Liste der möglichen Variationen von individualisierten Serviceangeboten, die manche Unternehmen für verschiedene Segmente ihres jeweiligen Kundenstamms ausrollen möchten, ist zum Teil sehr vielfältig. Auch der Umfang der technischen Infrastrukturen geht oft weit über die früheren Anforderungen hinaus, die ja nur wenige Jahre zuvor bestanden. Dieses explosionsartige Wachstum der geschäftlichen Nachfrage nach Ephemeralität, Individualisierbarkeit, Agilität und Skalierung treibt die außergewöhnlich schnelle Reifung des Kubernetes-Ökosystems – und damit den Marsch zu GitOps – voran.

DevOps war gestern

Das Aufkommen containerisierter Microservices stellt für DevOps-Teams eine grundsätzliche Herausforderung dar: Vorsätze der kontinuierlichen Integration und Bereitstellung Cloud-nativer Anwendungen scheitern an den Stolpersteinen manueller Administration der Staging- und Produktionsumgebung. Die gut geölte DevOps-Engine entpuppt sich in der Praxis als reines Wunschdenken. Das Ops-Team in einem DevOps-Workflow gerät ins Hintertreffen.

Der Bericht „DevOps Trends Survey 2020“ des DevOps-Pioniers Atlassian auf der Basis einer Befragung von rund 500 leitenden Entwicklern in Unternehmen durch das Forschungsinstitut CITE Research scheint dies zu bestätigen. Auf die Frage nach den größten Hindernissen bei der Umsetzung eines DevOps-Workflows verwies rund jeder dritte Teilnehmer auf Konflikte zwischen dem Dev- und dem Ops-Team. Als der größte Bremsklotz auf dem Weg zu kürzeren Release-Zyklen – und damit zu einer höheren Agilität – nannten die Befragten „zu viele manuelle Prozesse“ (31%).

Die Konflikte sitzen tief, denn sie sind quasi programmiert. Aus der Sicht der Ops-Fachkräfte sind Betriebsstörungen neuem Code anzulasten, denn der alte lief ja ohne Wenn und Aber – also müsse die Dev-Abteilung für etwaige Ausfälle geradestehen.

Aus der Sicht der Dev-Abteilung liegen die Fehler wiederum per se an dem Ops-Team, denn der Code lief ja problemlos in der Testumgebung, die die Dev-Sparte selber verantwortet. So oder so bleibt die Frage offen, wie der jeweils letzte lauffähige Zustand der Cloud-nativen verteilten Anwendung zu restaurieren sei. Reines DevOps hat dafür keine Antwort parat und so ist es mit der Agilität auch nicht so weit her.

Doch selbst die komplexeste Cloud-Infrastruktur lässt sich mit einigen Zeilen Code ohne menschliches Zutun orchestrieren (zum Beispiel mit Kubernetes). Diese Tatsache macht sich ein Ansatz namens „Infrastructure as Code“ zunutze, um die automatische Bereitstellung Cloud-nativer Anwendungen zu ermöglichen.

Infrastruktur als Code

Der Begriff „Infrastructure as Code“ (IaC) beschreibt den Prozess der Verwaltung und Bereitstellung von Elementen der Cloud-Infrastruktur deklarativ über maschinenlesbare Definitionsdateien anstelle iterativer Konfigurationsschritte. Mit diesem Ansatz können Entwickler die Anforderungen für die Bereitstellung ihrer Anwendungen in Produktion mit Tools wie Terraform direkt in Code erfassen und ausführen.

E-Book zum Thema

Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

eBook herunterladen

IaC vereinfacht die Serververwaltung, die Ressourcenbereitstellung und sogar die langfristige Wartung komplexer Cloud-Infrastrukturen im Rahmen von CI/CD-Pipelines. Vollständig automatisierte Nachschubwege für die Softwarebereitstellung müssen eine Möglichkeit der Versionierung vorsehen, um zuverlässig zu funktionieren. Dies trifft auf Infrastructure as Code umso mehr zu, denn nur so kann sich die Bereitstellung an die dynamischen Anforderungen der versionierten Anwendung anpassen.

Solange sich die Entwicklungs- und Testumgebungen (Dev) in der Produktion (Ops) nicht mit absoluter Vorhersehbarkeit reproduzieren und versionieren lassen, kann auch von selbstheilenden Anwendungsarchitekturen wohl kaum die Rede sein. So bleibt aber auch die erhoffte Agilität aus.

Sollte die Bereitstellung einer neuen Version der Cloud-nativen Anwendung in der Produktionsumgebung, aus welchen Gründen auch immer, fehlschlagen, ist ein Rollback zum letzten lauffähigen Zustand angesagt, um die Dienstbereitschaft wiederherzustellen.

In verteilten Cloud-nativen Anwendungen gilt es, die letzte lauffähige Version des gesamten verteilten Systems kurzfristig wiederherzustellen (nicht bloß den letzten Zustand einer einzelnen VM wie im Falle von monolithischen Altlasten). Bei containerisierten Microservices ist die manuelle Wiederherstellung eines bestimmten lauffähigen Zustands der Bereitstellung auf Grund der schieren Komplexität schlicht unrealistisch.

GitOps kommt hier wie gerufen. Mit dieser Herangehensweise machen sich Entwickler Infrastructure-as-Code-Tooling zunutze, um Updates des Code und der Cloud-Infrastruktur über Git zu steuern. In GitOps gibt es kein „Ops-Team“ mehr. Nach Angaben der CNCF (Cloud Native Computing Foundation) hätten Entwickler bei der erstmaligen Implementierung der GitOps-Methodologie in ihren Cloud-nativen Umgebungen Verbesserungen der Produktivität, Stabilität, Zuverlässigkeit und Sicherheit beobachtet.

Abgesehen von den technischen Aspekten der Umsetzung einer GitOps-Pipeline hängt der Erfolg dieser Herangehensweise nicht zuletzt auch von den richtigen Management-Prozessen ab. Eine der wichtigsten Errungenschaften von GitOps bestehe in der Fähigkeit, „eine Reihe von Systemänderungen korrekt anzuwenden und dann zu verifizieren“, sagt Alexis Richardson, CEO und Gründer von Weaveworks, der den Begriff „GitOps“ (mit)geprägt haben soll. Weaveworks ist Anbieter der Weave Cloud, einer CI/CD-Plattform, die sich auf GitOps-Prinzipien stützt.

Nach der erstmaligen Bereitstellung einer Anwendung überwacht die GitOps-Plattform die Gesundheit des verteilten Systems und schlägt Alarm beim Auftreten von Abweichungen vom angestrebten Soll-Zustand der aktuellen Git-Deklaration. Dadurch kann die Bereitstellung kontinuierlich zum gewünschten Entwicklungszustand konvergieren. Die kontinuierliche Integration und Bereitstellung containerisierter Anwendungen nach dem GitOps-Paradigma kann dadurch vollständig automatisiert ablaufen.

Fazit

Nach dem Spiel ist vor dem Spiel: Vollständig automatisierte Nachschubwege für Anwendungscode und Infrastrukturdeklarationen verleihen kontinuierlicher Integration und Bereitstellung ihre wahre Bedeutung. Mit GitOps sind jetzt wieder die Entwickler die Sturmspitze am Ball. Denn während das Versionssystem Code- und Konfigurationsänderungen aufzeichnet, wachen intelligente Softwareagenten auf dem Cluster über die Gesundheit der Bereitstellung und so können sich die Entwickler ungestört ihren Aufgaben widmen. Die resultierenden Deployments sind selbstheilend und wiederherstellungsfähig.

Dieser Beitrag ist ein Auszug aus unserem eBook „Ein kleiner GitOps-Guide“. Darin erfahren Sie auch mehr über passende Tools und das Troubleshooting von GitOps-Pipelines.

E-Book zum Thema

Ein kleiner GitOps-Guide

GitOps soll die Cloud-native Entwicklung containerisierter Anwendungen von Grund auf umkrempeln. Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

Im eBook erfahren Sie mehr über:

• GitOps-Prinzipien, Vorteile und Alternativen
• Tooling für GitOps
• Troubleshooting von GitOps-Pipelines

eBook „Ein kleiner GitOps-Guide“ herunterladen

(ID:47847764)