Was bedeutet serverlos?

Das serverlose Computing stellt einen Paradigmenwechsel in der Anwendungsentwicklung dar, da Entwicklern damit ermöglicht wird, sich auf das Schreiben von Code zu konzentrieren, ohne sich um die Infrastruktur kümmern zu müssen. Im Vergleich zum herkömmlichen Computing bietet es eine Reihe von Vorteilen wie automatische Serververwaltung, On-Demand-Bereitstellung, Autoscaling und nutzungsbasierte Zahlung. Aufgrund dieser Vorteile eignet sich das serverlose Computing ideal für Anwendungsfälle wie z. B. zustandslose HTTP-Anwendungen, Webanwendungen, mobile Back-Ends, IoT-Back-Ends, Batch- und Streamdatenverarbeitung und Chatbots.


GCP-Portfolio für serverloses Computing

Symbol: Cloud Functions

Serverlose Funktionen und Ereignisse

Cloud Functions

Eine ereignisgesteuerte Computing-Plattform für die einfache Verbindung und Erweiterung von Google- und Drittanbieter-Cloud-Diensten sowie die Entwicklung von Anwendungen, die sich problemlos für den globalen Einsatz skalieren lassen.

Weitere Informationen  
App Engine-Standardumgebung

Serverlose HTTP-Anwendungen

App Engine-Standardumgebung

Eine vollständig verwaltete, serverlose Anwendungsplattform für Web- und API-Back-Ends. Sie können in der App Engine-Standardumgebung gängige Entwicklungssprachen verwenden und müssen sich nicht um das Verwalten der Infrastruktur kümmern.

Weitere Informationen  
Cloud Run

Serverlose Container

Cloud Run

Eine serverlose Computing-Plattform, mit der Sie zustandslose Container ausführen können, die über HTTP-Anfragen aufrufbar sind. Cloud Run ist als vollständig verwaltete Plattform, bei der Sie nur für die tatsächliche Nutzung bezahlen, sowie als Teil von Anthos verfügbar.

Weitere Informationen  

Welche serverlose Computing-Plattform ist die richtige für Sie?

Diagramm: Serverlose Optionen

* Die App Engine-Standardumgebung unterstützt Node.js, Python, Java, Go und PHP.

* Cloud Functions unterstützt Node.js, Python und Go.

Anwendungsfälle

Symbol: Webanwendungen

Webanwendungen

Die App Engine-Standardumgebung eignet sich für fast managementfreie Webanwendungen, die in Node.js, Python, PHP, Java und Go ausgeführt werden. Sie können Ihre Anwendungen darin auf eine standardisierte, idiomatische Weise schreiben und dazu eine beliebige Sprachbibliothek verwenden. Aufgrund der kurzen Bereitstellungszeiten und der schnellen Skalierbarkeit ist die App Engine-Standardumgebung für Arbeitslasten mit Lastspitzen gut geeignet.

Asynchrone Back-End-Verarbeitung

Asynchrone Back-End-Verarbeitung

Cloud Functions dient dazu, auf Datenereignisse in der Cloud zu reagieren und einfache Verarbeitungsaufgaben durchzuführen, beispielsweise das Anpassen der Größe eines in Cloud Storage hochgeladenen Bilds oder das Validieren von Daten, wenn in der Firestore-Datenbank ein Wert geändert wurde.

Symbol: Mobile Back-Ends

Mobile Back-Ends

Bei herkömmlichen REST API-Back-Ends für mobile Apps dient die App Engine-Standardumgebung als App-Plattform, die die Hosting-Umgebung überwacht, aktualisiert und skaliert. Sie müssen lediglich den Code für Ihren mobilen Back-End-Dienst schreiben. Firebase bietet eine Reihe leistungsstarker Back-End-Dienste, die direkt in Ihre mobilen Apps integriert werden können: NoSQL-Echtzeitdatenbanken, Authentifizierung, Hosting, Dateispeicherung und viele mehr. Firebase lässt sich in Cloud Functions einbinden, sodass Sie problemlos eine Verbindung zu Ihren übrigen Google Cloud Platform-Diensten herstellen können.

APIs

APIs

Wenn Sie eine einfache API (eine begrenzte Anzahl von Funktionen, auf die über HTTP oder Cloud Pub/Sub zugegriffen werden kann) erstellen möchten, empfehlen wir die Verwendung von Cloud Functions. Es ist auf Arbeitslasten mit sporadischen Lastspitzen ausgelegt, und sein Programmiermodell (Funktionen) trägt dazu bei, dass Back-End-Code von begrenztem Umfang organisiert bleibt. Bei einer komplexeren API, z. B. einer REST API mit vielen Routen, empfehlen wir dagegen die Verwendung der App Engine-Standardumgebung, da Sie damit Ihre vielen Funktionen wahrscheinlich leichter organisieren können. Wenn Sie Ihre API mit Cloud Endpoints verwalten, empfehlen wir, die App Engine-Standardumgebung mit Python 2.7 und Java 8 zu nutzen, da diese Cloud Endpoints unterstützt.

Periodische Vorgänge

Periodische Vorgänge

Cloud Scheduler kann geplante HTTP-Anfragen senden, um Vorgänge nach einem benutzerdefinierten Zeitplan auszulösen. Er kann auch speziell auf App Engine oder HTTP-Endpunkte wie Cloud Functions und Cloud Run abzielen.

Symbol: Rapid Prototyping und API-Stitching

Rapid Prototyping und API-Stitching

Für kleine Projekte oder "Hackathon"-Projekte, bei denen Rapid Prototyping und/oder das Zusammenfügen mehrerer APIs und Dienste zum Einsatz kommen, empfehlen wir die Verwendung von Cloud Functions. Mit dessen Programmiermodell können Sie kleine Anwendungen und/oder "Klebecode" schnell entwickeln; mit letzterem können Sie vorhandene APIs und Dienste zusammenfügen.

Anbieterunabhängige Container ausführen

Anbieterunabhängige Container ausführen

Docker-Container sind der Branchenstandard und können in jeder Cloud oder lokal ausgeführt werden. Cloud Run kann Container auf eine serverlose Anfrage/Antwort-Art ausführen. Wir empfehlen, Cloud Run zu verwenden, es sei denn, Sie benötigen benutzerdefinierte Hardware wie GPUs oder einen Kubernetes-Cluster. In diesem Fall können Sie Cloud Run in GKE in Ihrem Google Kubernetes Engine-Cluster ausführen.

Serverlose und zustandsorientierte Arbeitslasten kombinieren

Serverlose und zustandsorientierte Arbeitslasten kombinieren

Cloud Run for Anthos ermöglicht Ihnen das parallele Ausführen serverloser und zustandsorientierter Arbeitslasten. Beispielsweise können Sie MongoDB vom Marketplace aus in Ihrem Anthos-GKE-Cluster bereitstellen, um es als Dokumentenspeicher für serverlose Arbeitslasten zu verwenden. Anthos bietet Ihnen die Flexibilität, Beliebiges in Ihrem Kubernetes-Cluster auszuführen, und mit Cloud Run for Anthos können Sie zusätzlich serverlose Arbeitslasten bereitstellen.

Produktvergleich

App Engine-Standardumgebung Cloud Functions Cloud Run Cloud Run for Anthos
Bereitstellungsartefakt App Funktion Container Container
Auf null skalieren Häkchen Häkchen Häkchen Pods2
Kostenlose Stufe Häkchen Häkchen Häkchen
WebSockets Häkchen
Sprachen Java, Node.js, Python, Go, PHP Node.js, Python, Go Alle Alle
Zugriffssteuerung OAuth 2.0, CICP, Firebase Authentication, Google Log-in, Users API IAM-Invoker-Berechtigung IAM-Invoker-Berechtigung, CICP, Google Log-in, Firebase Authentication Nur Cluster, nur VPC
HTTP/2 und gRPC Häkchen
Benutzerdefinierte Domain Häkchen Häkchen Häkchen
Zeitüberschreitung bei Anfrage 1 Minute3 9 Minuten 15 Minuten 15 Minuten
GPUs und TPUs Häkchen
VPC-Konnektivität Häkchen HäkchenBeta1 In Planung Häkchen

1 Beta-Software hat kein SLA.

2. Cloud Run in GKE skaliert die Anzahl der Pods auf null. Die Anzahl der Knoten pro Cluster kann jedoch nicht auf null skaliert werden. Diese Knoten werden Ihnen in Rechnung gestellt, wenn keine Anfragen vorhanden sind.

3. Automatische Skalierung: 60 Sekunden für HTTP-Anfragen.

Weitergehende Tipps und Best Practices

Hier sind einige weitere Faktoren, die Sie eventuell berücksichtigen sollten.