Wie die Cloud von morgen sich selbst managt

Cloudbasierte Softwarearchitekturen können sowohl mit modernen Ansätzen und Werkzeugen schneller initial bereitgestellt als auch besser über ihren gesamten Lebenszyklus gemanagt werden. Die Prozessoptimierung ist ein angestrebtes Ziel in der «IT Operation for Digital Age» (IO4DA), doch noch lange nicht abgeschlossen. Innerhalb des IO4DA kommen daher Push- (CIOps) und Pull-Prinzipien (GitOps) zur Anwendung. In beiden Szenarien wird nach Entwicklergrundlagen gearbeitet und der Softwarecode ist versioniert in einer Sourcecode-Verwaltung verfügbar.

Das Push-Prinzip: CIOps

Bei diesem imperativen Ansatz ist der Continous Integration (CI) Server der zentrale Koordinator und orchestriert die Abläufe. Nachdem ein Build-Prozess angestossen wurde, wird die aus einem oder mehreren Artefakten bestehende Applikation gebildet, integriert, getestet und in einer Registry oder Artifact Repository abgelegt. Das Deployment wird anschliessend durch den CI-Server vorgenommen. Die dafür notwendigen Konfigurationen sind entweder auf dem CI-Server vorhanden oder im Git verfügbar. Die aktuellen Deployment-Informationen und Beschreibungen liefert in diesem Prinzip der CI-Server mit.

GitOps als Pull-Prinzip

Bei diesem deklarativen Ansatz erkennt die Betriebsumgebung über den «Reconciliation Loop», wenn relevante Veränderungen in der Sourcecode-Verwaltung gemacht wurden, sei dies an der Konfiguration, die nun zwingend versionisiert im Git vorhanden sein muss, oder im Sourcecode, der für Updates von Artefakten genutzt wird. Der CI-Server führt weiterhin den Build-Prozess und das Testing durch. Durch den Einsatz von Pull-Prinzipien werden Auditierbarkeit und Reproduzierbarkeit optimiert, denn der CI-Server führt keine imperativen Zwischenschritte durch, weil der Reconcilation Loop zwischen Quelle (Sourcecode/Konfiguration) und Ziel (laufende Betriebsumgebung) stetig synchronisiert wird. Dieser Ansatz führt zu mehr Sicherheit, weil etwa schreibende Zugriffe von aussen auf einen Kubernetes-Cluster verringert werden. Zudem werden Zugriffe auf ein Git Repository organisatorisch einfacher geregelt als Zugriffe auf produktive Betriebsumgebungen wie es unter anderem bei APIs von Hypervisors oder Firewall der Fall ist. Ein manueller Eingriff in das Produktionssystem ist somit nicht mehr notwendig.

Fazit

Wurde bisher eine Änderung in der Produktionsumgebung, zum Beispiel das Ausrollen einer neuen Software, in der Regel durch einen Operator angestossen (Push-Prinzip), so erkennt bei Git­Ops ein Agent in der Produktionsumgebung automatisch, dass Änderungen im Git gemacht wurden und holt sich eigenständig alle für den vollautomatischen Rollout erforderlichen Informationen. Beide Modelle eignen sich sehr gut, um cloud-native Awendungsentwicklungen effizient zu betreiben. Unternehmen, die bereits eine grössere Anzahl von Deployment-Prozessen im Push-Prinzip implementiert haben, sollten eine Umstellung auf ein Pull-Prinzip nur dann durchführen, wenn grosse Mehrwerte damit verbunden sind. Einsteiger sollten sich zunächst mit dem Pull-Prinzip intensiv auseinandersetzen.

Unternehmen sollten einen verlässlichen Partner an ihrer Seite haben, der sie dabei unterstützt, ihre Digitaliserungsstrategie entlang der GitOps-Prinzipien für die IT Operation for Digital Age erfolgreich bereitzustellen.

----------

Von CIOps zu GitOps ist wie der Wechsel vom Piloten zum Autopiloten 

Die Komplexität des Cloud-Managements für IO4DA nimmt immer mehr zu. Das erfordert den Übergang von manueller Intervention hin zu automatisierten Frameworks nach dem GitOps-Prinzip. Interview: Marc Landis

Wann ist der Einsatz von CIOps beziehungsweise wann derjenige von GitOps angezeigt?

Steven Henzen: Wenn man die beiden Modelle CIOps und GitOps als Maturitätslevel betrachtet, dann ist in der «IT Operation 4 Digital Age (IO4DA)» das CIOps-Prinzip das Einsteigermodell und das GitOps-Prinzip als integriertes und überwachtes System die Königsdisziplin.

Inwiefern kann man beim Übergang von CIOps (Push) zu GitOps (Pull) von einem Paradigmenwechsel sprechen?

Der Paradigmenwechsel besteht darin, dass man von manueller Intervention in einem Zielsystem hin in eine automatisierte, Framework gesteuerte Intervention wechselt, man könnte auch sagen vom Piloten hin zum Autopiloten.

Welches sind wichtige Vor- und Nachteile der ­beiden Ansätze?

In beiden Prinzipien ist es ein grosser Vorteil, dass nach Grundsätzen der Developer mit einem «Cloud native Mindset» gearbeitet und dabei der Sourcecode in einem Repository gespeichert wird, wodurch er der Developer-Community im Unternehmen zur Verfügung steht. Als Nachteil kann man fast dasselbe nennen, denn overall ist es die veränderte Arbeitsweise, die zum Tragen kommt, und damit der verbundene Mindset-Change, der in den Unternehmen gemacht werden muss.

Welche Stolpersteine kann es bei GitOps geben?

Meine persönliche Einschätzung ist, dass die Stolpersteine nicht direkt in der Anwendung des GitOps-Prinzips liegen, sondern in der Öffnung des Sourcecodes innerhalb des Unternehmens, sprich: der Wechsel zum Innersource-Softwaremodell, das die Grundgedanken von Open Source mit sich zieht. Auch das konsequente Umsetzen des GitOps-Prinzips, bei dem der Reconciliation Loop mit Observer zur Anwendung kommt, kann ein potenzieller Stolperstein sein, da ein kompromissloses Umsetzen dazu führt, dass keine manuellen Interventionen im Systems durchgeführt werden.

Warum eignen sich GitOps besonders für IO4DA?

IO4DA verfolgt das Ziel, in «no time instant delivery» der Leistungen für Endkundenanforderungen bereitzustellen. In einem GitOps-Prinzip sind alle Build-, Integrations- und Deploymentprozesse durchgängig automatisiert und diese reagieren auf Updates im Repository, die durch den Entwickler anhand der Markt-/Kunden- und Businessanforderungen feingranular auf Feature-Ebene durchgeführt werden. So werden Unternehmen befähigt, ihrer Time-to-Market Wert zu geben und gegebenenfalls auch auf Kundenfeedbacks instant zu reagieren.