Was ist Serverless?
Der Begriff „Serverless“ bezieht sich auf ein cloudnatives Entwicklungsmodell, bei dem Entwicklungsteams Anwendungen erstellen und ausführen können, ohne Server verwalten zu müssen. Serverless Computing ist eventgesteuert, skaliert automatisch und folgt in der Regel einem Pay as you go-Preismodell. Der Begriff „serverless Architektur“ beschreibt ein Design-Konzept, bei dem Apps ausschließlich nach Bedarf ausgeführt werden.
Bei Serverless verpacken Entwicklungsteams ihren Code in Containern für das Deployment. Nach der Bereitstellung reagieren serverless Anwendungen auf die Nachfrage und skalieren bei Bedarf automatisch vertikal. Serverless Lösungen von Public Cloud-Anbietern werden üblicherweise entsprechend der Nachfrage mit einem eventgesteuerten Ausführungsmodell berechnet. Das heißt, dass eine serverless Funktion erst dann etwas kostet, wenn sie tatsächlich benutzt wird.
„Serverless“ bedeutet nicht, dass keine Server vorhanden sind. Es bedeutet, dass die Server von der Anwendungsentwicklung getrennt sind. Ein Cloud-Anbieter übernimmt die Routineaufgaben der Provisionierung, Verwaltung und Skalierung der Server-Infrastruktur. 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.
Was ist der Unterschied zwischen Serverless Computing und serverless Architektur?
Serverless Computing bezieht sich auf das Modell der Anwendungsentwicklung, während sich serverless Architektur auf das Design-Konzept einer Anwendung bezieht. Obwohl häufig synonym verwendet, handelt es sich bei Serverless Computing und serverless Architektur um unterschiedliche Konzepte.
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 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 des Serverless Computing
Serverless Computing lässt sich in mehrere Kategorien unterteilen:
- Function as a Service (FaaS): FaaS führt eventgesteuerte Funktionen in Kurzzeit-Containern aus. Die Verwaltung von Serverinstanzen entfällt, und die Ausführung erfolgt nur bei Auslösung.
- Backend as a Service (BaaS): 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
Wenn ein App-Code durch ein Ereignis ausgelöst wird, weist der Public Cloud-Anbieter dafür Ressourcen zu. Wenn der Code nicht mehr ausgeführt wird, 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.
Red Hat Ressourcen
Was sind die Vor- und Nachteile von Serverless?
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 automatisch nach Bedarf vertikal 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.
- Interaktionsbeschränkungen: Cloud-Anbieter schränken möglicherweise die Art und Weise ein, wie Sie deren Komponenten nutzen können, wodurch Ihre Flexibilität reduziert wird.
- 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?
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.
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.
Was ist FaaS und die Rolle des Cloud-Anbieters?
Function as a Service (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.
Was ist Knative?
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-Plattformen 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-Systemen (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.
Warum Red Hat?
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.
15 Gründe für die Einführung von Red Hat OpenShift Virtualization
Erfahren Sie, wie Red Hat OpenShift Virtualization Ihre IT-Abläufe mit einer Plattform für virtuelle Maschinen und Container vereinheitlichen und vereinfachen kann.