Was ist serverloses Computing?

Beim Erstellen von Anwendungen müssen Entwickler in der Regel eine Reihe anderer Serververwaltungsaufgaben ausführen, die sie ausführen müssen, um ihren Code bereitzustellen, z. B. Ressourcen für Verarbeitung und Speicherung definieren, Patching, Load-Balancing und mehr. All diese zusätzlichen Elemente führen zu längeren Bereitstellungszeiten und zusätzlichem Betriebsaufwand, was letztendlich die Entwicklungsteams verlangsamt. 

Beim serverlosen Computing wird versucht, Entwicklern ein unsichtbares „serverloses“ Erlebnis zu bieten, sodass sie sich keine Gedanken über Server oder alles machen müssen, was eine Anwendung möglicherweise für die Ausführung braucht. Stattdessen erledigt der Dienstanbieter die ganze Arbeit im Hintergrund, um sicherzustellen, dass Sie die Ressourcen haben, um Ihren Code auszuführen und Anforderungen zu erfüllen, ohne dass Ihnen ungenutzte Kapazitäten in Rechnung gestellt werden. 

Ein serverloser Ansatz ist wie das Wasser in Ihrem Haushalt. Sie könnten Ihren eigenen Brunnen graben, die Wasserqualität testen und alle externen Rohrleitungen installieren und warten, die für den Einbau im Haus erforderlich sind. Sie können auch eine Verbindung mit der Hauptwasserversorgung Ihrer Stadt herstellen. Sie drehen einfach den Wasserhahn und bekommen genau dann so viel Wasser, wie Sie möchten, und die Stadt sendet Ihnen eine monatliche Rechnung über die exakte Wassermenge. 

Auf ähnliche Weise richten Cloud-Anbieter die Infrastrukturressourcen und Laufzeitumgebungen hoch, die für die Ausführung Ihrer serverlosen Anwendungen erforderlich sind. Nach Abschluss der Ausführung werden sie automatisch wieder auf null herunterskaliert. In der Regel werden Ihnen die Kosten basierend auf den Ressourcen während der Ausführungszeit in Rechnung gestellt. Dies kann jedoch je nach Dienst und Anbieter variieren. 

Aber Moment mal: Bieten nicht auch andere Arten von Cloud-Computing On-Demand-Ressourcen auf Pay-as-you-go-Basis? Es stimmt, dass Cloud-Dienstmodelle wie Infrastructure as a Service (IaaS) und Platform as a Service (PaaS) ebenfalls On-Demand-Zugriff auf Rechenressourcen bieten. 

Die Ihnen zugewiesene Cloud-Infrastruktur bleibt jedoch aktiv, auch wenn Sie sie nicht nutzen. Außerdem sind Sie dafür verantwortlich, die Serverkapazität zu skalieren oder Ihre Anwendungen so zu konfigurieren, dass sie je nach Nutzerbedarf hoch- oder herunterskaliert werden. 

Serverlose Architekturen sind dagegen ereignisgesteuert. Bei diesem Modell stellt der Anbieter nur dann Ressourcen bereit, wenn ein Ereignis die Ausführung Ihres Codes auslöst. Die Ressourcen werden sofort und automatisch an die Anfragen angepasst.

Beim serverlosen Cloud-Computing gibt es im Allgemeinen zwei Arten von Diensten: FaaS (Function as a Service) und Backend as a Service (BaaS). 

• FaaS stellt die Rechenressourcen bereit, die für die Ausführung der Anwendungslogik als Reaktion auf Anfragen erforderlich sind. Diese Logikbausteine (oder Funktionen) werden in Containern ausgeführt, die vollständig vom Cloud-Dienstanbieter verwaltet werden. Serverlose Anwendungen sind in der Regel in einzelne Funktionen unterteilt, die als Reaktion auf ein Ereignis eine Aktion ausführen. 
• BaaS bietet die gesamte Backend-Funktionalität von Web- oder mobilen Anwendungen als Dienst an, z. B. Authentifizierungsdienste, Datenbankverwaltung, Cloud-Speicher, Push-Benachrichtigungen und Hosting. Außerdem müssen Sie keine Server, Container oder virtuellen Maschinen verwalten. 

In der Entwicklung wird der Begriff „serverlos“ in der Regel für FaaS-Angebote verwendet. FaaS ist jedoch technisch gesehen eine Untergruppe der serverlosen Technologie. Serverloses Computing umfasst alle Arten von Diensten, bei denen Serververwaltung, Konfiguration, Skalierung und Abrechnung für den Endnutzer abstrahiert werden. Dazu gehören Datenbanken, Speicher, Ereignis-Streaming, Messaging und API-Gateways. 

Zu den häufigsten und neuen Beispielen für serverloses Computing gehören:

• Anwendungsfall: Nahtlose Synchronisierung von Leads/Kunden zwischen verschiedenen Geschäftsanwendungen (z. B. CRM und Marketingautomatisierung)
• Serverlose Lösung: Eine HTTP-getriggerte Cloud Run-Funktion empfängt Webhooks vom Quellsystem (z. B. Salesforce), transformiert die Daten und ruft die API des Zielsystems (z. B. HubSpot) auf. Dabei wird häufig Secret Manager für Anmeldedaten verwendet.
• Serverlose Google Cloud-Produkte: Cloud Run Functions und Secret Manager

• Anwendungsfall: Automatisierte Erstellung und Verteilung von Routineberichten
• Serverlose Lösung: Ein Cloud Scheduler-Job löst täglich über Pub/Sub eine Cloud Run-Funktion aus. Die Funktion fragt ein Data Warehouse (z. B. BigQuery) ab, verarbeitet die Daten zu einem Bericht und sendet ihn über eine E-Mail-API.
• Serverlose Google Cloud-Produkte: Cloud Scheduler, Pub/Sub, Cloud Run-Funktionen und BigQuery

• Anwendungsfall: Cloud-Kosten senken, indem inaktive Rechenressourcen automatisch identifiziert und verwaltet werden
• Serverlose Lösung: Ein nächtlicher Cloud Scheduler-Job löst über Pub/Sub eine Cloud Run-Funktion aus. Diese Funktion verwendet die Compute Engine API und Cloud Monitoring, um inaktive Instanzen zu identifizieren und sie automatisch zu beenden oder zu löschen. Die Aktionen werden in Cloud Logging protokolliert.
• Serverlose Google Cloud-Produkte: Cloud Scheduler, Pub/Sub, Cloud Run-Funktionen, Cloud Monitoring und Cloud Logging

• Anwendungsfall: Streamingdaten in großem Umfang verarbeiten und anreichern (Beispiel: Nutzeraktivität), um sofortige Einblicke zu erhalten und Maßnahmen zu ergreifen
• Serverlose Lösung: Nutzer-Clickstream-Ereignisse werden in Pub/Sub gestreamt. Eine Cloud Run-Funktion (oder ein Cloud Run-Dienst) verarbeitet diese Ereignisse, ergänzt sie mit Daten aus Firestore und veröffentlicht die angereicherten Daten dann in einem anderen Pub/Sub-Thema für Echtzeitanalysen in BigQuery oder personalisierte Empfehlungen.
• Serverlose Google Cloud-Produkte: Pub/Sub, Cloud Run-Funktionen, Cloud Run, Firestore und BigQuery

• Anwendungsfall: Build, Test und Bereitstellung von Mikrodiensten bei Codeänderungen automatisieren
• Serverlose Lösung: Ein Cloud Build-Trigger überwacht ein Git-Repository (Beispiel: Cloud Source Repositories). Bei einem Code-Commit führt Cloud Build Tests durch, erstellt ein Container-Image in Artifact Registry und stellt die neue Version automatisch in Cloud Run bereit.
• Serverlose Google Cloud-Produkte: Cloud Build, Cloud Run, Artifact Registry und Cloud Source Repositories

• Anwendungsfall: Beim Upload automatisch optimierte Bildvarianten erstellen (z. B. Miniaturansichten, verschiedene Formate)
• Serverlose Lösung: Eine Cloud Run-Funktion wird aktiviert, wenn ein neues Bild in einen Cloud Storage-Bucket hochgeladen wird. Diese Funktion verarbeitet das Bild (Größenänderung, Formatkonvertierung), speichert die neuen Versionen wieder in Cloud Storage und aktualisiert die Metadaten in Firestore.
• Serverlose Google Cloud-Produkte: Cloud Storage, Cloud Run Functions und Firestore

• Anwendungsfall: KI-Inferenz in Echtzeit mit LLMs wie Llama 3.1, Gemma 2, Mistral und anderen durchführen
• Serverlose Lösung: Cloud Run lässt sich in KI-Modelle wie die Gemini API, Vertex AI-Endpunkte oder Modelle einbinden, die in einem GPU-fähigen Cloud Run-Dienst gehostet werden. Außerdem kann Cloud Run als skalierbarer API-Endpunkt dienen und KI-Agents hosten.
• Serverlose GCP-Produkte: Cloud Run, Cloud Storage, Firestore

Einer der größten Nachteile von serverlosem Computing ist, dass es sich noch um eine relativ neue Technologie handelt. Daher ist es noch nicht für alle potenziellen Anwendungsfälle geeignet. 

Es ist auch klar, dass einige der aktuellen Schwächen im Laufe der Zeit behoben werden, da sich das serverlose Computing weiterentwickelt. Insbesondere wird bereits viel an Open-Source-Implementierungen von serverlosem Computing und an Möglichkeiten gearbeitet, Cloud-Dienste offener zu gestalten, um Lösungen auf verschiedene Plattformen und Umgebungen übertragbar zu machen.

• Eingeschränkte Eignung für Anwendungsfälle: Serverlose Architekturen sind nicht immer für Anwendungen mit spezifischen Anforderungen geeignet, z. B. für Prozesse mit langer Laufzeit oder sehr niedriger Latenz.
• Leistungseinschränkungen: Bei serverlosen Funktionen kann es zu Kaltstarts (verzögerte erste Ausführung) kommen. Außerdem können die Ausführungszeit und der Arbeitsspeicher begrenzt sein.
• Anbieterabhängigkeit: Die Migration serverloser Anwendungen zwischen Cloud-Anbietern kann aufgrund von Unterschieden bei APIs und Konfigurationen komplex sein.
• Weniger Transparenz bei Servern: Entwickler haben nur begrenzten Einblick in die zugrunde liegende Infrastruktur. Das erschwert die Fehlersuche bei Leistungsproblemen oder die Optimierung der Ressourcennutzung.
• Langsamer Start: Bei serverlosen Funktionen kann es manchmal zu einem „Kaltstart“ kommen, bei dem die Funktion mit Verzögerung aufgerufen wird, was sich auf die Latenz auswirken kann.