Serverless: Mit mehr Vielfalt zu mehr Möglichkeiten
Die Nutzung von Serverless-Technologien in Unternehmen nimmt weiter Fahrt auf, wie der Report "The State of Serverless" zeigt. Mehr Vielfalt im Angebot führt zu mehr Möglichkeiten im Daily Business, wobei sich Serverless und container-basierte Technologien immer stärker überschneiden.
Statt sich mit dem Aufbau einer Infrastruktur zu beschäftigen, können Unternehmen mit Serverless schneller Ideen ausprobieren und auf den Markt bringen. Die jeweilige Cloud-Plattform übernimmt die Bereitstellung der Ressourcen und kümmert sich um deren Logistik, was der Entwicklung mehr Zeit gibt, sich abseits von hardwarespezifischen Fragen stärker auf fachliche Aufgaben zu fokussieren. Aber in welchem Umfang werden diese Technologien inzwischen im Unternehmensumfeld adaptiert?
Das Interesse an Serverless ist deutlich gewachsen
Für den Report wurden die Telemetriedaten tausender Serverless-Applikationen im eigenen Netzwerk ausgewertet, um ein aktuelles Bild von der konkreten Nutzung im Unternehmensumfeld zu entwerfen. Es zeigt sich, dass mehr als jedes zweite Unternehmen, das auf die großen Cloud-Provider AWS, Google Cloud und Azure setzt, auch Serverless-Technologie nutzt.
Das Interesse und die Verbreitung von Serverless sind somit weiter gewachsen. Organisationen nutzen die Plattformen nicht nur zur Ausführung von ereignisgesteuertem Code. Wie die Telemetriedaten zeigen, stellen sie auch containerisierte Anwendungen auf serverlosen Plattformen wie Azure Container Instances, Google Cloud Run oder ECS Fargate bereit.
Google Cloud: FaaS und Containerisierung gleich auf
Google Cloud Functions wird von den Unternehmen in der Google Cloud am häufigsten verwendet. In den vergangenen Jahren hat dieses FaaS-Angebot ("Function as a Service") auch die stärksten Zuwachsraten gehabt. Das Thema der Containerisierung ohne Infrastrukturmanagement ist für die Firmen nahezu genauso wichtig und wird entsprechend eingesetzt. Google Cloud Run, das Serverless-Container-Produkt von Google, liegt allerdings nur wenige Prozentpunkte hinter Google Functions.
Das deutet darauf hin, dass sich Unternehmen gezielt in Abhängigkeit des Workloads zwischen den beiden Ansätzen entscheiden. Bei Cloud Functions laden die Entwickler ein Code-Bundle hoch, das in einer Runtime abläuft. Um die Einrichtung von Instanzen müssen sich die Entwickler nicht kümmern. Die Besonderheit: Jede Instanz verarbeitet jeweils parallel nur ein Event, das die Funktion dann auslöst. Cloud Run führt dagegen hochgeladene Container in den Instanzen aus. Die verschiedenen Instanzen können mehrere parallele Requests via HTTP verarbeiten – ein Vorteil beim Einsatz von RESTful-APIs und großen Arbeitslasten. Mit Cloud Run können so auch Legacy-Container einfach hochgeladen werden, um sie dort dann etwa als Microservices bereitzustellen.
Die Migration von Legacy-Code in Richtung Google Functions gestaltet sich dagegen aufwändiger, weil eine bestehende Anwendung erst auf separate Dienste aufgeteilt werden muss und zudem zusätzliche Event-Handler entwickelt werden müssen.
Azure-Nutzer scheuen den Kaltstart
Der Report hat ein interessantes Detail bei der Verwendung von FaaS herausgearbeitet. So bietet Azure Functions einen ausschließlich verbrauchsbasierten Plan, der mittels Autoscaling bei höheren Workloads nach oben skaliert. Ein zweischneidiges Schwert: Denn wenn keine Ereignisse und Ausführungen im Verbrauchsplan stattfinden, wird die App möglicherweise auf Null-Instanzen heruntergefahren. Die größere Kostenkontrolle hat also den Nachteil, dass es zu einem "Kaltstart" und damit Latenz kommen kann, weil erst eine neue Instanz aufgerufen werden muss. Genau das wollen die Unternehmen hier offenbar vermeiden, denn mehr als die Hälfte der Unternehmen nutzt die Option, vorgewärmte Instanzen (Prewarmed Workers) einzusetzen. Da diese kontinuierlich laufen, reduziert sich das Risiko des Kaltstarts.
Die Entscheidung für "prewarmed" Instanzen liegt ohnehin für alle Organisationen nahe, die bereits Anwendungen auf virtuellen Maschinen in Azure hosten, da diese oft über freie Rechenressourcen verfügen, die dann zur Ausführung von Funktionen genutzt werden können. Die unbegrenzte Ausführungszeit stellt somit sicher, dass die Funktionen permanent reaktionsfähig sind und daher größere Workloads ohne Zeitverlust verarbeitet werden können.
AWS Lambda zeigt Durchmarsch der API-Economy
Der Datenverarbeitungsservice Lambda gehört weiterhin zu den populärsten Teilen des AWS-Angebots. Die aus den Monitoring-Anwendungen gewonnenen Telemetriedaten zeigen, dass über die Hälfte der Funktionsaufrufe in Lambda aus API-Gateways stammen. Die Zahlen unterstreichen somit die ohnehin bereits gefühlte Bedeutung von APIs in der modernen Softwarentwicklung. Man denke hier nur an den Fintech- und Insurtech-Sektor, der seine Geschäftsmodelle teilweise ausschließlich entlang von APIs entwickelt (Stichwort "Banking as a Service").
Der zweithäufigste AWS-Service zum Aufrufen von Lambda-Funktionen ist Amazon Simple Queue Service (SQS). SQS wird häufig dazu genutzt, Microservices zu entkoppeln und eine asynchrone Kommunikation zwischen ihnen zu implementieren. In der Kombination zwischen API-Gateway und AWS Lambda fällt zudem auf, dass 80 Prozent der Lambda-Aufrufe, die via API-Gateway erfolgen, auf zweckgebundene Funktionen verweisen. Sie reagieren auf Ereignisse, die von einem einzelnen Endpunkt ausgehen. Die Isolierung der Funktionen erleichtert das Debugging und vereinfacht die Absicherung der Anwendungen, da über das AWS Identity and Access Management (IAM) jeder Funktion eine Rolle zugewiesen werden kann. Aufgrund einer kleineren Paketgröße sind sie zudem schneller am Start. Offenbar adaptieren Entwickler diese Vorteile.
Die Popularität dieser Single-Functions ist etwas überraschend, weil damit im Gegensatz zu monolithischen Lambda-Funktionen ein höherer Aufwand bei der Implementierung verbunden ist. Dies nehmen die Teams offenbar gern in Kauf, um von der größeren Granularität zu profitieren.
Größere Vielfalt bei den Programmiersprachen
Die größere Zahl an Wahlmöglichkeiten bei Serverless-Technologien spiegelt sich auch beim Einsatz der verwendeten Programmiersprachen wider. Python, Node.js, Java und Go dominieren das Bild. Allerdings kommen auch weitere Sprachen zum Einsatz. Es gibt also keinen einheitlichen Ansatz für die Erstellung von serverlosen Anwendungen. Es scheint somit nicht so zu sein, dass die Unternehmen in erster Linie auf die Sprachen zurückgreifen, mit denen die Entwickler bereits größere Erfahrungen gesammelt haben. So ist Java im Unternehmensumfeld zwar stark verbreitet, laut Auswertungen aber nur eine der möglichen Lösungen.
Python, Node.js, Java und Go dominieren das Bild.
Sechs von zehn Organisationen, die mehr als 100 Lambda-Funktionen ausführen, haben diese in drei oder mehr Programiersprachen implementiert. Es wird somit je nach Anwendungsfall und Workload entschieden, welches Werkzeug zum Einsatz kommt. So würde sich Go etwa für Anwendungen im Bereich Datenkompression oder Videostreaming anbieten, weil die enthaltenen Routinen besonders für Arbeitslasten geeignet sind, in denen es auf die parallele Ausführung ankommt.
Lambda-Nutzer nutzen gern die Containerisierung
Als AWS Lambda-Functions ausrollte, wurden lediglich ZIP-Archive mit einer Größenbeschränkung von 250 MB akzeptiert. Die ZIP-Dateien mussten den Code und alle Abhängigkeiten enthalten. Das wurde Anfang 2020 geändert. Jetzt lassen sich AWS Lambda-Funktionen auch als Docker-Container bereitstellen. Wie die Auswertungen zeigen, wächst seitdem das Interesse an dieser Methode kontinuierlich an. Rund 20 Prozent der Organisationen, die Lambda-Functions einsetzen, bevorzugen inzwischen diesen Weg.
Einer der wesentlichen Vorteile, den immer mehr Organisationen entdecken, ist ohne Zweifel das größere Limit von bis zu 10 GB für die Container-Images. Damit können diese ohne größere Probleme auch Bibliotheken wie NumPy oder PyTorch aufnehmen, die viele Abhängigkeiten besitzen, aber für KI-Projekte wie Datenanalysen oder maschinelles Lernen die Basis bilden. Was ebenfalls zu einer stärkeren Adaption der Paketierung als Container-Images beitragen dürfte, ist die Tatsache, dass sie sich in bestehende Arbeitsabläufe gut einfügt. Organisationen, die ohnehin Pipelines für die Bereitstellung von Docker-Images aufgebaut haben, sind damit in der Lage, serverlose Funktionen einfacher zu integrieren. Das spart Zeit und steigert die Produktivität.
Lambda-Nutzer setzen verstärkt auch auf Fargate
Mit der Beliebtheit von AWS Lambda geht auch eine stärkere Nutzung von ECS Fargate einher. Von den im Report erfassten Organisationen, die Lambda einsetzen, verwenden inzwischen 20 Prozent auch ECS Fargate. Sie können damit Container starten, ohne sich um die Verwaltung und Bereitstellung von EC2-Instanzen zu kümmern. Dies deutet darauf hin, dass die Unternehmen die Vorteile von Fargate – etwa die genauere Kontrolle über die Zuweisung von Ressourcen – nutzen wollen, um Workloads, die viele Ressourcen benötigen, weiter zu optimieren.
Serverless wird erwachsen – Monitoring und Security mitdenken
Der aktuelle Report unterstreicht die gewachsene Bedeutung von Serverless-Computing für Unternehmen, wobei es nicht einfach nur um den Ersatz klassischer Hardware durch die Cloud geht. Gerade das Deployment von containerisierten Funktionen eröffnet mehr Flexibilität und Produktivität in der Architektur von Microservices oder dem konsequenten Einsatz von APIs. Diese Vorzüge erkennen immer mehr Organisationen und Entwicklungsteams. Die recht breite Auswahl von Programmiersprachen und Bibliotheken, die hier zum Einsatz kommen, spricht dafür, dass Entwickler genau abwägen, welche Umgebung am besten für den jeweiligen Funktionszweck geeignet ist.
Serverless-Computing scheint sich also weiter als wichtiges Thema in den Unternehmen zu etablieren. Schließlich liegt darin eine Möglichkeit, sich stärker auf den Geschäftswert zu fokussieren. Entwicklerteams können sich auf das Schreiben von Geschäftslogik konzentrieren und nicht auf die Codierung der unterstützenden Infrastruktur für die Geschäftslogik. Die Abschaffung von OnPremise-Systemen und verbrauchsabhängige Tarife entlasten das IT-Budget. Überspitzt zusammengefasst: Mit jeder Aufgabe und Teil der Business-Logik, die ausgelagert werden, steht mehr Zeit für die Produktion von Mehrwerten zur Verfügung. Aus Sicht von Anwenderinnen und Anwendern und Kundinnen und Kunden spielen diese technologischen und monetären Vorteile aber keine Rolle. Das Unternehmen steht insgesamt weiter in der Verantwortung für die Systeme und Anwendungen, die es bereitstellt. Wenn dort etwas nicht funktioniert, weil es in der Cloud zu Problemen gekommen ist, wird der Fehler nicht den Tech-Konzernen und ihrer Cloud-Infrastruktur angelastet, sondern dem Anbieter des Service.
Deshalb dürfen Unternehmen bei der Adaption von Serverless-Computing nicht die Herausforderungen des Monitorings und der Security unterschätzen. Im Sinne von sicheren, performanten und stabilen Anwendungen sollte das Setzen von Zugriffsrechten und Rollen nicht unterschätzt werden. Gleichzeitig werden die Konstruktionen insgesamt komplexer. Jede einzelne Komponente kann zwar einfacher und agil weiterentwickelt und gepflegt werden. Sie muss aber auch überwacht werden, damit Anomalien oder Störungen frühzeitig erkannt werden können, um einen Stillstand des Systems zu vermeiden. Bei Installationen, die auf 100 oder mehr FaaS-Element setzen, ist das von Menschen nicht mehr zu leisten. Hier werden in Zukunft Lösungen, die nicht nur optimal an die Cloud angepasst sind, sondern auch mit Methoden wie dem maschinellen Lernen arbeiten, eine noch stärkere Rolle spielen.
