Gorodenkoff - stock.adobe.com
Google Cloud Run und App Engine im Vergleich
Google Cloud Run und App Engine sollen die Entwicklung von Apps beschleunigen und die Bereitstellung vereinfachen. Der Vergleich präsentiert Vor- und Nachteile beider Tools.
Obwohl der Begriff Serverless Computing etwas irreführend ist, wird er häufig verwendet, um Cloud-Dienste zu beschreiben, die keinerlei Vorabbereitstellung oder Ressourcenmanagement erfordern.
Cloud-Dienste wie Google bieten ein umfangreiches Portfolio an serverlosen Produkten an. Dieses reicht von einer Basis-Infrastruktur bis hin zu gebündelten KI-Umgebungen. Die Grundlage des Serverless-Angebots der Google Cloud Platform (GCP) bilden drei Services: Sie sind darauf ausgelegt, die Anwendungsentwicklung zu beschleunigen, die Bereitstellung zu vereinfachen und die Skalierung von Ressourcen sowie andere betriebliche Aufgaben zu automatisieren.
Cloud Functions führt eine ereignisgesteuerte Funktion als Service (Function as a Service, FaaS) in beliebigem Umfang und ohne Management-Overhead aus. Die Nutzer zahlen nur für die Ausführungszeit, die mit einer Granularität von 0,1 Sekunden gemessen wird.
Cloud Run ist eine verwaltete Laufzeitumgebung für containerisierte Anwendungen. Der Dienst unterstützt Images, die in einer beliebigen Sprache geschrieben sein können. Er ist außerdem in die anderen Cloud-Entwicklungsdienste von Google integriert, darunter Cloud Code, Cloud Build und Artifact Registry. Wie Cloud Functions wird auch Cloud Run nach der gesamten Ausführungszeit abgerechnet, die auf 0,1 Sekunden genau gemessen wird.
App Engine ist ein PaaS-Angebot für Webanwendungen. Diese können in Node.js, Java, Ruby, C#, Go, Python, PHP oder einer beliebigen benutzerdefinierten Laufzeitumgebung geschrieben und als Container verpackt sein. Wie Cloud Functions und Cloud Run skaliert auch App Engine automatisch, um sich an wechselnde Arbeitslasten anzupassen. Die Plattform arbeitet zudem mit den Überwachungs-, Protokollierungs- und Debugging-Diensten von Google zusammen.
Im Vergleich zu Cloud Functions bieten Cloud Run und App Engine mehr Flexibilität. Dies kann von Vorteil sein, da die meisten Unternehmensanwendungen nicht rein ereignisgesteuert sind.
Cloud Run: Container ohne Kubernetes-Probleme
Cloud Run ist ein Container-on-demand-Service – ganz analog wie Azure Container Instances und AWS Fargate. Im Gegensatz zu Google Kubernetes Engine (GKE) ist Cloud Run für zustandslose Webanwendungen konzipiert, auf die über HTTP, WebSockets oder gRPC-Anfragen oder -Streams zugegriffen wird. Daher eignet sich Cloud Run nicht für Anwendungen, die ein persistentes Dateisystem benötigen.
Die Cloud-Run-Umgebung kann jeden Code und jede Bibliothek verarbeiten, die in einem benutzerdefinierten Container gepackt sind. Sie umfasst von Haus aus Laufzeitumgebungen für Go, Java, Node.js, Python oder .NET Core. Dies ist besonders für Entwickler interessant, die diese Skriptsprachen verwenden. Schließlich gehören sie zu den beliebtesten Sprachen für Webanwendungen.
Cloud Run basiert auf der Open-Source-Umgebung Knative. Diese ermöglicht es Entwicklern, Anwendungen auf lokale On-Premises-Systeme oder andere Knative-kompatible Cloud-Dienste zu portieren.
Mit Knative lässt sich Cloud Run Code in Sekunden bereitstellen und mit Frameworks wie Django, Ruby on Rails, Spring und anderen verknüpfen. Sollte keine Nachfrage bestehen, kann Cloud Run alle Instanzen abschalten. Dies macht den Dienst effizient für zustandslose Webanwendungen mit stark schwankenden Arbeitslasten.
Weitere Merkmale sind:
- die Möglichkeit, den Datenverkehr auf verschiedene Anwendungsversionen aufzuteilen, um schrittweise Beta-Versionen oder Blue/Green-Tests einzuführen
- automatische Redundanz mit Instanzen, die automatisch über mehrere Zonen hinweg repliziert werden
- Unterstützung für benutzerdefinierte Domains, Zuordnung von Cloud Run und Verwendung eines privaten TLS-Zertifikats anstelle des Zertifikats, das bei Verwendung von Cloud Run Domain Mapping automatisch bereitgestellt wird
Zu den idealen Anwendungen und Anwendungsfällen von Cloud Run gehören:
- dynamische Websites, die ein Framework wie Django oder Ruby on Rails verwenden
- Backend-Webdienste mit REST APIs
- ereignisgesteuerte Datentransformationen wie die Konvertierung einer CSV-Datei in eine strukturierte Tabelle für Data Warehouses a la BigQuery
- geplante Batch-Jobs für Aufgaben wie die Konvertierung von Dokumenten, zum Beispiel die Umwandlung von Word-Dokumenten oder Excel-Formularen in PDF-Dateien
App Engine: codezentrierte Wahl
App Engine geht auf Compute Engine und andere Infrastrukturdienste von Google Cloud zurück. Diese Dienste stellten eine standardisierte Entwicklungs- und Laufzeitumgebung für Webanwendungen bereit. App Engine wurde seitdem über App Engine Flexible Environment erweitert, um benutzerdefinierte containerisierte Laufzeiten zu unterstützen. Flexible Environment ist eine Art Hybrid zwischen der standardmäßigen, codezentrierten App Engine und den containerbasierten Cloud Run und GKE.
Google zielt mit App Engine auf Anwendungen ab, die als Microservices konzipiert sind. Dies gilt insbesondere bei der Verwendung der Standardumgebung, da sie Code in einer sicheren Sandbox ausführt und Anwendungen innerhalb von Sekunden bereitstellen und automatisch skalieren kann. App Engine verwendet für jede Bereitstellung Container-Instanzen. Bei Nutzung der Standardumgebung sind diese mit einer der folgenden Support-Laufzeiten vorkonfiguriert:
Python (die Versionen 2.7, 3.7, 3.8 und 3.9 werden derzeit unterstützt)
Java 8 und Java 11
js (Versionen 10, 12, 14 und 16)
PHP (5.5, 7.2, 7.3 und 7.4)
Ruby (2.5, 2.6 und 2.7)
Go (1.11-1.16)
Die Entwickler legen die Laufzeit der App Engine und die Bereitstellungskonfiguration in einer YAML-Datei fest. Sie können diese mit einem einfachen Befehl bereitstellen:
gcloud app deploy
Die Konfiguration identifiziert auch eine Instanzklasse, die die für jede Anwendung verfügbaren CPU- und Speicherressourcen bestimmt. Die kleinste und standardmäßige Instanz, F1, bietet beispielsweise eine 0,6 GHz vCPU mit 256 MB Speicher. Die größte Instanz B8 umfasst einen äquivalenten Prozessor mit 4,8 GHz und 2048 MB RAM.
Entwickler konfigurieren die flexiblen Environments von App Engine über eine ähnliche YAML-Datei, die jedoch eine vom Benutzer bereitgestellte Laufzeitumgebung erfordert. Es ist möglich, jede beliebige Kombination von CPUs zu verwenden, von eins bis 80 in Zweierpotenzen; RAM, das den Mindestanforderungen pro Anwendung unterliegt; und Festplatte von 10 GB bis 10 TB.
Wie Cloud Run werden auch die App-Engine-Standardumgebungen nach der Anzahl der genutzten Instanzstunden abgerechnet. Die Preise richten sich nach der Größe der Instanz. Google berechnet die Preise für flexible Umgebungen als eine Kombination aus vCPU-Stunden, RAM-GB-Stunden, Größe der persistenten Festplatte und ausgehendem Netzwerkverkehr.
Sowohl Cloud Run als auch App Engine zielen auf webbasierte, zustandslose Anwendungen ab (es sei denn, sie verwenden Flex-Umgebungen). Insbesondere sind das solche, die mit einer der Standard-Laufzeitumgebungen entwickelt wurden, oder auf REST-Backends mit sehr variablen Arbeitslasten.
Dazu gehören:
- statische Websites und dynamische Webdienste
- mobile Backends
- Protokoll- und Datenverarbeitungs-Workflows
Cloud Run versus App Engine: Wählen Sie für Ihre Aufgabe den besten Service
Cloud-native Anwendungen werden idealerweise in viele Komponenten oder Microservices zerlegt. Diese Komponenten beruhen auf mehr als nur Code, der in einer einzigen Laufzeit- oder Container-Umgebung gekapselt ist.
Ein Hauptvorteil der Cloud ist der Zugang zu einer Reihe von serverlosen Datenmanagement-, Analyse- und KI-Diensten. Unabhängig davon, ob Sie App Engine oder Cloud Run nutzen, ist die Arbeit eines Entwicklers immer mit anderen Google Cloud-Diensten verbunden. Einige Beispiele sind BigQuery, Bigtable, Pub/Sub, Cloud Storage und die Vision API.
Entwickler sollten die Wahl zwischen Cloud Run und App Engine für benutzerdefinierten Code nicht als eine einmalige Entscheidung betrachten. Stattdessen sollten sie den Service wählen, der für einen bestimmten Microservice oder ein Anwendungssubsystem am besten geeignet ist.
