Was ist Serverless?

Der Begriff „Serverless" (serverlos) bezieht sich auf ein cloudnatives Entwicklungsmodell, bei dem Entwickler Anwendungen erstellen und ausführen können, ohne Server verwalten zu müssen.

Natürlich sind die Server noch physisch vorhanden, nur wurden sie von der App-Entwicklung getrennt. Ein Cloud-Anbieter übernimmt die Routineaufgaben der Provisionierung, Verwaltung und Skalierung der Serverinfrastruktur. Die Entwickler müssen zur Bereitstellung lediglich den Code in Container paketieren.

Einmal bereitgestellt, werden Serverless-Apps bedarfsabhängig ausgeführt und können automatisch nach oben oder unten skaliert werden. Serverless-Lösungen von Public Cloud-Anbietern werden üblicherweise entsprechend der Nachfrage über ein ereignisgesteuertes Ausführungsmodell berechnet. Das heißt, dass eine Serverless-Funktion erst dann etwas kostet, wenn sie tatsächlich benutzt wird.

Serverless-Modelle unterscheiden sich vom Cloud Computing dahingehend, dass der Cloud-Anbieter sowohl für die Verwaltung der Cloud-Infrastruktur als auch die Skalierung der Apps verantwortlich ist. Serverless-Apps werden in Containern bereitgestellt, die bei Bedarf automatisch aktiviert werden.

Im Rahmen eines standardmäßigen IaaS-Modells für das Cloud Computing erwirbt der Nutzer 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 dem Nutzer ü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.

Bei einem Serverless-Modell hingegen werden Apps nur bei Bedarf ausgeführt. Wenn ein App-Code durch ein Ereignis ausgelöst wird, weist der Public Cloud-Anbieter dafür dynamisch Ressourcen zu. Wenn der Code nicht mehr ausgeführt wird, fallen auch keine Kosten mehr an. Neben den Kosten- und Effizienzvorteilen befreit das serverlose Modell den Entwickler von den wiederkehrenden Aufgaben der Anwendungsskalierung und Serverprovisionierung.

Beim Serverless-Prinzip ist für Routineaufgaben (wie die Verwaltung von Betriebs- und Dateisystem, Sicherheits-Patches, Load Balancing, Kapazitätsmanagement, Skalierung, Protokollierung und Überwachung) der Cloud Service-Anbieter zuständig.

Es ist möglich, eine komplett serverlose App oder eine Anwendung aus teils serverlosen, teils traditionellen Microservice-Komponenten zusammenzustellen.

Er führt die physischen Server aus und weist die Ressourcen den Nutzern dynamisch zu, die den Code direkt in der Produktivumgebung bereitstellen können.

Serverless Computing-Lösungen unterteilen sich in zwei Gruppen: BaaS (Backend-as-a-Service) und FaaS (Function-as-a-Service).  

BaaS ermöglicht dem Entwickler Zugriff auf eine Vielzahl an Drittanbieter-Services und -Apps. So könnte ein Cloud-Anbieter z. B. Authentifizierungs-Services, zusätzliche Verschlüsselung, per Cloud zugängliche Datenbanken sowie wiedergabetreue Nutzungsdaten bereitstellen. Beim BaaS-Modell werden Serverless-Funktionen normalerweise über APIs aufgerufen.

Häufig ist es so, dass die meisten Entwickler mit Serverless eigentlich das FaaS-Modell meinen. Bei diesem Ansatz schreibt der Entwickler die spezifische serverseitige Logik, aber ausgeführt wird diese in Containern, die zu 100 % von Cloud Service-Anbietern verwaltet werden. 

Die wichtigsten unter ihnen bieten eine oder mehrere FaaS-Lösungen an. Dazu gehören unter anderem Amazon Web Services mit AWS Lambda, Microsoft Azure mit Azure Functions, Google Cloud mit mehreren Varianten und IBM Cloud mit IBM Cloud Functions. 

Manche Organisationen bevorzugen ihre eigenen FaaS-Umgebungen mit auf Open Source basierenden Serverless-Plattformen wie Red Hat® OpenShift® Serverless, das auf dem Knative-Projekt für Kubernetes basiert.

FaaS (Function-as-a-Service) ist ein event-gesteuertes Ausführungsmodell mit einer von Entwicklern geschriebenen Logik. Die Logik wird in Containern bereitgestellt, die komplett von einer Plattform verwaltet und nach Bedarf ausgeführt werden.

Im Gegensatz zu BaaS bietet FaaS den Entwicklern mehr Kontrolle, denn sie können benutzerdefinierte Apps erstellen und sind nicht von einer Library vordefinierter Services abhängig. 

Code wird in Containern bereitgestellt, die wiederum von einem Cloud-Anbieter verwaltet werden. Diese Container sind im Besonderen:

• Zustandslos und ermöglichen eine einfachere Datenintegration
• Flüchtig und können für kurze Zeit ausgeführt werden
• Event-orientiert und können bei Bedarf automatisch ausgeführt werden
• Komplett gemanagt von einem Cloud-Anbieter, damit Sie nur für das zahlen, was Sie brauchen, und nicht für „Always-on"-Anwendungen und -Server

Mithilfe von FaaS können Entwickler Serverless-Apps per API aufrufen, die vom FaaS-Anbieter über ein API Gateway gehandhabt werden.

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, Chat Bots, geplanten Aufgaben oder Geschäftslogik.

Weitere Use Cases sind Backend-APIs und Web-Apps, Business Process Automation, Serverless Websites und die Integration in mehreren Systemen.

Die Kubernetes-Plattform zur Container-Orchestrierung ermöglicht die Ausführung containerisierter Apps auf einer automatisierten Infrastruktur und ist nicht zuletzt deswegen eine beliebte Wahl für Serverless-Umgebungen. Kubernetes aber ist von Hause aus nicht für die native Ausführung von Serverless-Apps konfiguriert.

Knative ist ein Open Source Community-Projekt, mit dem Komponenten hinzugefügt werden, um Serverless Apps bereitstellen, ausführen und verwalten zu können.

Die serverlose Knative-Umgebung ermöglicht die Bereitstellung von Code auf einer Kubernetes-Plattform wie Red Hat OpenShift. Dazu können Sie mit Knative Services erstellen, indem Sie Ihren Code als Container Image paketieren und dieses ans System übergeben. Ihr Code wird nur wenn nötig ausgeführt, die Instanzen werden von Knative automatisch gestartet und gestoppt.

Knative besteht aus drei Hauptkomponenten:

• Build: ein flexibler Ansatz zur Entwicklung von Quellcode in Containern
• Serving: ermöglicht die schnelle Bereitstellung und automatische Skalierung von Containern über ein anfragegesteuertes Modell, das Workloads nach Bedarf bereitstellt
• Eventing: eine Infrastruktur, die Events verbraucht und produziert, um Apps auszulösen. Anwendungen können von ganz unterschiedlichen Quellen ausgelöst werden, z. B. von Events Ihrer eigenen Anwendungen, von Cloud Services verschiedener Anbieter, von SaaS-Systemen und Red Hat AMQ Streams.

Im Gegensatz zu älteren Serverless-Frameworks wurde Knative dazu entwickelt, beliebige moderne App-Workloads bereitzustellen, und zwar von monolithischen Anwendungen bis hin zu Microservices und Minifunktionen.

Knative ist eine Alternative zu einer FaaS-Lösung, die nur von einem Service-Anbieter gesteuert wird, und kann auf allen Cloud-Plattformen verwendet werden, auf denen Kubernetes ausgeführt wird. Dazu gehört auch die Ausführung in einem On-Premise Rechenzentrum. Auf diese Weise können Organisationen ihre Serverless-Workloads agiler und flexibler ausführen.

Vorteile:

• Es sorgt für höhere Entwicklerproduktivität und geringere Betriebskosten. Da die Entwickler nun keine Zeit mehr für Routineaufgaben (wie die Provisionierung und Verwaltung von Servern) aufwenden müssen, können sie sich vermehrt auf ihre Apps konzentrieren. 
• Serverless fördert die Umstellung auf DevOps. Denn die Entwickler müssen die Infrastruktur, die das Operations-Team für sie provisionieren muss, nicht mehr so häufig explizit beschreiben.  
• Die App-Entwicklung lässt sich noch weiter optimieren, und zwar indem Sie ganze Komponenten von externen BaaS-Anbietern integrieren.
• Das serverlose Modell spart Betriebskosten, weil Sie bei der Nutzung cloudbasierter Computing-Zeit einem „Pay as you go"-Modell folgen und nicht Ihre eigenen Server rund um die Uhr ausführen und verwalten müssen.

Nachteile:

• Es kann auch Nachteile haben, wenn Sie Ihren eigenen Server nicht selbst ausführen und Ihre eigene serverseitige Logik nicht selbst kontrollieren.
• Cloud-Anbieter haben möglicherweise strikte Beschränkungen in Bezug auf Interaktionen mit ihren Komponenten, was wiederum die Flexibilität und Definition Ihrer eigenen Systeme beeinflussen kann. So kann es sein, dass Entwickler im Falle von BaaS-Umgebungen von Services abhängig sind, deren Code sie nicht bearbeiten können.
• Und wenn Sie diese Aspekte Ihres IT Stacks nicht mehr kontrollieren können, führt Sie dies eventuell in einen Vendor Lock-in. Denn ein Anbieterwechsel würde womöglich Kosten für Systemupgrades mit sich bringen, die Sie aus Gründen der Konformität mit den neuen Händlerspezifikationen durchführen müssten.

Die Serverless- und FaaS-Konzepte haben sich gemeinsam mit der steigenden Beliebtheit von Containern und On-Demand-Cloud-Angeboten entwickelt. In einem zusammen mit Red Hat erstellten Bericht hat 451 Research die Serverless-Evolution in drei Phasen eingeteilt.

Die Phase „1.0" wurde von Einschränkungen begleitet, die Serverless für das allgemeine Computing nicht gerade ideal machten. Serverless 1.0 zeichnet sich durch Folgendes aus:

• HTTP und wenige weitere Ressourcen
• Nur Funktionen
• Begrenzte Ausführungszeit (5–10 Minuten)
• Keine Orchestrierung
• Beschränkte lokale Entwicklererfahrung

Das Aufkommen von Kubernetes läutete die Phase „Serverless 1.5" ein, wo Container mithilfe von zahlreichen Serverless-Frameworks vermehrt automatisch skaliert wurden. Serverless 1.5 zeichnet sich durch Folgendes aus:

• Knative
• Kubernetes-basierte Autoskalierung
• Microservices und Funktionen
• Einfaches Debugging und lokales Testen
• Mehrsprachig und portabel

Das aktuelle „Serverless 2.0" hat Integrations- und Zustandsfunktionen mit sich gebracht. So haben die Anbieter mittlerweile die fehlenden Komponenten integriert, weswegen Serverless jetzt für generische geschäftliche Workloads geeignet ist. Serverless 2.0 zeichnet sich durch Folgendes aus:

• Grundlegende Handhabung von Zuständen
• Einsatz von Enterprise Integration Patterns
• Erweiterte Messaging-Funktionen
• Kombination mit unternehmensfähigem PaaS
• Unternehmensfähige Event-Quellen
• Zustand und Integration