Wie sich der Cloud-native-Wandel auf Continuous Delivery auswirkt

Die Definition von Cloud-Native variiert stark, und in Kombination mit einem Continuous-Delivery-(CD-)Paradigma hat sie das moderne Anwendungsentwicklungsmodell revolutioniert.  Organisationen, ob klein oder groß, implementieren die Cloud-Native-Architektur für ihre Entwicklungsumgebung, um den Prozess der Erstellung einer funktionierenden Software effizient zu gestalten. 

Der rasche Übergang zur Cloud-Native-Welt hat dazu geführt, dass Organisationen mit Hochdruck daran arbeiten, Code schnell zu erstellen, zu testen und freizugeben. Continuous Delivery hat sich als Hilfsmittel erwiesen und die häufige Freigabe eines Softwareprodukts beschleunigt. Da aber bekanntlich nichts im Leben einfach ist, brachte die Einführung von Continuous Delivery für Cloud-Native viele damit verbundene Herausforderungen mit sich. In diesem Artikel werden wir die Herausforderungen, die jeweiligen Lösungen und die Überlegungen zur Verfolgung von Continuous Delivery für Cloud-Native erörtern. Aber beginnen wir zunächst mit den Problemen.

Die damit verbundenen Herausforderungen

• Die Komplexität des Release-Prozesses nimmt zu: Vor Cloud-Native war die Unterstützung des Release-Prozesses einer einzelnen monolithischen Anwendung vereinfacht. Im Gegensatz dazu erwies sich der Prozess mit der Aufrüstung auf vollständige Cloud-Native auf Continuous Delivery als komplexer. Der Grund dafür ist, dass die Ingenieure nun die Freigabe von Dutzenden von Microservices-Prozessen handhaben und verwalten mussten, und auch die Abhängigkeit mit dem Hinzufügen von mehr Schichten zum Stack ist eine Überlegung wert.
   
• Die Aufrechterhaltung der Geschwindigkeit ist essenziell: Geschwindigkeit ist der wichtigste Faktor im Zusammenhang mit Continuous Delivery. Zusammen damit ist es auch unerlässlich, die Stabilität des komplexen Systems zu gewährleisten, während man mit einer Cloud-Native-Strategie vorgeht.
   
• Erweiterung der Verantwortlichkeiten der Entwickler: Um mit der Geschwindigkeit der Entwicklung Schritt zu halten, wird Automatisierung eingesetzt. Die Automatisierung löste die Probleme mit der Geschwindigkeit, warf aber schließlich Bedenken bei den Entwicklern auf. Sie erweiterte die Rolle der Entwickler, die zur Automatisierung beitragen. 
  Um die Anwendung näher an den Entwicklern laufen zu lassen, legt die Cloud-Native-Anwendung die Konfiguration in Code ab. Dies erhöht sequenziell die Verantwortung der Entwickler für den Betrieb und die Bereitstellung ihrer Anwendung.

Lösungsansätze

• Kontinuierliches Experimentieren: Um mit der Komplexität Schritt zu halten, ist das Experimentieren in Cloud-Native-Umgebungen unerlässlich. Organisationen können mit Canary Releases, Feature Toggles, Blue-Green-Deployments, A/B-Tests oder Kombinationen der zuvor genannten Prozesse vorgehen, um die Exzellenz der Continuous-Delivery-Pipeline zu testen und zu messen. Dies wird den Continuous-Delivery-Prozess sequenziell rationalisieren und die Funktionen schnell untersuchen, um das Kundenerlebnis zu verbessern. 
   
• Geschwindigkeit durch Automatisierung managen: Die Basis für eine erfolgreiche Orchestrierung ist die Automatisierung. Sie führt letztendlich zu einer hochskalierten, funktionierenden Continuous-Delivery-Pipeline. Daher wird empfohlen, dass die Automatisierung eine wichtige Rolle spielen sollte, um mit der erhöhten Geschwindigkeit umzugehen.
   
• Kurzer Automatisierungszyklus: Die Zunahme der Rollen und Verantwortlichkeiten der Entwickler kann durch das Konzept der IT-Umgebung charakterisiert werden, in der der Prozess so automatisiert und abstrahiert wird, dass keine interne Verwaltung und Messung erforderlich ist, was als "No-Ops"-Ansatz bezeichnet wird. Um reibungslos zu funktionieren, wird die Vermischung der verschmutzten Funktionen in einen kurzen automatisierten Lebenszyklus die Probleme mit den Entwicklern lösen.

Anwendungsfall: Effiziente Continuous-Delivery-Pipeline auf Cloud-Native 

Basierend auf dem Tekton-Projekt können die OpenShift-Pipelines über einen Operator über Red Hat OpenShift 4.1 OperatorHub auf dem Cluster installiert werden. Dies ermöglicht die Erstellung von Delivery-Pipelines im Kubernetes-Stil. OpenShift-Pipelines ermöglichen es Entwicklern, den kompletten Microservices-Lebenszyklus zu besitzen und zu kontrollieren, ohne dass zentrale Teams die Continuous Integration (CI)-Server, Plugins und deren Konfigurationen verwalten und warten müssen. 

Neben Pipelines im Kubernetes-Stil ermöglicht OpenShift die serverlose Erstellung und Ausführung von Pipelines, die Multi-Plattform-Bereitstellung (Kubernetes, VMs und andere serverlose Plattformen), das Erstellen von Images mit den Kubernetes-Tools (Buildah und Dockerfiles, Jib, Kaniko), die Entwicklung von Befehlszeilen-Entwicklertools für die Pipeline-Interaktion zusammen mit der OpenShift-Entwicklerkonsole und IDF-Plugins). 

Kubernetes Custom Resources (CRD) sind die Basis für die Erstellung von Continuous Integration/Continuous Delivery Pipelines. Die folgenden Punkte geben einen kurzen Überblick darüber:

• Task: Eine Reihe von Befehlen oder Schritten, die in separaten Containern in einem Pod ausgeführt werden.
• Pipeline: Sammlung von Tasks, die in einer definierten Reihenfolge ausgeführt werden.
• PieplineResource: Eingaben (Git-Repository) und Ausgaben (Image-Registry) für die Pipeline.
• TaskRun: Laufzeitdarstellung der Task-Ausführung.
• PipelineRun: Laufzeitdarstellung einer Pipeline-Ausführung.

Abschließende Bemerkung:

Organisationen sind voll und ganz bestrebt, ihren Kunden das Beste zu liefern. Dabei vollziehen sie in rasantem Tempo den Übergang zu Cloud-Native.  In Kombination mit Continuous Delivery hat sich Cloud-Native zu einer Reform für den Anwendungsentwicklungsprozess entwickelt. Zunehmende Geschwindigkeit, Komplexität und Verantwortlichkeiten sind die Herausforderungen, die damit einhergingen. Um die zuvor genannten Probleme zu lösen, ist ein dezentraler Ansatz mit dem Austausch von Prozessen und Praktiken zu verfolgen. Tools wie OpenShift Pipelines haben sich als Hilfsmittel für den Continuous-Delivery-Prozess herauskristallisiert.

Was halten Sie davon? Teilen Sie Ihre Meinung auf unseren sozialen Kanälen: Facebook, LinkedIn und Twitter.