Serverless – Funktionen ohne Server mit AWS Lambda

#JAVAPRO #Serverless #AWSLambda

Nicht nur die Softwareentwicklung, sondern auch der IT-Betrieb ist einer ständigen Weiterentwicklung unterworfen. Ohne eine Virtualisierung geht nicht nur in Java heute gar nichts. Mit AWS -Lambda gibt es jetzt die Möglichkeit der serverlosen Datenverarbeitung um sich bei der Umsetzung auf die Umsetzung der Anforderungen und nicht um den Betrieb von Infrastrukturen zu kümmern.

Die Evolution der Cloud mit FaaS

Seit vor über einem Jahrzehnt das Cloud-Angebot Amazon Web Services (AWS) erschienen ist, hat sich die Anzahl und die Art der von AWS angebotenen Services verhundertfacht. War man am Anfang schon zufrieden, dass man sich nicht mehr um Rechnerund Speicherressourcen kümmern musste, sondern direkt in seine dort installierten virtuellen Maschinen loslegen konnte, stieg mit der Nutzung auch der Bedarf nach höherwertigen Diensten. Als neue Variante nach IaaS, PaaS und CaaS gibt es jetzt seit 2014 AWS Lambda, das allgemein als FaaS (Function as a Service) bezeichnet wird (Abb. 1).

Diese Variante verspricht in der Kombination mit den anderen AWS-Diensten, dass man sich als Entwickler rein auf die Umsetzung von ereignisgesteuerten Funktionen konzentrieren kann und sich nicht mit der Wartung der Infrastruktur beschäftigen muss. Für den Einstieg in die Entwicklung einer Lambda-Funktion mit Node.js reicht ein einfacher Browser und ein AWS-Konto. Die ersten eine Million Anforderungen und 400.000 GB/s verarbeiteten Daten sind in jedem Monat kostenlos. Zusätzliche Gebühren können anfallen, wenn Ihre Lambda-Funktion andere AWS-Services nutzt, Daten übertragen oder die jährliche kostenlose Testphase abgelaufen ist. Für bestimmte Kontingente bleiben zum Beispiel für AWS Lambda, Step-Functions und X-Ray auch danach kostenlos, jedoch nicht für das API oder IoT-Gateway.

Was ist eine serverlose Datenverarbeitung?

Mit dieser rein verbrauchsabhängigen Abrechnung wird man in vielen Fällen weniger bezahlen, als für eine nur schwach ausgelastete virtuelle Maschine, bei der man je nach Bereitstellung zusätzliche verbrauchsabhängige Kosten hat. Wenn kein Code ausgeführt wird, fallen bei Lambda also keine Kosten an.

Ein weiterer Vorteil ist, wenn man AWS-Plattformdienste nutzt, dass man sich auch nicht um die Wartung, Aktualisierung oder Skalierung dieser Dienste kümmern muss. Denn, wie sich AWS CTO Werner Vogels ausdrücke: „Kein Server ist so einfach zu verwalten, wie überhaupt kein Server“. Auch ThougtWorks hat das Thema serverlos in seinem neuesten Technology-Radar aufgenommen und auch in einem Grundlagenartikel von Mike Roberts beschrieben.

Der typische Aufbau einer serverlosen Architektur sieht wie folgt aus: Es gibt eine Funktion, die aufgrund eines Ereignisses in einem bestimmten Kontext gestartet wird und Geschäftslogik oder andere Backend-Dienste aufruft. Dessen Ergebnis wird dann asynchron zurückgeliefert. Es kann jedoch auch nur der Start eines Batch-Programmes sein. Eine Lambdafunktion darf selbst keine Zustände verwalten. Zum Abspeichern von Ergebnissen werden weitere AWS-Dienste, wie das Dateisystem S3 oder eine Datenbank wie DynamoDB benötigt (Abb. 2).

AWS Lambda Funktionen können in Node.js (JavaScript), Python, Java und C# (.NET Core) umgesetzt werden. Für Java bzw. C# gibt es mit AWS-Toolkit-for-Eclipse bzw. AWS-Toolkit-for-Visual Studio auch eine Integration in deren beliebteste IDE. Von vielen AWS-Diensten können Ereignisse verarbeitet und selbst wieder veröffentlicht werden. Zu den aktuell unterstützten AWS-Diensten gehören Amazon-Simple-Storage-Service (S3), DynamoDB, API-Gateway, Kinesis-Streams, Amazon-Simple-Notification-Service, Simple-Email-Service, Cognito, CloudFormation, CloudWatch , CodeCommit, Config, Echo und Lex (Abb. 3).

Funktionen einer serverlosen Plattform

Da die Ausführung einer Lambda-Funktion selbst nicht immer garantiert werden kann und weil die Log-Ausgaben und API-Aufrufe mit CloudTrail protokolliert werden, wird für eine größere AWS-Anwendung mit mehreren Funktionen und Services eine Überwachungs- und Tracing-Lösung, wie AWS-CloudWatch und AWS-X-Ray benötigt. Obwohl sich jede Änderung an der Lambda-Version automatisch pensioniert gestaltet, wird zum reinen API-Management das Amazon-PI-Gateway benötigt. Das API-Proxy hilft beim Erstellen, Veröffentlichen, Warten, Überwachen und Absichern der angebotenen REST-Services. Zusätzlich kann es auch die Autorisierung, Zugriffssteuerung, ebenso wie das Monitoring und Versionsmanagement der Services übernehmen. Gerade bei verteilten Diensten ist es wichtig einen Gesamtüberblick zu behalten und im Fehlerfall nachvollziehen zu können, wo der Engpass oder Fehler ursächlich aufgetreten ist, um nicht nur die Symptome zu behandeln, sondern das Problem an der Quelle lösen zu können. Mit X-Ray kann man seine eigene Anwendung um spezielle Trace-Ausgaben mit einer eindeutigen Korrelations-ID versehen.

Durch diese Gasse muss alles

Doch was sind typische Anwendungsfälle für serverlose Architekturen? Da sind die für mobile Apps oder IoT-Clients bereitgestellten Backend-for-Frontend-Dienste. Damit können entweder bestehende Backend-Dienste mit neuen geeigneten Schnittstellen und Protokolle angeboten werden, ohne die bisherigen
Dienste anpassen zu müssen oder auch davon entkoppelt weiterentwickelt werden. Ein beliebtes Muster ist hier das Gateway. Dieses wird von Amazon sowohl zum Management der API, als auch für IoT-Geräte angeboten. Unterstützt das API-Gateway nur REST-Endpunkte, werden vom Device-Gateway zusätzlich die
Protokolle MQTT und WebSockets unterstützt. Vor allem kann das Device-Gateway mit einer sehr hohen Anzahl von Geräten umgehen und kümmert sich um dessen Verwaltung. Gerade das API-Gateway ist für die meisten Lambda-Funktionen gesetzt, da es die Entwicklung und den Betrieb von Lambda-Funktionen
erleichtert. Neben einer Versionierung, kann auch die Dienstgüte und die Sicherheit der Lambda-Funktionen an einer Stelle einfacher realisiert werden. Das API-Gateway unterstützt Mock-Integration für API-Methoden. Damit ist es möglich, Testdaten für API-Antworten im API-Gateway zu hinterlegen, ohne dass die entsprechende Backendlogik bereits implementiert ist. Damit können Entwicklungsteams voneinander entkoppelt arbeiten.

Das Amazon-API-Gateway unterstützt den Import und Export von Swagger-Definitionen. Als Quasi-REST-Standard (die darauf basierende Open API Spezifikation 3.0 ist gerade in Arbeit) gibt es für Swagger in über 40 Sprachen Client-Bibliotheken. So lassen sich aus der API-Beschreibungen die Client-Rümpfe generieren oder in der Swagger-Oberfläche schon mal testen.

Anwendungsfälle für serverlose Referenzarchitekturen

Neben Mobile-Back-Ends und IoT-Back-Ends, die eh schon oft nachrichtenbasierten Informationsaustausch haben, sind sicher auch Teilfunktionen von Web-Anwendungen typische Einsatzgebiete von Lambda-Funktionen. So können Lambda-Funktionen über AWS-SNS-Push-Benachrichtigungen, E-Mails und SMS-Nachrichten asynchron versenden. Da gerade der Ressourcenbedarf für solche Nachrichten stark schwanken kann, profitieren diese Dienste von der dynamischen Skalierbarkeit und den verbrauchsabhängigen Kosten von Lambda.

Mit den durch Amazon-Alexa (die sprechende Lautsprecherbox) bzw. Lex (T2S, S2T-Konversationsdienste) beliebt gewordene Sprachsteuerung werden Chatbots immer populärer. Da diese bereits Cloud-Dienste nutzen und letztendlich wiederum einen Cloud-Dienst aufrufen, sind diese quasi prädestiniert für die Verwendung von Lambda. Da AWS mit Recognition einen eigenen Dienst für eine Bildanalyse anbietet, kann auch diese von Lambda genutzt werden (Abb. 4).

Für die Verarbeitung oder Umwandlung von großen Datenmengen bietet sich Lambda in Kombination mit anderen AWS-Data-Diensten an. Neben einer einfachen Dateiverarbeitung mit S3, kann Lambda auch Dienste von AWS-Kinesis zum Laden und Analysieren von Streaming-Daten nutzen.

Da Lambda-Funktionen selbst zustandslos sind und damit keine eigene Datenhaltung haben, müssen diese ihre Ergebnisse in Backend-Systemen speichern, wenn diese von anderen, darauf aufbauenden Funktionen genutzt werden sollen. Mit AWS-Step-Functions können einfache Arbeitsschritte von einzelnen Lambda-Funktionen grafisch modelliert und orchestriert werden. Je nach definiertem Zustand werden dann Folgefunktionen aufgerufen.

Anwendungsfälle mit einem Architekturdiagramm und Beispiel-Code finden sich auf der jeweiligen AWS-Github-Seite, wo diese aktualisiert und weiterentwickelt werden. Für den tieferen Einstieg gibt es eine ausführliche und mit Beispielen vorbildlich erstellte Dokumentation von Amazon zu Lambda. Abgerundet wird das durch vertiefende Whitepaper, aktuellen Blogbeiträgen oder Präsentationen, die neue Verwendungsmöglichkeiten beschreiben.

Serverlose Entwicklung und Deployment

Da man bei komplexeren serverlosen Anwendungen mit vielen genutzten Diensten schnell den Überblick verlieren kann und auch die regelmäßigen Deployment-Schritte nur automatisiert sinnvoll sind, gibt es auch hier hilfreiche Erweiterungen. Eine Deployment-Vorlage lässt sich mit dem AWS-Serverless-Application-Model (AWS-SAM) in einem Designer grafisch erstellen und mit CloudFormation automatisiert ausführen. Damit ist man nicht mehr, wie bei den ersten Schritten mit AWS Lambda, darauf angewiesen die Konfiguration über die AWS-Web-Konsole vorzunehmen.

(Listing 1) AWS SAM Beispielvorlage

AWSTemplateFormatVersion: ‚2010-09-09‘
Transform: ‚AWS::Serverless-2016-10-31‘
Resources:
MyFunction:
Type: ‚AWS::Serverless::Function‘
Properties:
Handler: index.handler
Runtime: nodejs4.3
CodeUri: ‚s3://my-bucket/function.zip‘

CodeBuild und CodePipeline ergänzen CloudFormation, um die einzelnen Schritte zum Bauen, Testen und Paketieren von serverlosen AWS-Anwendungen zu automatisieren. Bis auf die lokale Entwicklungsumgebung und eine gute Netzanbindung, braucht man keine eigene Infrastruktur um serverlose Anwendungen zu
entwickeln, da Amazon diese kostengünstig zur Verfügung stellt.

Mit dem Open-Source-Projekt Serverless-Framework, kann das Deployment und das Testen von serverlosen Anwendungen nicht nur von AWS Lambda, sondern auch mit seinen Konkurrenten MS-Azure und IBM-OpenWhisk, vereinfacht werden. Dadurch, dass dieses Deployment-Framework produktunabhängig ist, lässt es sich durch eigene oder fremde Plugins auch an die eigenen Bedürfnisse anpassen und so den eigenen Deployment-Prozess optimieren. Beim Bau von serverlosen Architekturen können die fünf im Buch „Serverless Architectures on AWS“ von Peter Sbarski beschriebenen Muster für Command, Messaging, Priority-Queue, Fan-out, Pipes-and-Filter hilfreich sein.

Besonders spannend, gerade für den IoT-Bereich, ist die Verknüpfung zwischen lokaler Vorverarbeitung auf dem Gerät und der Nutzung serverlosen Funktionen. Mit AWS-Greengrass kann AWS Lambda-Code lokal ausgeführt werden. Dazu muss auf einem Linux-Gerät, wie zum Beispiel der Raspberry Pi, Greengrass-Core installiert werden. Die Programmierung erfolgt mit dem Greengrass-Device-SDK, welches das bestehende AWS-IoT-Device-SDK erweitert. Durch die lokale Datenvorverarbeitung wird für die Datenübertragung weniger Bandbreite benötigt und die gesamte Übertragungszeit reduziert sich. Damit ist es auch einfach möglich auf zeitweise Netzausfälle reagieren zu können. Auch höhere Sicherheitsanforderungen können damit umgesetzt werden, da zum Beispiel nicht mehr individualisierte Daten, sondern nur deren berechneten Ergebnisse weitergegeben werden.

Ausblick

Gewiss sind serverlose Architekturen nicht für jede Anwendung geeignet. Je mehr die Leistungsfähigkeit von Cloud-Diensten erkannt wird und damit deren Nutzung voranschreitet, sind serverlose Dienste aber eine gute Ergänzung zu bestehenden Ansätzen. Die Vielzahl und Reife der bereits unterstützten Dienste ist beeindruckend. Gerade bei neuen oder spezialisierten Anwendungsfällen in den Bereichen Mobile, IoT, Big-Data oder kognitive Dienste können diese recht schnell umgesetzt und produktiv evaluiert werden. Serverlose Architekturen machen andere Ansätze, wie zum Beispiel containerbasierte Microservices, nicht überflüssig sondern ergänzen diese hervorragend. Als einziger Schwachpunkt bleibt, dass man sich mit der intensiven Nutzung, der von einem Cloud-Anbieter angebotenen Dienste mit serverlosen Anwendungen, stark abhängig von diesem macht. Wie bei jeder Architekturentscheidung sollte man sich deren Wechselwirkung bewusst sein, und sich nach einer Kosten-/Nutzen-/Riskobetrachtung entscheiden. Auf jeden Fall ist es sinnvoll, mit der serverlosen Architekturalternative erste Erfahrungen zu sammeln.