Im letzten Beitrag haben wir die Prinzipien der “Continuous Integration & Delivery” vorgestellt. Heute runden wir den Layer mit dem Thema “App Definition and Development” aus der CNCF-Landscape ab. “App Definition & Image Build” gehört größtenteils zu einer CI/CD Pipeline, konzentriert sich aber insbesondere auf die Application Delivery.
Applikation definieren
Damit eine Applikation geliefert werden kann, muss zunächst einmal festgelegt werden, was eine Applikation ist. Im Bereich der Containerisierung und der Aufteilung von Services in Microservices kann das schon einmal verwirrend werden. Zum Verständnis dieses Beitrags genügt, dass wir einen funktionsfähigen, alleinstehenden Service mit einer konkreten Aufgabe als Applikation definieren. Eine Darstellung der Inhalte einer Website wäre also eine einzelne Applikation. Dazu kommt eine Instanz zur Verarbeitung der Eingaben auf der Website, genau wie eine Datenbank. Alle drei Instanzen – das Frontend, das Backend und die Datenbank – können unabhängig voneinander funktionieren und bilden zusammen einen Application Stack, um die Aufgaben zu verbinden und den schlussendlichen Mehrwert zu liefern. In unseren Beispiel ist der Mehrwert durch eine Website gegeben, die den Nutzer alle geplanten Funktionen ausführen und speichern lassen.
Microservices können dann auch Applikationen sein, welche eigenständig lauffähig sind. Der Unterschied zu den vorherigen Services liegt dabei in der Aufgabenteilung. Ein Backend-Service, welcher mit Hilfe eines Cache die Datenabfrage beschleunigt, kann sich eines Microservice bedienen, welches diese Aufgabe übernimmt. Memcached und RabbitMQ wären je nach Anwendung also innerhalb einer Applikation als eigenständige Applikation definierbar, obwohl sie Teil des Backend sind.
Warum das wichtig ist
Die Definition einer Applikation verdeutlicht am Ende, wie die Application Delivery aussehen kann. Zeitgleich hebt es noch einmal die Bedeutung der Systemarchitektur hervor. Denn ohne Architektur ist keine klare Tool-Wahl möglich.
Mit der Entscheidung die eben beschriebene Applikationen als verteiltes System mit Microservices auf Kubernetes zu betreiben, ist jetzt alles definiert was wir brauchen, um die verschiedenen Tools einmal näher in Augenschein zu nehmen.
Anhand der Definition einer Applikation lässt sich übrigens auch die Aufgabenteilung in der Softwareentwicklung gut beschreiben. Wenn man den Gedanken von Microservices verfolgt, können kleine Teams gezielter und umfangreicher jede beliebige Komponente entwickeln. Abgesehen von gemeinsamen Schnittstellen auch vollkommen unabhängig.
Die Toolchain beginnt jetzt
Sei es eine Schnittstellendefinition mit OpenAPI, die Erstellung von Containern mit kaniko oder die Auflistung der Konfigurationsparameter von Applikationen mit Helm – jedes Tool unterstützt Entwickler dabei, während der Code-Erstellung die Applikation bereit für den Betrieb auf Kubernetes zu machen.
Hier zeigt sich, wie gut die vorgestellten Bestandteile der CNCF-Landscape ineinander greifen. Denn die Aufgaben aus der Entwicklung spiegeln den Bedarf der anderen Komponenten wider. Es beginnt mit der Programmierung, geht über in die Testphase, behandelt die Integration von bestehenden Tools und endet schlussendlich im Betrieb.
Alles berücksichtigt? Los geht’s!
Jedes Tool bringt seine eigenen Vorteile mit. Daher ist besonders in diesem Bereich die Nutzung mehrerer Tools für verschiedene Teilaufgaben zu empfehlen.
Angefangen mit der Cloud-Nativen-Entwicklungsumgebung Eclipse Che. Diese bietet die Möglichkeit, für jeden Entwickler bereits definierte Microservices in einem eigenen Namespace auf Kubernetes zu starten und per Web-IDE Theia die Applikation zu entwickeln und zu deployen. Die Installation ist jedoch sehr umfangreich. Als lokale Umgebung kann Skaffold einen guten Ersatz darstellen.
Für die Definition von Deployment-Konfigurationen sind weiterhin Helm-Charts zu empfehlen.
Für das Erstellen von Container-Images ist Kaniko zu empfehlen, welches auch ohne besondere Rechte in der Lage ist, Images zu erstellen. Die Ablage aller Komponenten kann dann in einem git-Repository erfolgen.
Der Vorteil der hier dargestellten Toolchain ist insbesondere die Integration in andere Toolchains. So ist die Toolchain für die CI/CD-Pipeline mit ähnlichen Komponenten möglich. Das erleichtert auch den Ansatz des Shift-Left-Testings.
Damit wird auch die Integration in die anderen Bereiche deutlich. Wenn man die Application Delivery als Ausgangspunkt sieht, folgen daraus die anderen Themenbereiche.
Die Reihenfolge der Themen für Software-Entwickler sieht dann wie folgt aus:
- Application Delivery & Image Build
- Continuous Integration & Delivery
- Database
- Streaming & Messaging
- Service Proxy oder Service Mesh
Für Administratoren ist es umgekehrt:
Der Einstieg in die Kubernetes-Welt
In der Blogreihe haben wir gezeigt, welche Herausforderungen im Umgang mit Kubernetes warten und welche Tools beim Einstieg helfen. Zeitgleich sollte die Komplexität und die Vielfalt im Cloud-nativen Umfeld mit unseren Erfahrungen reduziert werden.
Auch wenn wir damit Kubernetes 101 abschließen, gilt weiterhin: Wenn Du Fragen hast oder bei der Entscheidung Hilfe benötigst, helfen wir Dir gern weiter. Wir haben für alle Probleme den richtigen Lösungsansatz. Schreib uns einfach!
