Was ist Cloud Native?
Microservices in der Cloud haben den Begriff Cloud-Native geprägt. Er beschreibt die Tatsache, dass cloud-native Software hochgradig verteilt ist (d.h. über ein Netzwerk miteinander kommuniziert), in einer sich ständig verändernden Umgebung existieren muss (z.B. die Anzahl der Worker Nodes ändert sich, wenn sich die Lastanforderungen ändern) und sich auch selbst ständig verändert (Continuous Delivery). Der Begriff Cloud beschreibt, wo wir unsere Software betreiben und Cloud Native beschreibt, wie wir sie betreiben.
Was ist Cloud-native Entwicklung?
Die Cloud-native Entwicklung von Microservices unterscheidet sich nicht unbedingt von der traditionellen Softwareentwicklung. Ausser dass wir nicht mehr (nur) eine lokale Infrastruktur haben, sondern Komponenten für die Cloud und mit der Cloud entwickeln.
Allerdings muss mehr Wert auf einige bereits bekannte Technologien und Prinzipien gelegt werden.
Diese sind:
- Container, Container-Orchestrierung und deren Besonderheiten bei Isolation, Automatisierung und Skalierung
- DevOps Philosophie und deren Prinzipien
- Microservices Architektur Pattern mit vielen unabhängigen Komponenten
- Resiliency
- Observability
- etc.
Was ist Cloud Native Coding?
Bei der Softwareentwicklung mit oder in der Cloud, stellt sich die Frage, welche Wege es gibt, die Entwicklung, Test, Debugging etc. optimal zu Unterstützen. Denn einerseits sollte die gewohnte Arbeitsumgebung weiter genutzt werden können. Andererseits werden die notwendigen Komponenten, die man zum Testen der eigenen Applikation auf dem Laptop benötigt, immer mehr und ressourcen-hungriger.
Dabei gibt es prinzipiell 3 verschiedene Möglichkeiten:
- Lokal: Alle Services und der gesamte Sourcecode/IDE/Applikationen befinden sich auf dem Laptop
- Hybrid: Sourcecode/IDE/Applikationen ist auf dem Laptop und die Services befinden in der Cloud
- Cloud: Alle Services und auch die Sourcecode/IDE/Applikationen befinden sich in der Cloud
Lokal
Die reine lokale Programmieren ist der klassische Weg eine Applikation zu entwickeln. Hier kann der Entwickler weitgehend selbst und frei über seine Tools und Prozesse entscheiden.
Vorteile:
- man muss nicht online sein
- der Development-cycle enthält keine Containerisierung, kein Deployment und ist deswegen meistens schneller
- debugging kann direkt in der IDE erfolgen
Dennoch unterscheidet sich die Umgebung, die während der Entwicklung der Applikation verwendet wird, stark von der in der die Applikation später betrieben wird. Dies kann auch durch Verwendung von Mocks oder einzelnen Containern für Datenbanken oder Messaging nur wenig verbessert werden. Hier wird primär eher Funktionalität und API-Kompatibilität getestet, weniger das (Laufzeit-) Verhalten in einer komplexeren Produktionsumgebung.
Nachteile:
- Dev- und Produktionsumgebung stark unterschiedlich
- Mocks teilweise notwendig
- Keine komplexere Systemtests möglich
Zur Unterstützung der lokalen Entwicklung gibt es einige Tools die dies erleichtern. Einerseits helfen sie statt umfangreiche Mocks, die echten Tools als Container zu verwenden (Testcontainers). Andererseits ist es möglich komplette oder zumindest schlankere Versionen der Produktionsumgebung auf dem eigenen Laptop laufen zu lassen (durch Tools wie kind oder minikube). Zumindest bei Linux Entwicklungssystemen ist dies eine sehr gute Möglichkeit sehr produktionsnah zu entwickeln. Je weiter sich die Entwicklungssysteme (wie zum Beispiel Mac oder Windows) jedoch von den Produktionssystemen (die meistens Linux auf Intelbasis sind) entfernen, desto schwieriger wird dies.
Gängige Tools:
Testcontainers: Testcontainers ist eine Java-Bibliothek, die JUnit-Tests unterstützt und leichtgewichtige Wegwerf-Instanzen gängiger Datenbanken, Selenium-Webbrowser oder anderes bereitstellt und als Container ausgeführt werden kann.
kind ist ein Tool zum Ausführen lokaler Kubernetes-Cluster mithilfe von Container-„Knoten“. kind wurde in erster Linie zum Testen von Kubernetes selbst entwickelt, kann aber auch für die lokale Entwicklung oder CI verwendet werden.
minikube richtet schnell einen lokalen Kubernetes-Cluster auf macOS, Linux und Windows ein. minikube konzentrieren sich darauf, Anwendungsentwicklern und neuen Kubernetes-Benutzern zu helfen.
Hybrid
Bei der Hybriden Entwicklung wird versucht die Flexibilität und Kapazität einer Kubernetes-basierten Cloudumgebung so in ein Entwicklungssystem zu integrieren als wäre alles lokal. Die Tools dazu heissen beispielsweise kubefwd oder Telepresence. Damit der Dev Cycle auch in der Containerwelt unterstützt wird, bietet sich Skaffold an. Alle diese Tools lassen sich natürlich auch zusammen mit kind oder minikube sehr sinnvoll nutzen.
kubefwd ist ein Befehlszeilendienstprogramm, das entwickelt wurde, um mehrere Dienste innerhalb eines oder mehrerer Namespaces auf einem oder mehreren Kubernetes-Clustern weiterzuleiten. kubefwd verwendet denselben Port, der vom Dienst bereitgestellt wird, und leitet ihn von einer Loopback-IP-Adresse auf Ihrer lokalen Workstation weiter. kubefwd fügt Ihrer /etc/hosts-Datei vorübergehend Domäneneinträge mit den Dienstnamen hinzu, um das Cluster-interne DNS zu simulieren.
Telepresence ist ein Open-Source-Tool, mit dem Sie einen einzelnen Dienst lokal ausführen und diesen Dienst mit einem entfernten Kubernetes-Cluster verbinden können.
Skaffold kümmert sich um den Workflow zum Erstellen, Pushen und Bereitstellen der Anwendung, sodass sich die Entwickler auf das konzentrieren können, was am wichtigsten ist: das Schreiben von Code.
Cloud first
Durch Technologien wie beispielsweise Electron, die in IDEs wie VS Code verwendet wird, ist es möglich das "Backend" der IDE direkt als Pod in einem Kubernetes Cluster laufen zu lassen. Das Frontend wird durch einen Browser realisiert, der sich auf dem Gerät des Entwicklers befindet. Dies kann dann ein Laptop, ein Smartphone oder ein Tablet sein.
Die Vorteile die sich daraus ergeben sind beispielsweise:
- Es kann auf teure, voll ausgestattete PCs verzichtet und günstige Thin Clients eingesetzt werden
- Thin Clients entlasten die Administration der Geräte, die nur noch für einen funktionierenden Browser sorgen muss
- Es wird sich kein Code mehr auf dem Gerät selbst befinden. Dadurch wird die Sicherheit erhöht
- Es können spezifische, vorgenerierte und austauschbare Umgebungen (für Java, für Golang, für eine bestimmte Komponente) genutzt und verwaltet werden
- Die Grenzen der Entwicklungs- und Testumgebung werden durch die Grösse des Clusters bestimmt und nicht durch das Gerät auf dem entwickelt wird
Kandidaten dazu sind:
Fazit
Es wird oft unterschätzt, dass die aus guten Gründen notwendige Modularisierung von Monolithen und der Gang in die Cloud auch einiges an Veränderung bedarf. Security, Hochverfügbarkeit, Reciliency und Observability sind neben der eigentlichen funktionalen Entwicklung ebenso wichtig geworden. Dies zu testen ist essentiell und je früher so etwas im Entwicklungsprozess beginnt, desto besser. Dabei ist die Umgebung je wertvoller, desto näher man sich am Produktivsystem befindet. Beachtet man dies, können die genannten Tools eine grosse Hilfe sein.
