Freitag, 17. Mai 2024

Cloud Serie: Das GCP Serverless Trio in der Übersicht - mit etwas GKE

In den letzten drei Artikeln in dieser Cloud Serie habe ich drei verschiedene Möglichkeiten der Google Cloud (GCP) vorgestellt, mit denen sich serverless Programme ausführen lassen:
Jeweils erläutert anhand einer Beispiel-Applikation basierend auf der ESC-Bibliothek. In diesem Artikel fasse ich diese 3 Möglichkeiten nochmals kurz zusammen und gebe in einer Gegenüberstellung Hinweise, welches Werkzeug sich für welchen Einsatz am besten eignen könnte.

Cloud Functions
Vorweg: Das Produkt heisst offiziell "Cloud Functions". Ich schreibe es aber auch nicht konsequent in der Mehrzahl. Wenn es nur eine Funktion ist, schreibe ich häufig "Cloud Function". Mit Cloud Functions können einzelne Funktionen zur Verfügung gestellt werden. Dazu gibt es zwei Möglichkeiten:
  • HTTP-Funktion: Aufrufbar via URL (i.d.R. REST-API)
  • Ereignisgesteuerte Funktionen: Sind von folgenden GCP-Ereignissen aufrufbar: Pub/Sub-Trigger, Cloud Storage Trigger, Firestore Trigger, EventArc-Trigger


Unterstützte Sprachen:
Cloud Functions können in einer der folgenden Programmiersprachen implementiert werden:
  • JavaScript/Node.js
  • Python
  • Go
  • Java/JVM-Sprachen (bspw. Scala, Kotlin)
  • C#
  • Ruby
  • PHP

App Engine
Mit App Engine können komplette Applikationen, also nicht nur einzelne Funktionen, bereitgestellt werden. Dies erfolgt in einem pro Sprache definierten Standardcontainer. Dabei gibt es jedoch zwei Ausprägungen. Man kann zwischen der Standard- und der Flexibler-Umgebung wählen. Einen Vergleich der beiden gibt es hier: https://cloud.google.com/appengine/docs/the-appengine-environments?hl=de


Unterstützte Sprachen:
App Engine Applikationen können in einer der folgenden Programmiersprachen implementiert werden:
  • JavaScript/Node.js
  • Python
  • Go
  • Java/JVM-Sprachen (bspw. Scala, Kotlin)
  • C#
  • Ruby
  • PHP

Cloud Run
Cloud Run ist eine vollständig verwaltete Container-Plattform. Mit Cloud Run kann man sehr einfach Applikationen als Docker-Image deployen.

Offizielle GCP-Präsenzhttps://cloud.google.com/run?hl=de

Unterschiede zu App Engine folgen gleich im nächsten Teil. An dieser Stelle möchte ich GKE als mögliche Alternative erwähnen. Wann braucht man GKE anstelle von Cloud Run? GKE ist für viele Anwendungen und gar für viele Organisationen mit Kanonen auf Spatzen geschossen. Cloud Run hat seine Limitierungen vor allem da, wo man eine Microservice-Architektur für eine Anwendung mit sehr vielen einzelnen Services hat, welche enge Abhängigkeiten untereinander haben. Solche einzeln via Cloud Run orchestrierst zu deployen und zu managen kann aufwändig sein. Dazu gehört auch das Monitoring, welches in GKE für solche Szenarien einfacher "out-of-the-box" feingranularer möglich ist. Wie bei App Engine mit Standard und Flexibel, gibt es auch bei GKE mehrere Ausprägungen. Standard und Premium und dann vor allem "normal" (um nicht wieder Standard zu verwenden) und Autopilot. Letzterer vereinfacht das Management und reduziert die Aussage der Kanonen und Spatzen verstärkt auf die Kostensicht. App Engine Flexibel, Cloud Run und GKE Autopilot liegen nahe beisammen. Es versteht sich von selbst, dass letztlich bei allen drei Produkten wiederum Kubernetes die technische Basis ist. Selbst die neuen Cloud Functions sind letztlich nichts anderes als Container. Man sieht diese Cloud Functions (2nd Generation) in der Konsole auch unter Cloud Run. Dort steht bei "Deployed by" Cloud Functions. So schliesst sich der Kreis.

Gegenüberstellung
Die folgende Tabelle zeigt aus meiner Sicht relevante unterschiede zwischen den drei Produkte auf.

Vergleich von Cloud Functions, App Engine und Cloud Run - ohne Gewähr

Bei Standard App Engine wählt man eine Maschine aus einer Klasse aus, die Leistung ist eher bescheiden. Epp Engine Flexibel ist dagegen ein Biest. Die Frage ist, ob es nicht Software architektonische Mängel gibt, wenn eine Applikation auf einer Maschine laufen muss mit so viel Power. Ggf. wäre es sinnvoller, die Last auf mehrere Instanzen zu verteilen. App Engine ist generell bezüglich Netzwerk und Sicherheit "einfacher", da mehr direkt konfiguriert werden kann, während man bei Cloud Run diesbezüglich mit Load Balancer, Cloud Armor etc. ggf. zusätzliche Konfigurationen machen muss. Ein grosser Vorteil von Cloud Run ggü. App Engine ist aus meiner Sicht VPC, da man damit GCP Dienste einfacher einbinden/verwenden kann, also via App Engine.

Fazit
GCP bietet verschiedene Möglichkeiten, Applikationen serverless zu betreiben. Cloud Functions sind wahrscheinlich am einfachsten zu charakterisieren und zu wählen. Die Wahl zwischen App Engine (Flexibel) und Cloud Run ist nicht immer trivial, da werden feine Unterschiede den Ausschlag geben. In die Harmonie drei kommt dann noch GKE und insb. GKE Autopilot als Möglichkeit dazu. Das macht die Wahl zugegebener Massen nicht einfacher. Ich persönlich würde wann möglich nicht mit GKE starten, wenn nicht von Beginn an klar ist, dass es das braucht. Viele Szenarien lassen sich letztlich einfacher mit den drei hier vorgestellten Möglichkeiten umsetzen. Und gerade wenn man Cloud Run nutzt und damit bereits eigene Container-Definitionen hat, ist ein Wechsel auf GKE nicht so weit weg. Bei der Verwendung von GKE braucht man einfach bald weitere Technologien wie bspw. Helm, um bspw. effizient deployen zu können. Jede zusätzliche Technologie/Produkt braucht wiederum Know-how und Management und birgt Risiken. Das muss gut überlegt sein, ob damit die Vorteile insgesamt wirklich überwiegen oder (noch) nicht. In den meisten Fällen gibt es bei der Wahl kein Richtig oder Falsch. Neben den technischen Eigenschaften der Produkte muss bei der Wahl auch immer das eigene Know-how resp. das Know-how des Teams, der Firma berücksichtigt werden. Ebenso relevant ist die Menge. Vielleicht ist für ein Anwendungsfall Cloud Functions genau das Richtige. Wenn man aber nur eine einzige Cloud Functions hat, ist dies wohl organisatorisch nicht optimal und man entscheidet sich bspw. für Cloud Run, weil der Rest auch mit Cloud Run läuft. Dann überwiegt die Einfachheit des Tech- resp. Tool-Stack.







Keine Kommentare: