Kolumne

EnterpriseTales: Klein, kleiner, AWS Lambda

Lars Röwekamp

Spätestens seitdem es State of the Art ist, seinen Monolithen in nette, kleine Module – aka Microservices – aufzutrennen, haben wir uns daran gewöhnt, dass der traditionelle Application Server dem alten Eisen zuzurechnen ist. Statt auf eine schwergewichtige Runtime zu setzen, bündelt man heutzutage die notwendigen Serverfragmente direkt mit dem fachlichen Code und spendiert ihm so eine Art integrierte Laufzeitumgebung. Das Ganze noch in mehreren Containern verpackt, ein wenig mit Management- und Monitoringfunktionalität versehen und fertig ist die Anwendung.

Dem nicht genug, taucht in der jüngsten Vergangenheit vermehrt der Begriff Serverless Applications auf. Vorreiter ist mal wieder Amazon mit AWS Lambda. Aber auch Mitbewerber wie IBM mit openWhisk , Google mit Cloud Functions oder Microsoft mit Azure Functions stehen in den Startlöchern. Kann zukünftig also ganz auf Server und Infrastruktur verzichtet werden? Wenn ja, wie bitte soll das funktionieren? Und für wen ist das überhaupt interessant? Aufklärung muss her. Ein Fall für Enterprise Tales!

Was ist eine Serverless Application?

Der Begriff Serverless Application ist ein wenig irritierend, da er suggeriert, dass auf eine Ablaufumgebung für den eigenen Anwendungscode gänzlich verzichtet werden kann. Dies ist nicht der Fall. Vielmehr möchte der Begriff ausdrücken, dass Serverless Applications intensiven Gebrauch von Third-Party-Diensten machen, wie Cloud-basierte Datenbanken, Filesysteme und API-Gateways (Backend as a Service, kurz BaaS) oder der eigene Anwendungscode in einem ebenfalls externen flüchtigen Compute-Container abläuft (Function as a Service, kurz FaaS). Kombinationen beider Ansätze sind natürlich auch erlaubt. Google schreibt dazu: „Functions is a lightweight, event-based, asynchronous compute solution that allows you to create small, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment.“

PaaS, BaaS oder FaaS?

Bei den vielen Akronymen kann man schon einmal durcheinanderkommen. Während PaaS (Platform as a Service) eher als Development- und Deployment-Plattform verstanden werden will, also dafür verantwortlich ist, Anwendungen und deren Code zu verwalten, auszuführen und zu überwachen, stellt BaaS nützliche Backend-Systeme, wie Datenbanken, Filesysteme oder Authentication Services, zur Verfügung, die von den Entwicklern aus ihren Anwendungen heraus direkt angesprochen werden können.

Aber wie passt da nun FaaS ins Bild? Die Idee bei FaaS ist, dass der Anwendungsentwickler zwar serverseitigen Code (Functions) implementiert, als Runtime aber kein Application Server oder Embedded Server verwendet wird, sondern ein Cloud-basierter „stateless compute container“. Anders formuliert deployt der Entwickler seine Funktion einfach, indem er den zugehörigen Code direkt in die Cloud lädt und einen Trigger definiert, also ein Event, das die Ausführung des Codes anstößt. Ein solches Event kann z. B. die Ablage einer Datei in das Cloud-Dateisystem, das Hinzufügen eines Datensatzes in die Cloud-Datenbank oder aber ein Request gegen ein Cloud-API-Gateway sein. Sobald ein passendes Event ausgelöst wurde, wird die FaaS-Funktion in einem eigenen Prozess gestartet und ausgeführt. Laufzeitressourcen wie CPU oder Speicher werden also nur dann belegt, wenn tatsächlicher Bedarf besteht.

Das wesentliche Alleinstellungsmerkmal von FaaS ist also, dass man Backend-Code ausführen lassen kann, ohne eigene Application Server oder Serveranwendungen managen zu müssen. Auch das Verwalten von Containern entfällt. Skalierung bekommt man durch den FaaS-Provider geschenkt. Geschenkt? Naja, nicht ganz. In der Regel wird nach Aufrufen oder CPU-Zeit abgerechnet – bei AWS Lambda in 100-ms-Schritten. Je mehr oder je rechenintensiver der Aufruf, desto teurer die Funktion zur Laufzeit.

Beispiel gefällig?

Ein typisches Beispiel für eine FaaS-Funktion wäre ein Backend-Processing-Service für die Verarbeitung von Ressourcen, z. B. Bilder. Lädt ein Nutzer ein Bild in die Cloud, könnte durch die Ablage des Bilds in das Cloud-basierten Dateisystem ein Event ausgelöst werden, das die FaaS-Funktion triggert, die dann automatisch Thumbnails oder alternative Bildformate generiert. Diese werden wiederum ebenfalls in dem Cloud-basierten Dateisystem abgelegt.

Wie aber sieht es mit UI-getriebenen Anwendungen aus, z. B. einem Webshop? Auch hier ist eine Serverless Application denkbar. Nehmen wir als Ausgangsbasis an, dass das UI des Webshops als Single Page Application (SPA) realisiert wurde, sich ein Teil der Businesslogik also im Client befindet. Die Authentifizierung könnte über einen Cloud-basierten BaaS-Service erfolgen; einfache, lesende Abfragen auf die Datenbank ebenso, z. B. zur Auflistung von verfügbaren Produkten. Komplexere Aktionen wie eine parametrisierbare Suche könnten wir durch eine FaaS-Funktion realisieren, die den Zugriff auf die dahinterliegende Cloud-Datenbank kapselt. Aber wie wird diese aktiviert? Hier kommt ein API-Gateway ins Spiel, also eine Art konfigurierbarer HTTP-Server, der unsere Suchanfrage als http- Request entgegennimmt, die übergebenen Parameter auf die Eingabeparameter unserer Funktion transformiert und uns später das Ergebnis in Form eines ebenfalls transformierten HTTP-Responses zurückliefert. Das API-Gateway selbst ist natürlich auch eine Cloud-basierte Komponente, die es lediglich zu konfigurieren gilt.

Um die FaaS-Funktionen zu realisieren, bietet Amazon Lambda Unterstützung für die Programmiersprachen JavaScript, Python und Java. Weiterer Sprachen sind geplant. Google Functions dagegen unterstützt lediglich JavaScript, IBM OpenWhisk JavaScript und Swift. Die breiteste Unterstützung bietet derzeit Microsoft Azure Functions mit JavaScript, C#, Python und PHP.

State und Performanz

FaaS-Funktionen teilen sich per Definition keinen Speicher und sollten somit stateless sein. Sie führen also entweder ausschließlich Transformationen oder Berechnungen auf den übergebenen Parametern durch oder beziehen den zur Berechnung notwendigen State aus Cloud-basierten Datenbanken, Dateisystemen oder Cross-Application Caches.

Eine FaaS-Funktion wird bei Bedarf gestartet, ausgeführt und dann wieder beendet. Je nach gewählter Programmiersprache oder zugrunde liegender Runtime kann es dabei zu einer gewissen Start-up-Latenz kommen. Bei JavaScript oder Python fällt dies in Relation zum eigentlichen Code kaum ins Gewicht. Etwas anders sieht es aus, wenn der Code in einer JVM ausgeführt wird. Hier kann es in ungünstigen Konstellationen zu erheblichen Start-up-Verzögerungen kommen. Dies ist immer dann der Fall, wenn zwischen zwei Aufrufen viel Zeit vergeht oder Peaks punktuell zu deutlich mehr Aufrufe als gewöhnlich führen. In der Regel ist dieses Problem aber zu vernachlässigen, wenn nicht gerade eine Anwendung mit Echtzeitanforderung realisiert werden muss.

FaaS-Funktionen sind in der Regel in ihrer Ausführungszeit begrenzt. Amazon Lambda gibt ein Limit von 300 Sekunden vor. Möchte man langlaufende Prozesse modellieren, gilt es somit eine entsprechende Architektur zu designen, die diese in mehrere FaaS-Funktionen splittet.

Wie funktionier das Testing bei Serverless?

Da der Code einer FaaS-Funktion in der Regel keinen State benötigt oder diesen aus einem leicht zu mockenden Third-Party-System bezieht, sind Unit-Tests denkbar einfach zu realisieren. Wie aber sieht es mit Integrationstests aus? Hier wird es schon etwas schwieriger, da diese stark von den verschiedenen Cloud-Diensten abhängen. Es stellt sich also die Frage, wie gut diese Drittsysteme für Testszenarien geeignet sind. Ist eine Verwendung im Rahmen von Tests überhaupt vorgesehen? Existieren Test-Stubs, gegen die entwickelt werden kann? Wie einfach lassen sich die Systeme mit sinnvollen Testdaten befüllen? Und welche Strategie zur Abrechnung der Testläufe innerhalb der Cloud fährt der Provider? Sicherlich wird es in den wenigsten Fällen möglich sein, Integration- oder Acceptance-Tests vollständig auf seinem lokalen Rechner oder einen nicht mit der Cloud verbundenen Rechner durchzuführen.

Fazit

Positiv zu bewerten ist das extrem einfache Modell. Als Entwickler brauche ich mich um nichts weiter als den Anwendungscode zu kümmern. Das Managen von Servern oder Containern entfällt. Kosten fallen nur dann an, wenn die Anwendung Last erzeugt, wobei diese automatisch skaliert. Dies macht sich insbesondere bei Peaks positiv bemerkbar, für die normalerweise zusätzliche Infrastruktur bereitgehalten werden müsste. Auch das Deployment einer neuen Version einer FaaS-Funktion ist denkbar einfach. Einfach den Code hochladen oder im Falle von Java vorher packen, und schon steht die neue Version zur Verfügung.

Als Nachteil ist sicherlich der Vendor-Lock-in zu sehen. So können FaaS-Funktionen zwar in Standardsprachen wie Java oder JS geschrieben werden, alles andere aber ist herstellerspezifisch, z. B. die Trigger und angebundenen BaaS. Eine Portierung einer Anwendung von Amazon zu Google wäre ohne Weiteres nicht möglich. Insbesondere würde dieser Schritt bedeuten, dass auch angebundene Systeme, wie Cloud-Dateisystem oder Cloud-Datenbank, portiert werden müssten. Hier wären On-Premise-Lösungen sowie Abstraktionsframeworks zur Erhöhung der Portabilität wünschenswert.

API-Änderungen, neue Major-Releases oder ein abgeändertes Preismodell können so zu einem echten Risiko werden. Ein weiterer Nachteil kann sich auch durch die Verlagerung der Businesslogik auf den Client ergeben. Wer mehrere verschiedene Clients anstrebt, muss diesen Code entsprechend mehrfach implementieren. Auch die aktuellen SLAs der verschiedenen Anbieter könnten sich im Einzelfall als Nachteil herausstellen. Amazon erlaubt maximal 1 000 parallel laufende Ausführungen von Lambdas. Das hört sich erst einmal viel an, ist aber nach dem aktuellen Modell als Maximum über alle Lambda-Funktionen zu sehen. Ein intensiver Test könnte so die Produktivumgebung lahmlegen.

Fairerweise muss gesagt werden, dass wir uns noch in einer sehr frühen Phase befinden und daher davon auszugehen ist, dass sich etliche der angesprochenen Probleme bereits auf der Agenda der Anbieter befinden. In diesem Sinne: Stay tuned …!

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: