In einem Blogbeitrag vom Mai 2023 habe ich das GitOps-Pattern vorgestellt, welches DevOps-Ansätze mit den Möglichkeiten von Infrastructure-as-Code kombiniert. Dieser Beitrag reflektiert die Erfahrungen nach zwei Jahren praktischer Anwendung dieses Patterns.
Das GitOps-Pattern wurde mit dem Tool ArgoCD auf einer Containerplattform basierend auf Red Hat OpenShift bei einer grösseren Schweizer Krankenversicherung implementiert. ArgoCD ist dabei die zentrale Continous Deployment Komponente, welche fortlaufend die deklarativen Konfigurationen aus einem Git-Repository in die Containerplattform überführt.
Der Installations- und Betriebsaufwand von ArgoCD auf OpenShift ist äusserst klein, da das Tool als „OpenShift GitOps“ von Red Hat vollintegriert und getestet zur Verfügung gestellt wird, und nur noch konfiguriert werden muss. Den grössten Teil stellt dabei die Security-Konfiguration dar: Da sich auf der vorhandenen Containerplattform verschiedene Teams einen OpenShift-Cluster und somit die Argo CD-Instanz teilen, kann eine fehlerhafte oder undurchdachte Konfigurationen schnell in Privilege Escalations resultieren. Eine wohlüberlegte und gewissenhafte Konfiguration ist folglich unerlässlich, aber auch entsprechend aufwändig.
In vielen Fällen zu komplex
Bei der Adaption des Tools durch verschiedene Teams haben sich wiederholt dieselben Schwierigkeiten gezeigt: Die hohe Komplexität, welche die Konfiguration der Deployments unter Verwendung von ArgoCD mit sich bringt, stellt für viele Teams eine zu grosse Einstiegshürde dar. Das Einrichten und die Integration der häufig bereits seperat bestehenden Deploymentlogik (etwa in Form von Helm-Charts oder Operators) erfordert nebst ArgoCD-spezifischem Know-how auch ein klares Verständnis der zugrunde liegenden Prinzipien und Abstraktionen. Dieses Know-how ist aber häufig schwach ausgeprägt, da die Schwerpunkte der verantwortlichen Teams in der Regel anders gelagert sind – etwa der Entwicklung oder dem Applikationsmanagement.
Wird die zusätzliche Komplexität von ArgoCD mit dem zusätzlichen Nutzen gegenüber semi-manuellen Deployments aufgewogen, führt das häufig zu einer ablehnenden Haltung. Gerade in den Fällen, wo Deployments welche selten durchgeführt werden und daher die Vorteile von ArgoCD weniger zum Tragen kommen wird das Kosten-Nutzen-Verhältnis als negativ vergenommen.
Häufige Anpassungen an der Deployment-Logik welche mitunter Anpassungen in der Argo CD-Konfiguration nach sich ziehen können erhöhen die Komplexität ebenfalls weiter. In ungünstigen Fällen führt das zu einer Summierung der Komplexität, statt einer Reduktion derer. In solchen Fällen wird zwar regelmässig auf ArgoCD verzichtet, nicht aber auf das komplette GitOps-Pattern an sich. Auch ohne Continuous Deployment mit ArgoCD werden die einzelnen Artefakte im Sinn von Infrastructure as Code in GIT abgelegt, wodurch zumindest einige der Grundsätze beibehalten werden.
In anderen Fällen eine Vereinfachung
ArgoCD hat aber auch seine Nischen gefunden, in welchen sich ein durchaus positives Bild zeigt: Häufige Deployments mit derselben Deployment-Logik werden durch das automatische, standardisierte Deployment-Verfahren massiv vereinfacht. Die Möglichkeit, in solchen Fällen Continuous Deployment durch eine vorhandene Plattform-Komponente vergleichsweise unkompliziert ausführen zu können stellt gegenüber einer selbstgebauten Lösung (etwa in Form einer Pipeline) eine massive Zeit- und Komplextitäsersparnis dar.
Ein wahrer Segen ist ArgoCD aber in Fällen, wo beinahe identische Deployments in hoher Anzahl erfolgen müssen. Als Beispiele seien hier Monitoring-Komponenten, RBAC- oder Quota-Objekte erwähnt welche pro Workload deployed werden müssen. In diesen Fällen besteht zwar weiterhin die hohe initiale Komplexität, durch die schiere Quantität rechnet sich diese aber auch entsprechend schnell.
Das richtige Werkzeug für die richtige Aufgabe
Zusammenfassend lässt sich somit sagen, dass ArgoCD sich für gewisse Workloads bewährt hat, während an anderen Stellen die zusätzliche Komplexität gegenüber dem Nutzen zu hoch ist. Diese Erfahrungen lassen sich treffend mit einem Zitat von Alan Kay bezüglich Komplexität zusammenfassen (Power of Simplicity, 2015):
You get simplicity by finding a slightly more sophisticated building block to build your theories out of.
Bei simplen, unregelmässigen Deployments kann ArgoCD somit als slightly more sophisticated building block einen „Overkill“ darstellen – bei komplexen Lösungen hingegen die Workflows vereinfachen.
