Google ist bekannt für Innovation und für durchdachte Konzepte. Das gilt insbesondere für jene, die für Google selbst am meisten Nutzen stiften. Erst vor Kurzem wurde in diesem Spannungsfeld das Skaffold-Projekt für produktreif erklärt. Skaffold befeuert derzeit zahlreiche Diskussionen, gibt es damit doch nun eine interessante Komposition von Google-Tools zur Entwicklung containerbasierter Softwarelösungen für Cloudumgebungen. Und all das mit Fokus auf dem Orchestrierungstool Kubernetes, quasi dem derzeitigen Standard in der Verwaltung von Containeranwendungen in der Cloud. Ein grober Überblick zu den erwähnten Technologien findet sich im vorangegangenen Artikel dieser Serie. Der Weg von Google beginnt in diesem Kontext also mit der Bereitstellung flexibler Open-Source-Tools und endet derzeit bei seinen eigenen Managed-Cloud-Services.

Mit Vorteilen und Risiken in genau diesem Spannungsfeld, beschäftigt sich der folgende Beitrag.

Beim Herstellen einer containerbasierten Softwareumgebung sind einige Schritte nötig, um geschriebenen Sourcecode in einen lauffähigen Zustand zu versetzen. Arbeitet man mit mehreren Containern in einer etwas größeren Umgebung, also einer typischen Micro-Service-Architektur, ist der Einsatz eines Container-Ochestrierungstools sinnvoll. Heute wird zumeist Kubernetes zur Verwaltung von Containerlösungen genutzt. Trotz Orchestrierungsschicht bleibt jedoch genug „manuelle“ Arbeit übrig, um entwickelten Sourcecode auch innerhalb von Kubernetes in einen arbeitsfähigen Zustand zu versetzen und gleichermaßen zu pflegen, zu testen und zu verwalten.

Das mehrstufige Verfahren beginnt mit dem Schreiben oder Ändern von Sourcecode. Sind die Programmierarbeiten abgeschlossen, muss zunächst ein Containerimage erstellt werden, um es in einem Cluster zu deployen. Dazu sind sogenannte Yaml-Dateien anzupassen (Dateien mit Konfigurationsbeschreibungen), um zum Beispiel neue Software- und Containerversionen zu kennzeichnen. Diese neuen Informationen werden über einen Befehl auf der Kommandozeile in den Cluster überführt. Anschließend ist das Ergebnis zu verifizieren, damit sichergestellt ist, dass das gewünschte Systemverhalten auch wirklich erreicht wurde. Mit der nächsten Anpassung des Sourcecodes beginnt dieser Zyklus von Neuem – gewissermaßen eine Endlosschleife von Anpassungen im Source Code und dem anschließenden Deployment- und Verifizierungsprozess – egal wie banal auch eine Änderung sein mag. In der realen Welt sprießen üblicherweise hausgemachte Skripte wie Pilze aus dem Boden, um wenigstens einen Teil des beschriebenen Ablaufs zu automatisieren.

An dieser Stelle setzt das Tool Skaffold aus dem Hause Google an. Skaffold ist Open Source, also kostenlos und ermöglicht auf dem lokalen Rechner eines Entwicklers, den neu erstellten oder geänderten Source Code automatisiert in Container zu verpacken sowie anschließend in einem Kubernetes-Cluster bereitzustellen und auch zu starten. Im richtigen Modus aktiviert, werden lokale Anpassungen am Code vollständig und automatisiert erkannt und in ein Kubernetes-Cluster übertragen. Das Konzept ist wirklich spannend, denn die Arbeit in der Entwicklung kann so tatsächlich erheblich vereinfacht werden, weil ein Großteil der sonst manuellen Tätigkeiten jetzt automatisierbar ist.

Zusätzlich zu den skizzierten Vorteilen von Skaffold, ist das Google-Add-on Cloud Code einen Blick wert – eine Erweiterung sogenannter IDEs (integrierte Entwicklungsumgebung oder im Original: Integrated Development Enviroment). Eine IDE ist eine Sammlung von wichtigen Tools unter einer gemeinsamen Oberfläche für das Erstellen von Software. Cloud Code von Google unterstützt derzeit zwei dieser IDEs, nämlich VS Code und IntelliJ IDEA. Der fachliche Mehrwert liegt unter anderem darin, Yaml-Templates bereitzustellen, die es ermöglichen, Steuerdateien einfacher und schneller zu erzeugen bzw. deren Funktionsfähigkeit während des Erstellungsprozesses zu überprüfen, bevor ein Deployment angestoßen wird. In Kombination eingesetzt, versprechen Cloud Code und Skaffold, zukünftig die Entwicklung von Lösungen im containerbasierten Cloudumgebungen signifikant zu vereinfachen und damit zu beschleunigen.

Wir sprechen an dieser Stelle noch nicht von einem produktiven Deployment in eine operative IT-Infrastruktur. Da beide Projekte Open Sources sind, funktioniert das beschriebene Konstrukt hervorragend, ohne dabei in eine Abhängigkeit der Managed Services aus der Google Cloud zu geraten. So könnte ein produktives Zielsystem auch gern in der eigenen Infrastruktur (On-Premises), aber auch in Azure oder AWS liegen.

Genau an dieser Stelle wird es interessant. Denn ein automatisiertes Deployment im Rahmen eines Continuous-Deployment-Prozesses (permanente Auslieferung von aktualisierter Software ohne lange Planungsperioden und Downtimes) ist natürlich das Tüpfelchen auf dem I. Google beglückt uns auch in diesem Fall mit einem kleinen Helferlein namens Cloud Build. Cloud Build soll nämlich genau diese letzte Lücke zur vollständigen Glückseligkeit schließen und kann relativ einfach durch wenige Codezeilen in einem Skaffold-Yaml aktiviert werden. Mit überschaubarem Aufwand ist es möglich, vollständige Deploymentprozesse in einem produktiven Kubernetes-Cluster zu implementieren. Es gibt aber ein kleines Detail zu beachten. Cloud Build ist derzeit in zwei Ausprägungen verfügbar. Eine Open-Source-Variante erstellt die Builds als lokale Version und beschränkt sich dabei auf singuläre Builds auf genau einem Host. Mehrere Build-Prozesse auf multiplen Hosts sind mit dieser Version nicht möglich. Aber genau das wäre ja das erklärte Ziel einer sinnvollen Micro-Service-Architektur. Um multiple Builds parallel zu starten, kann Cloud Build jedoch als Managed Service direkt aus der Google Cloud konsumiert werden. Dadurch können Docker-Images in der Google Cloud erzeugt werden. Man verbindet also die lokale Entwicklungsumgebung mit dem Service aus der Google Cloud, um Images in der Google Infrastruktur zu erzeugen. Sollte das eigene Kubernetes-Cluster in Azure oder AWS laufen, schaut man in diesem Fall erst einmal in die Röhre. Ein meines Erachtens geschickter Zug von Google, die letzte Meile nur als Teaser frei verfügbar zugänglich zu machen. Man kann an der Wurst schnuppern, aber sie nur verspeisen, wenn man sich an den Tisch der Google Cloud setzt.

Ich rekapituliere:

Skaffold und Cloud Code sind Tools, um die Entwicklung in einem Container-Umfeld mit Kubernetes zu vereinfachen bzw. zu beschleunigen. Sie sind jedoch nicht geeignet, um produktive Deploymentpipelines im Sinne einer Continuous-Deployment-Strategie zu managen. An dieser Stelle liefert Google das Tool Cloud Build, das relativ leicht an eine Entwicklungsumgebung angedockt werden kann. Voll funktionsfähig ist Cloud Build jedoch nur in der Google Cloud selbst bzw. in einem dort gehosteten Kubernetes-Cluster. Insofern liefern die betrachteten Komponenten durchaus einen Mehrwert im Rahmen von Entwicklungsprozessen, enden aber potenziell auch am Fliegenfänger der Managed-Google-Services bzw. in der Google Cloud. Wie immer sollte das Kleingedruckte gelesen werden, bevor man euphorisch auf den „Managed-Service-Zug“ springt. Die gewonnene Flexibilität in der Entwicklung ist nämlich nicht sonderlich viel wert, wenn man seine Deploymentprozesse nicht ohne den Service Provider abbilden kann. Mit proprietären Kubernetes-Implementierungen, die einige Dinge zwar stark vereinfachen, aber nur unter bestimmten Voraussetzungen und bei einem bestimmten Anbieter verfügbar sind, ist langfristig keinem Unternehmen geholfen. Auch wenn der erste Schritt ohne Managed Service etwas teurer sein mag, ist man besser beraten in eigenes Know-how zu investieren, denn Unabhängigkeit im Bereich der IT-Infrastruktur macht sich perspektivisch ganz sicher bezahlt.