Author: Kevin Duss

Gartner identifiziert Serverless als einen der bedeutendsten Technologietrends im Jahr 2022. Während die meisten unserer Kunden Platform as a Service (PaaS) anwenden, besteht bei Serverless noch ungenutztes Potenzial.

Das neue Serverless

Serverless hat ursprünglich Webapplikationen und Mobile Apps beschrieben, deren serverseitige Logik aus Cloud-Services von Drittanbietern zusammengesetzt ist. Typische Beispiele solcher Services sind Datenbanken und Authentifizierungsdienste. Diese Art von Service nennt sich Backend as a Service (BaaS). Serverless beschreibt auch Applikationen, deren serverseitige Logik von Kunden selbst als Functions implementiert, aber von Cloud-Anbietern verwaltet wird. Diese Art von Service nennt sich Function as a Service (FaaS). In diesem Beitrag liegt der Fokus auf FaaS, dem neueren Bereich von Serverless. Viele betriebliche Aspekte von FaaS, wie die Ressourcenverwaltung, treffen jedoch auch auf BaaS zu.

Functions und ihre Besonderheiten

Functions sind kurzlebig. Cloud-Anbieter erstellen und zerstören FaaS-Container basierend auf dem Laufzeitbedarf. Cloud-Anbieter sind gänzlich dafür verantwortlich, Ressourcen bereitzustellen, zuzuweisen und zu skalieren. Darin manifestieren sich die Hauptunterschiede von FaaS zu anderen Modellen wie PaaS: User müssen Cluster weder selbst aufbauen noch verwalten und Functions laufen nicht durchgehend. Letzteres ist nur aufgrund der Prämisse möglich, dass Functions zustandslos sind. Genauer gesagt wird deren Zustand externalisiert und beispielsweise in einer Datenbank persistiert.

Neben der Zustandslosigkeit muss bei der Entwicklung von Functions auf deren Ausführungszeit und Latenzzeit beim Start geachtet werden. Ausführungszeiten von Functions werden von Cloud-Anbietern beschränkt. Die zeitliche Beschränkung liegt typischerweise bei rund 10 Minuten. Startzeiten sind ausschlaggebend dafür, wie schnell Functions aufstarten, skalieren und Events abarbeiten können. Die Startzeit einer Function ist insbesondere wichtig bei «Cold Starts», wenn keine Instanz der Function wiederverwendet werden kann. In solchen Fällen muss der Cloud-Anbieter zuerst einen neuen Container und Prozess starten, bevor die Function mit der Arbeit loslegen kann.

Die genannten Vorteile bedeuten keineswegs, dass FaaS anderen Modellen grundsätzlich überlegen ist. Der Nutzen von FaaS entfaltet sich insbesondere bei Event-driven Architekturen mit homogenen Events und Applikationen mit hohen Lastspitzen. Für Request-driven Architekturen mit vielen Einstiegspunkten kann es angemessener sein, eigene Container bereitzustellen (z.B. mittels PaaS). Der Beitrag Cloud-Native! Aber wie? Container vs. Serverless bietet einen Direktvergleich zwischen Functions und Container-Technologien.

Event-driven unterscheiden sich von Request-driven Architekturen in der Art und Weise, wie Services aufgerufen werden. Services in Event-driven Architekturen bedienen nicht synchrone Requests von Usern oder Applikationen, sondern reagieren auf Events. Events bilden Zustandswechsel ab. Eine Architektur kann beispielsweise den Verkauf eines Produkts als Event vorsehen. Durch die asynchrone Natur von Events lassen sich Komponenten lose koppeln. Dies führt zu Architekturen, die sich ausgezeichnet für Functions eignen.

Umgang mit Vendor Lock-in

Unterschiedliche Cloud-Anbieter haben ihre (Serverless-)Angebote unterschiedlich implementiert. Ein Anbieterwechsel hat daher Auswirkungen auf die eingesetzten Betriebsinstrumente und den Code. Die grösste Herausforderung liegt gegebenenfalls nicht in der Migration eines Service an sich, sondern in dessen Integration mit bestehenden Services. Beispielsweise kann eine Function direkt vom Messaging-Service desselben Anbieters getriggert werden. Soll der Messaging-Service jedoch die Function zukünftig bei einem anderen Anbieter triggern, ist zusätzlicher Integrationsaufwand gefordert. Dieser Vendor Lock-in ist ein Risiko für Unternehmen.

Verschiedene Open Source-Frameworks haben dieses Risiko erkannt. Sie befähigen Entwicklerinnen und Entwickler, Functions über Cloud-Anbieter hinweg bereitzustellen. Zwei Beispiele sind das Serverless Framework und Spring Cloud Function:

Das Serverless Framework erlaubt die Definition der benötigten Infrastruktur, wie Datenbanken oder API-Gateways, via Code (vergleichbar mit Terraform). Die einheitliche Konfiguration mit YAML-Dateien bewahrt Entwicklerinnen und Entwickler davor, die Konfigurationsdetails der verschiedenen Cloud-Anbieter kennen zu müssen. So kann eine Function und deren benötigte Infrastruktur bei mehreren Cloud-Anbietern bereitgestellt werden.

Spring Cloud Function ermöglicht die Cloud-agnostische Entwicklung von Functions durch eine Palette von Adaptern. Diese Adapter abstrahieren die Eigenheiten verschiedener Serverless-Implementationen. Soll Code von einem Anbieter zum anderen migriert werden, muss so die Logik in der betroffenen Function nicht angefasst werden. Das Austauschen des Adapters reicht aus.

Die Nutzung solcher Frameworks hilft, den Vendor Lock-in zu lockern. Abhängigkeiten bleiben jedoch bestehen, falls innerhalb der Functions anbieterspezifische Services verwendet werden. Zudem kann dieser Ansatz zu neuen Abhängigkeiten gegenüber Frameworks führen. Ist hingegen Spring Boot bereits Teil des Entwicklungs-Stacks, kann Spring Cloud Function Entwicklerinnen und Entwicklern den Zugang zur Serverless-Welt erleichtern.

Fazit

• Trends der Cloud-nativen Softwareentwicklung zeigen in Richtung FaaS.
• Bei der Entwicklung von Functions muss auf Aspekte wie Zustandslosigkeit sowie Start- und Ausführungszeiten geachtet werden.
• FaaS soll Modelle wie PaaS nicht ablösen, sondern ergänzen.
• Bei richtiger Anwendung ist FaaS günstig im Betrieb, effizient in der Ressourcennutzung und schnell in der Entwicklung.
• FaaS birgt das Risiko des Vendor Lock-ins. Der Einsatz von Open Source-Frameworks kann dieses Risiko durch Abstraktion vermindern.