Function as a Service Entwickeln für Serverless-Umgebungen

Wer vorrangig eine Anwendung coden und sie nicht zusätzlich orchestrieren möchte, entwickelt für Serverless. Doch der „Function as a Service“- oder kurz FaaS-Ansatz hat seine ganz eigenen Spielregeln und bricht mit dem klassischen DevOps-Gedanken.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Web-Anwendungen der „alten Schule“ setzen ein Server-Betriebssystem voraus. Ob auf Bare-Metal, in VMs oder in Containern: Die Orchestrierung von Servern geht immer ans Geld. Die Kosten der kontinuierlichen Ressourcenbereitstellung, der hohe Aufwand der Orchestrierung und die ganze rund-um-die-Uhr-Systemadministration machen es den Unternehmen zu schaffen.

Ein neuer Ansatz namens Serverless verspricht Abhilfe: geringere Betriebskosten und die Befreiung vom administrativen Overhead durch automatische Skalierbarkeit.

„Never Change a Running System“ versus gelebte Praxis

Im konventionellen Client-Server-Modell ist die Überprovisionierung eigentlich der Regelfall, denn nur so lässt sich der Kaltstart neuer Server-Instanzen verzögerungsfrei bewerkstelligen. Gleichzeitig muss die Infrastruktur aus Kostengründen bedarfsgerecht skalieren. Hinzu kommt ja auch noch die aufwändige Administration der Server in Code.

Softwareupdates, Security-Patches und dergleichen andere Aufgaben würden aber komplett entfallen, hätten die Entwickler nicht auch noch die lästige Infrastruktur zu verantworten. Hier kann ein einziger Fehlschritt zum Totalausfall der Anwendung führen. Der halbe Dampf geht in die Pfeife.

In größeren Unternehmen mögen ja die Tätigkeitsbereiche der Anwendungsentwicklung (Engl. Dev) und der Server-Administration bzw. -Orchestrierung (Engl. Ops) strikt voneinander getrennt sein. Das eine Team tüftelt an den Web-Anwendungen, das andere administriert zur Laufzeit die Infrastruktur. Auf dem Papier sieht die Arbeitsteilung ja auch sinnvoll aus.

In der Praxis kommen sich die beiden Teams aber unvermeidlich in die Quere. Ob diese Version einer Bibliothek oder jene, darüber besteht zwischen der Dev- und der Ops-Abteilung nur selten Übereinkunft. Die Grabenkämpfe sind hier „programmiert“.

Entwickler brauchen vorrangig eine zuverlässige, vorhersehbare Arbeitsumgebung. Getreu dem Motto „Never change a running system“ sollte sich der Betriebssystemunterbau möglichst wenig ändern. Aus Sicht eines Systemadministrators sind die Prioritäten genau anders herum. Um die Angriffsfläche durch Zero-Day-Exploits zu minimieren und die bestmögliche Systemperformance zu gewährleisten, müssen Updates und Patches möglichst zeitnah her.

In kleineren Unternehmen zeichnen Entwickler sowohl für den Code als auch für die Anwendungsbereitstellung verantwortlich. Anstatt ihre Aufmerksamkeit einzig und allein dem Code ihrer Anwendung zu widmen, müssen sie sich auch noch über die kontinuierliche Betriebsbereitschaft der Infrastruktur Gedanken machen. Je kleiner die Softwareschmiede, umso größer der Overhead. Ein innovativer Ansatz namens Serverless versprich, diese Ineffizienzen auszumerzen.

Radikal anders: ereignisgetriebene Skalierbarkeit in Funktionscode

Serverless Computing schafft eine Ausführungsumgebung für den so genannten Funktionscode (engl. „Function as a Service“, kurz: FaaS). Hierbei ist von vereinzelten Anweisungen die Rede, die an ein Cloud-Backend übermittelt werden und eine granulare Skalierbarkeit der Bereitstellung ermöglichen, ohne den Anwendungsentwickler damit zu behelligen.

Der FaaS-Anbieter orchestriert selbst die benötigten Compute-Instanzen und andere Ressourcen, um die Funktionsaufrufe auszuführen. Die Orchestrierung entzieht sich also der direkten Kontrolle der betreffenden Entwickler, der administrative Aufwand entfällt. So bleibt mehr Zeit für das Wesentliche: Das Entwickeln und Debuggen der geforderten Funktionalität.

Funktionscode ist ein radikaler Bruch mit dem klassischen DevOps-Paradigma. Die Vorteile sprechen aber für sich:

• Granulare Skalierbarkeit: Die kontinuierliche Dienstverfügbarkeit von Serverless garantiert eine ununterbrochene Betriebsbereitschaft der betreffenden Anwendungen mit automatischer Ressourcenprovisionierung.

• Niedrigere Kosten: Das Bereitstellungsmodell von Serverless sieht ein anweisungsgetriebenes Abrechnungsmodell vor. In der Praxis läuft es darauf hinaus, dass sich die Kosten strikt nach der tatsächlichen Belastung richten. Die passive Wartezeit im Stillstand reflektiert sich (im Unterschied zu PaaS und SaaS) nicht in der Abrechnung.

• Höhere Robustheit: Die strikt bedarfsgetriebene Bereitstellung von Serverless-Anwendungen erleichtert die selbstheilende Wiederherstellung der Dienste, in der Regel jedoch ohne Statuserhaltung.

So ist es auch kein Wunder, dass sich bei Serverless mittlerweile um die mit Abstand wachstumsstärkste Technologie der Public-Cloud handelt. RightScale konnte Serverless im vergangenen Jahr eine jährliche Wachstumsrate in Höhe von 75 Prozent nachweisen (2018 State of the Cloud Report). Für Softwareentwickler eröffnen sich damit neue Welten. Laut Googles Trendbarometer wächst die Anzahl der Suchanfragen zu Microservices und zu Serverless nahezu im Gleichschritt miteinander. Die Entwickler sind offenbar dabei, sich neu auszurichten.

Funktionscode für Serverless nicht ganz ohne

Bei den eingesetzten Compute-Instanzen der Ausführungsumgebung handelt es sich typischerweise um zustandslose, ephemerale Container. Für die Entwickler sind diese Instanzen aber nicht sichtbar. Der Entwickler kann nur Konstrukte verwenden, welche die avisierte FaaS-Umgebung unterstützt. Die Anwendung besteht aus Funktionsaufrufen; alle Abhängigkeiten verwaltet der FaaS-Anbieter im Backend seiner Plattform.

Klingt einfach? Nun ja, Serverless ist nicht ganz ohne. Mit der Umstellung auf dieses Modell der Anwendungsentwicklung muss nicht nur neuer Code her, sondern auch eine neue Denkweise.

Aus Kosten- und Skalierbarkeitsgründen erfolgt die Bereitstellung der Container beim FaaS-Anbieter strikt ereignisbezogen; sie lässt sich beispielsweise durch eingehende HTTP-Anfragen, bestimmte Datenbankereignisse, Warteschlangendienste, Überwachungsalarme, Dateiuploads, geplante Wartungsaufgaben auf der Systemebene (Cron-Jobs) u.ä. auslösen.

Zwar steht diesen Containern lokaler Speicher zur Verfügung, aber es besteht kein Anspruch auf seinen Fortbestand. Zudem kann der Anwendungsserver u.a. keinen Code ausführen, der einen bereits obsoleten Server-Kontext voraussetzt. Nichts davon erledigt sich von selbst.

Die Kosten der Ausführung von Code fallen pro Funktionsaufruf an. Ungetesteter, fehlerhafter, ineffizienter Funktionscode kann somit extrem teuer werden; und da er sich zur Laufzeit der Kontrolle des Entwicklers entzieht, kommt die Schattenseite der unbeschränkten Skalierbarkeit voll zur Geltung.

Wo mehrere Entwickler Funktionscode für separate Teile der Anwendung schreiben, können sich diese durch gegenseitig unkoordinierte Funktionsaufrufe leicht in die Quere kommen und an die (meist arbiträr gesetzten) Leistungsgrenzen der FaaS-Plattform stoßen. Anstatt zu skalieren, kommt dann alles zum Stillstand.

Um das Problem der Interdependenzen zu umgehen haben viele Unternehmen ihren gesamten Serverless-Code in einer einzigen Funktion am Laufen. So haben diese Nutzer von Serverless eigentlich das Gegenteil davon erreicht: eine monolithische Anwendung in Funktionscode. Sicherlich nicht im Sinne des Erfinders.

Herausforderungen der Cybersicherheit fallen beim Einsatz von Serverless leider nicht weg. Ganz im Gegenteil: Die Entwickler müssen hier die Verantwortung für ihre Anwendungen im Alleingang übernehmen. Dabei können Angriffe durchaus auch auf Providerebene auftreten.

Die meisten Sicherheitsvorfälle lassen sich auf …

• Dateninjektion bei Funktionsaufrufen,

• unzuverlässige Authentifizierungsmechanismen,

• zu liberal gewählte Berechtigungen (und Rollen) der Funktionsaufrufe,

• fehlendes Monitoring und Logging,

• Sicherheitslücken in fehlerhaft programmierten Code-Abhängigkeiten,

• unsichere Storage für Geheimdaten der Anwendung (applications secrets)

… und dergleichen zurückführen. Daher spielt die Wahl des Serverless-Frameworks und der FaaS-Ausführungsumgebung eine derart gewichtige Rolle.

Serverless-Frameworks, -IDEs und Ausführungsumgebungen für FaaS

Frameworks zur Entwicklung von Funktionscode gibt es mittlerweile einige. Die erfolgreichsten unterstützten mehrere Programmiersprachen und verschiedene Ausführungsumgebungen; einige sind vielseitig und portabel, andere proprietär und nischenhaft. Die Liste und Vielfalt wächst scheinbar tagtäglich:

• Serverless, der goldene Standard für Funktionscode

• SLAppForge, ein proprietäres Serverless-Framework der Enterprise-Klasse mit einer innovativen Cloud-IDE namens Sigma

• Riff, eine Lösung für Funktionscode u.a. Anwendungen auf Kubernetes

• Claudia.js, ein Serverless-Framework zur Entwicklung von Java-Script-Anwendungen für die Ausführung in Funktionscode

• Amplify Framework, ein Serverless-Backend von AWS für mobile Apps,

• Google App Engine, Googles FaaS-Umgebung

• Google Cloud Functions, darunter auch:

• Knative, eine Serverless-Umgebung für Kubernetes mit Support u.a. von Google und Red Hat

• Cloud Run, eine administrierte Compute-Plattform von Google zum automatischen Skalieren zustandsloser Container nach dem Serverless-Paradigma

• Apex, eine Lösung für Entwickler auf macOS, Linux und OpenBSD für die Ausführungsumgebung AWS Lambda

• Microsoft Azure Functions, Microsofts eigene Edition von FaaS

• AWS Lambda, ein Compute-Dienst von AWS für FaaS

• nuclio, eine Serverless-Plattform für Datenwissenschaft,

• Apache OpenWhisk, eine quelloffene Cloud-Plattform im Serverless-modell,

• PureSec, eine Sicherheitslösung für Serverless-Anwendungen,

• Oracle Cloud Infrastructure Events Service auf der Basis von CNCF, Serverless von Oracle.

Zu den leistungsstärksten der oben genannten zählt das Serverless Framework, eine Open Source-Lösung für ereignisgetriebene Anwendungen im Pay-per-Execution-Modell mit automatischer Skalierbarkeit. Der knackige Projektname „Serverless“ erweckt dabei vielleicht den Eindruck, als ob jemand hier das große Los gezogen haben mag und jetzt nichts dafür leisten müsste.

Glück mit dem Domainnamen hatte Serverless durchaus, von „unverdient“ kann jedoch nicht die Rede sein: Zehn Millionen Downloads, 163.425 wöchentliche Deployments und sagenhafte 31.985 Sterne bei Github sind eine stolze Leistung. Zu den renommiertesten Anwendern von Serverless.com zählen u.a. EA (Electronic Arts), The Coca Cola Company, Nordstrom, Expedia und die Reuters-Agentur.

Über einen Vendor-Lock-In brauchen sich die Anwendungsentwickler beim Serverless-Framework ebenfalls keine Sorgen zu machen. Mit AWS, Azure, Apache OpenWhisk, Google Cloud Platform (GCP), Kubeless, spotinst, fn und Cloudflare gibt es hier eine sehr breite Auswahl an wählbaren Infrastruktur-Providern.

Mit Serverless ziehen Anwendungsentwickler die sprichwörtlichen großen Kanonen. Es geht aber auch durchaus einfacher, zum Beispiel mit der (leider) proprietären Plattform SLAppForge (SLAppForge.com) und ihrer innovativen Cloud-IDE. Diese hört auf den Namen Sigma und ist selbst im wahrsten Sinne des Wortes „serverless“.

Im Normalfall müsste der Entwickler eine Menge an Dokumentation geistig verdauen; der Aufwand entfällt, da sich SLAppForge bemüht hat, die Komplexität zu beschränken: Mit Service-Entities, Zugriffsrichtlinien (access policies), Invokation-Trigger-Konfigurationen und assoziierten Zugriffsrechten und sogar mit der API-Invokation-Syntax brauchen sich die Entwickler in Sigma in der Regel nicht zu befassen.

Die Serverless-IDE läuft im Browser und nutzt Backend-Services für die Authentifizierung und Analytik. Den Browser starten, einloggen und schon kann der Entwickler loslegen. Als Ausführungsumgebung kommen aber leider nur AWS und GCP in Frage. Sigma setzt also auf Simplizität. Das Ziel besteht hier darin, möglichst viel Funktionalität mit Drag-und-Drop zu erledigen, ohne in die Tiefen des Codes hinabsteigen zu müssen. Auch DynamoDB-Datenbank-Tabellen lassen sich rein visuell in das UI einbinden, welches in der AWS-Cloud laufen kann.

Sigma interagiert direkt mit der Serverless-Plattform und konfiguriert diese für den Entwickler anhand der passenden Credentials. Das kann durchaus Zeit sparen. Manuelle Eingriffe sind dennoch manchmal nicht zu vermeiden, aber zumindest möglich. Der Preis dieser Simplizität ist im Falle von SLAppForge ein hoher Grad an Vendor-Lock-in an den Eigentümer der Plattform.

Wer auf Simplizität einen hohen Wert legt, kann auch mit quelloffenen Frameworks wie Riff gut wegkommen. Das Project Riff umfasst ein leichtgewichtiges FaaS-Framework mit CLI-basierter Unterstützung für Knative, eine Middleware für Serverless-Workloads auf Kubernetes.

Schließlich gibt es auch Lösungen, die alte und neue Welten überbrücken. Mit Claudia.js können Entwickler ihre Node.js-basierten Projekte als ereignisgetriebene Microservices auf Lambda ausführen oder automatisch skalierbare Web-APIs über API Gateway bereitstellen. Die hohe Vielzahl möglicher Integrationen ermöglicht u.a. die Umsetzung von Multi-Plattform-Chatbots. Claudia automatisiert hierzu die Bereitstellung und Konfiguration und richtet alles automatisch ein. Der Workflow basiert auf NPM-Paketen; die Entwickler müssen sich mit Swagger nicht auseinandersetzen.

Cybersicherheit in der Edition Serverless

Zum Schutz von Serverless-Apps bieten sich Lösungen wie PureSec an, eine serverlose Sicherheitsplattform für Serverless-Apps. Die Serverless Security Platform von PureSec (kurz: SSP) kann die kontinuierliche Überwachung von Serverless-Applikationen im Hinblick auf die Cybersicherheit gewährleisten. Die Aufgabe besteht darin, nicht nur bekannte Bedrohungen, sondern auch ganz neue Gefahren abzuwenden. Hierbei kommt die verhaltensgesteuerte Schutzumgebung ins Spiel.

PureSec nennt es die Behavioral Protection Engine. Diese schützt die Serverless-Ausführungsumgebung, indem sie eine Art Sicherheitsnetz zwischen den Serverless-Applikationen und der darunter liegenden Plattform zur Verfügung stellt und böswillige Angriffe und unerlaubte Zugriffe abblocken können soll. Der gesamte SSP-Prozess ist mit dem Prozess der kontinuierlichen Integration und Bereitstellung verbunden (siehe auch den Bericht „Cybersicherheit in Code: Wie sich DevOps zu DevSecOps entwickelt“).

Die Cloud Native Computing Foundation (kurz: CNCF) hat es sich zum Ziel gesetzt, eine herstelleragnostische Plattform bereitzustellen, auf der viele renommierte Open-Source-Projekte zuhause sind, darunter Kubernetes, Prometheus und Envoy. Die CNCF bringt die globale Entwicklergemeinde, Anwender und Anbieter zusammen, steckt auch hinter vielen Open-Source-Entwicklerkonferenzen und ist zudem Teil der gemeinnützigen Linux Foundation.

Auf der CNCF-Plattform läuft beispielsweise Oracles Cloud Infrastructure Events Service, ein Überwachungs- und Benachrichtigungsdienst des Softwareriesen. Nachdem sich das Unternehmen die Softwarerevolution in der Cloud praktisch verschlafen hatte, versucht es jetzt, die sprichwörtliche Flucht nach vorne ins Serverless-Zeitalter zu ergreifen.

Ob Oracle Functions Erfolg beschert sein wird, muss sich aber erst noch erweisen. Serverless als generelle IT-Richtung ist auf jeden Fall begrüßenswert. Ein Alleinstellungsmerkmal aber sicherlich nicht mehr. Denn die Liste der großen (und kleinen) IT-Player, die auf Serverless/FaaS setzen, liest sich wie das Who-is-Who der Softwareentwicklung.

Fazit

Die Wende hin zu Serverless ist eine Antwort auf den erbitterten Bürgerkrieg zwischen den Anwendungsentwicklern (Dev) und den Administratoren der Anwendungsbereitstellung (Ops), die sich in vielen Unternehmen gegenseitig im Wege stehen. Die Entwickler haben mit FaaS die Überhand gewonnen.

Serverless Computing mit Functions-as-a-Service (FaaS) schafft eine saubere Abstraktion des Anwendungscode von der Infrastruktur. Als Resultat daraus erhoffen sich die Entwicklerteams eine höhere Produktivität, niedrigere Kosten, granulare Skalierbarkeit, den Wegfall von administrativem Overhead — und damit die Freiheit, einfach „nur“ zu coden.

(ID:46150210)