Google Cloud Run und App Engine im Vergleich

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.