Was ist Serverless?

Der Begriff „Serverless“ (serverlos) bezieht sich auf ein cloudnatives Entwicklungsmodell, bei dem Entwicklungsteams Anwendungen erstellen und ausführen können, ohne Server verwalten zu müssen. „Serverless“ bedeutet nicht, dass keine Server vorhanden sind. Es bedeutet, dass die Server von der Anwendungsentwicklung getrennt werden. Ein Cloud-Anbieter übernimmt die Routineaufgaben der Provisionierung, Verwaltung und Skalierung der Server-Infrastruktur. 

Mit Serverless können Entwicklungsteams ihren Code für das Deployment in Container paketieren. Einmal bereitgestellt, werden Serverless-Apps bedarfsabhängig ausgeführt und automatisch nach oben oder unten skaliert. Serverless-Lösungen von Public Cloud-Anbietern werden üblicherweise nach Bedarf unter Verwendung eines eventgesteuerten Ausführungsmodells berechnet. Das heißt, dass eine Serverless-Funktion erst dann etwas kostet, wenn sie tatsächlich benutzt wird.

Mehr über Red Hat OpenShift Serverless erfahren

Obwohl häufig synonym verwendet, handelt es sich bei Serverless Computing und Serverless-Architektur um unterschiedliche Konzepte. Serverless Computing bezieht sich auf das Modell der Anwendungsentwicklung, während sich Serverless-Architektur auf das Design-Konzept einer Anwendung bezieht. 

Serverless Computing 

Serverless Computing unterscheidet sich von anderen Cloud Computing-Modellen dahingehend, dass der Cloud-Anbieter sowohl für die Verwaltung der Cloud-Infrastruktur als auch für die Skalierung der Apps verantwortlich ist. Server werden nicht provisioniert und verwaltet. Stattdessen laufen Anwendungen auf automatisch verwalteten, von Cloud-Anbietern bereitgestellten Computing-Ressourcen. Serverless Computing ist eventgesteuert, skaliert automatisch und folgt in der Regel einem Pay as you go-Preismodell. Serverless-Apps werden in Containern bereitgestellt, die bei Bedarf automatisch aktiviert werden. 

Im Rahmen eines standardmäßigen IaaS-Modells (Infrastructure as a Service) für das Cloud Computing erwerben Nutzende eine bestimmte Kapazität. Im Klartext heißt das, Sie bezahlen einen Public Cloud-Anbieter für „Always-on“-Serverkomponenten, mit denen Sie Ihre Apps ausführen. Es bleibt den Nutzenden überlassen, in Zeiten mit hohem oder niedrigem Bedarf entsprechend nach oben oder unten zu skalieren. Dabei ist die zur Ausführung der Apps notwendige Cloud-Infrastruktur auch dann aktiv, wenn die Anwendungen nicht genutzt werden.

Arten von Serverless Computing

Serverless Computing lässt sich in mehrere Kategorien unterteilen:

• FaaS (Function as a Service): FaaS führt eventgesteuerte Funktionen in Kurzzeit-Containern aus. Die Verwaltung von Serverinstanzen entfällt, und die Ausführung erfolgt nur bei Auslösung.
• BaaS (Backend as a Service): BaaS bietet vollständig gemanagte Backend-Services, die Authentifizierung, Datenbanken, Messaging und Storage handhaben. Dieser Ansatz wird häufig in Mobil- und Webanwendungen genutzt.
• Serverless-Datenbanken: Serverless-Datenbanken werden automatisch skaliert und erfordern kein Infrastrukturmanagement.
• Serverless-Container: Serverless-Container werden ohne manuelle Provisionierung ausgeführt und dynamisch skaliert.
• Serverless Edge Computing: Serverless Edge Computing führt Codes näher an Nutzenden aus, um die Latenz zu reduzieren.

Serverless-Architektur

Der Begriff Serverless-Architektur beschreibt ein Design-Konzept, bei dem Apps ausschließlich nach Bedarf ausgeführt werden. Wenn ein App-Code durch ein Ereignis ausgelöst wird, weist der Public Cloud-Anbieter dafür Ressourcen zu. Wird der Code nicht mehr ausgeführt, fallen auch keine Kosten mehr an. Das Serverless-Modell befreit Entwicklungsteams außerdem von den Aufgaben der Anwendungsskalierung und Serverprovisionierung. Für Routineaufgaben wie die Verwaltung von Betriebs- und Dateisystem, Sicherheits-Patches, Load Balancing und Kapazitätsmanagement ist der Cloud-Serviceanbieter zuständig. Es ist möglich, eine komplett serverlose App oder eine Anwendung aus sowohl serverlosen als auch traditionellen Microservices-Komponenten zusammenzustellen.

Eine Serverless-Architektur, die Microservices-Komponenten verwendet, wird als Serverless Microservices bezeichnet. Mit Serverless Microservices ermöglicht die Serverless-Architektur den Entwicklungsteams das Schreiben von Code, während Microservices die Anwendung in kleinere, überschaubare Komponenten aufschlüsseln. Diese Kombination kann die Entwicklung und das Deployment beschleunigen. 

Vorteile

• Befreiung von Aufgaben zur Serververwaltung: Da die Notwendigkeit einer Provisionierung, Wartung oder Skalierung von Servern entfällt, haben Entwicklungsteams mehr Zeit, sich auf ihre Apps zu konzentrieren.
• Kosteneffizienz: Mit einem nutzungsbasierten Preismodell bezahlen Sie nur für die tatsächliche Ausführungszeit von Funktionen und senken auf diese Weise die Kosten für nicht genutzte Ressourcen.
• Schnellere Entwicklung und Bereitstellung: Dank reduziertem Infrastrukturmanagement und Deployments, die nur ein minimales Setup erfordern, steigt die Produktivität der Entwicklungsteams.
• Automatische Skalierung: Funktionen und Services werden nach oben oder unten skaliert.
• Integrierte Sicherheit: Sicherheits-Updates und -Patches werden vom Anbieter gemanagt. Dies verringert die Risiken im Zusammenhang mit fehlerhaft konfigurierten Servern.

Nachteile

• Komplexität in der Architektur: Eventgesteuerte Workflows können komplex werden, wenn mehrere Funktionen asynchron interagieren.
• Beschränkungen bei Interaktionen: Cloud-Anbieter schränken möglicherweise die Art und Weise ein, wie Sie ihre Komponenten nutzen können, und reduzieren damit Ihre Flexibilität.
• Vendor Lock-in: Serverless-Services, die eng in Ökosysteme von Cloud-Anbietern integriert sind, können eine Migration erschweren.

Welche Use Cases für Serverless gibt es?

Die Serverless-Architektur eignet sich am besten für asynchrone zustandslose Apps, die unmittelbar gestartet werden können. Gleiches gilt für Use Cases mit unregelmäßigen, unvorhersehbaren Bedarfsspitzen.

Das könnte beispielsweise die Batch-Verarbeitung großer eingehender Dateien sein, die vermutlich unregelmäßig stattfindet, aber stets bereit sein muss, wenn gleichzeitig eine Vielzahl an Images eingeht. Oder die Überwachung von eingehenden Änderungen in einer Datenbank und die darauf folgende Durchführung von verschiedenen Funktionen, um etwa diese Änderungen mit Qualitätsstandards abzugleichen oder sie automatisch zu übersetzen.

Serverless-Apps empfehlen sich außerdem für Use Cases mit eingehenden Daten-Streams, Chatbots, geplanten Aufgaben oder Geschäftslogik.

Weitere häufige Use Cases für Serverless sind Backend-APIs (Application Programming Interfaces) und Webanwendungen, die Automatisierung von Geschäftsprozessen, Serverless-Websites und Integration in mehrere Systeme.

In einem Serverless-Modell führt ein Cloud-Anbieter physische Server aus und weist die Ressourcen Nutzenden zu, die den Code direkt in der Produktivumgebung bereitstellen können.

FaaS, das gängigere Serverless-Modell, konzentriert sich auf ereignisgesteuerte Funktionen. Es ermöglicht Entwicklungsteams das Schreiben von spezifischer serverseitiger Logik, deren Bereitstellung in vollständig von Cloud-Serviceanbietern gemanagten Containern erfolgt. Diese Container sind: 

• zustandslos und ermöglichen eine einfachere Datenintegration
• flüchtig und können für kurze Zeit ausgeführt werden
• ereignisgesteuert mit automatischer Ausführung bei Bedarf
• vollständig gemanagt − Sie bezahlen nur für das, was Sie tatsächlich nutzen

Mit FaaS verfügen Entwicklungsteams über ein höheres Maß an Kontrolle und können Funktionen über APIs aufrufen, die vom Cloud-Anbieter durch ein API-Gateway gemanagt werden.

Große Cloud-Anbieter liefern FaaS-Lösungen, einschließlich AWS Lambda, Azure Functions, Google Cloud und IBM Cloud Functions. Einige Unternehmen nutzen Open Source-Plattformen wie Red Hat® OpenShift® Serverless (basierend auf Knative), um ihre eigenen FaaS-Umgebungen auszuführen.

Sie können FaaS mit BaaS − seinem Pendant für Backend-Services − kontrastieren, das Entwicklungsteams Zugang zu Drittanbieterservices wie Authentifizierung, Verschlüsselung und Datenbanken gewährt, und zwar in der Regel durch APIs. BaaS vereinfacht Backend-Aufgaben, bietet jedoch weniger Kontrolle über benutzerdefinierte Anwendungslogik.

Mehr über FaaS erfahren

Kubernetes ist eine beliebte Plattform für die Verwaltung containerisierter Apps, bietet jedoch keine native Unterstützung von Serverless-Workloads. Knative ist ein Open Source-Projekt, das die notwendigen Komponenten hinzufügt, um Serverless-Apps auf Kubernetes bereitzustellen, auszuführen und zu verwalten.

Knative ermöglicht Serverless-Umgebungen, indem es Ihnen das Deployment von Code auf Kubernetes-Plattform wie Red Hat OpenShift erlaubt. Mit Knative paketieren Sie Ihren Code als Image, und das System startet und stoppt Instanzen automatisch entsprechend dem Bedarf.

Knative umfasst 3 Hauptkomponenten:

• Build: konvertiert Quellcode in Container
• Serving: sorgt für die automatische Bereitstellung und Skalierung von Containern auf Basis des durch Anfragen gesteuerten Bedarfs
• Eventing: verwaltet Events aus verschiedenen Quellen, wie etwa Apps, Cloud-Services, SaaS-Systeme (Software as a Service) und Streams für Apache Kafka, um Funktionen auszulösen

Im Gegensatz zu traditionellen Serverless-Lösungen unterstützt Knative ein breites Spektrum an Workloads, von monolithischen Apps bis hin zu Microservices und kleinen Funktionen. Es kann auf einer beliebigen Kubernetes-fähigen Plattform inklusive On-Premise-Umgebungen ausgeführt werden.

Knative bietet entscheidende Vorteile, darunter:

• Unterstützte Microservices und Serverless-Workloads: Sie können ereignisgesteuerte, zustandslose Funktionen in Kubernetes bereitstellen. Sie können auch Microservices mit langer Ausführungszeit bereitstellen, die dynamisch skaliert werden, ohne dass eine manuelle Wartung von Serverinstanzen erforderlich ist.
• Optimierte Kosten und Ressourcennutzung: Im Gegensatz zu traditionellen Microservices, bei denen Pods möglicherweise permanent ausgeführt werden, unterstützt Knative die Scale-to-Zero-Funktion − wenn keine Anfragen eingehen, werden Ressourcen freigegeben und so die Kosten reduziert.
• Standardisierte APIs und Flexibilität: Knative folgt Kubernetes-nativen Patterns und kann mit mehreren Cloud-Anbietern arbeiten.

Indem Knative die Leistung von Serverless Computing in Kubernetes verlagert, vereinfacht es das Deployment und Management von Serverless-Workloads.

Entwickeln einer Serverless-Architektur mit Knative

Red Hat OpenShift Serverless hilft Ihnen, Serverless-Anwendungen schneller zu entwickeln und bereitzustellen, ohne dass Sie sich Gedanken über die Verwaltung von Infrastrukturdetails machen müssen.Damit wird eine unternehmensgerechte Serverless-Plattform bereitgestellt, die für Portierbarkeit und Konsistenz in Hybrid Cloud- und Multi Cloud-Umgebungen sorgt. 

Mit OpenShift Serverless können Entwicklungsteams cloudnative, quellenorientierte Anwendungen mit einer Reihe an CRDs (Custom Resource Definitions) und dazugehörigen Controllern in Kubernetes erstellen. Und für Operations-Teams bietet OpenShift Serverless ein vereinfachtes Erlebnis, denn es lässt sich im Handumdrehen auf Red Hat OpenShift installieren, wurde auf anderen Red Hat Produkten getestet und bietet vielfach ausgezeichneten Support. 

OpenShift Serverless stellt eine vollständig serverlose Lösung für Anwendungsentwicklung und -Deployment bereit, indem Apps mit anderen Services von Red Hat OpenShift Container Platform integriert werden, wie beispielsweise Red Hat OpenShift Service Mesh und Cluster-Überwachung. Damit steht den Entwicklungsteams eine zentrale Plattform für das Hosting ihrer Microservices sowie Legacy- und Serverless-Anwendungen zur Verfügung. Apps werden als Linux®-Container paketiert, die in beliebiger Umgebung ausführbar sind. 

Erstellen einer OpenShift Serverless-Funktion