Einführung in AWS Lambda – Teil 1

Was ist Lambda und was kann man damit machen?

| Autor / Redakteur: Thomas Drilling / Florian Karlstetter

Einführung in Serverless Computing mit AWS Lambda.
Einführung in Serverless Computing mit AWS Lambda. (Bild: Amazon Web Services)

AWS hat mit Lambda „Serverless Computing“, bzw. „Serverless Applications“ salonfähig gemacht. Microsoft hat mit Azure Functions und Google mit Cloud Functions nachgezogen. In allen drei Fällen handelt es sich um eine Ereignis-basierte und asynchrone Computing-Lösung, mit deren Hilfe sich kleine, einzelne, direkt mit anderen Cloud-Services korrespondierende Funktionen erstellen lassen, ohne dass dazu ein virtueller Server oder eine Laufzeitumgebung erstellt und verwaltet werden muss.

Die Verwendung oder Verwendbarkeit von AWS-Lambda steht im engen Zusammenhang mit der Implementierung der Geschäfts-Logik für komplexe (Web)-Anwendungen in der Cloud. Dabei müssen sich Nutzer keine Gedanken über die Infrastruktur oder die Bereitstellung von Servern mehr machen, etwa in Bezug auf das Hochskalieren der Lambda-Aufrufe. So lassen sich mit wenigen Klicks Bindungen an andere AWS-Dienste oder auch externe Dienste erstellen, welche als Ein- oder Ausgabe für Lambda dienen können.

Während bereits das PaaS-Modell im Gegensatz zu IaaS und SaaS Nutzer und Entwickler im Wesentlichen von der Notwenigkeit entbindet, sich um Infrastrukturaspekte kümmern zu müssen, treiben Lambda-Funktionen diese Idee mit Serverless-Computing auf die Spitze. Gezahlt wird nicht mehr für Infrastruktur, sondern für Funktionsaufrufe.

Von REST zur Geschäftslogik

Die besonderen Eigenschaften von Cloud Computing wie z. B. Elastizität erfordern es, das komplexe Anwendungen nicht mehr monolithisch, sondern modular und Service-orientiert programmiert sind. Nur dann z. B. können Cloud-Features wie eine automatische Skalierung von Anwendungen greifen. Eine Möglichkeit, eine Service-orientiere Architektur, wie Sie Web-Anwendungen von Haus aus vorsehen, zu implementieren ist eine REST-Architektur. Dieser wiederum begünstigt z. B. im Vergleich zu SOAP das Modell der so genannten „losen Kopplung“, die wiederum eine elementare Voraussetzung dafür ist, dass eine Anwendung skalierbar wird/bleibt, da REST-Aufrufe zustandslos sind. Eine REST-Architektur begünstigt, bzw. ermöglicht die lose Kopplung, wenngleich hierbei immer noch HTTPS-Services direkt miteinander sprechen. Eine solche Architektur lässt sich weiter entzerren/entkoppeln, in dem man etwa HTTP-Services nicht direkt miteinander kommunizieren lässt, sondern Queueing- oder Messaging-Systeme dazwischen schaltet.

Aus einer einfachen, starren Geschäftslogik, wie etwa der simplen Abfrage eines hinter einem Loadbalancer platzierten Webservers, der im Hintergrund Daten aus einer Datenbank serviert (LAMP-Stack), wird eine individuelle Geschäftslogik: wenn beispielsweise Ereignisse Funktionen triggern, die wiederum Nachrichten versenden, welche dann Aktionen wie das Skalieren eines Webservers oder das Holen und Weiterverarbeiten eines Datenbankeintrags auslösen.

Zustandslosigkeit

Zustandslosigkeit bedeutet, dass es bei einer REST-Kommunikation keine Benutzersitzungen (etwa in Form von Sessions und Cookies) gibt, weil sämtliche erforderlichen Informationen stets bei jeder Anfrage neu mitgeschickt werden. Dabei ist es gerade die Zustandslosigkeit, durch die REST-Services sehr einfach skalierbar sind. Existieren keine Sitzungen, ist es im Grunde auch unerheblich, wenn z. B. mehrere Anfragen der Clients zum Zwecke der automatischen Skalierung auf verschiedene Server verteilt werden.

Eine zustandsorientierte (Stateful) Geschäftslogik sollte man also wann immer möglich vermeiden. Umsetzbar ist dies z. B. in einem REST-Kontext mit Hilfe einer dokumentenorientierten Verarbeitung. Damit ist gemeint, das Service-Design möglichst so zu wählen, dass ein Arbeitsschritt mit einem Service-Aufruf abgedeckt werden kann. Ganz vermeiden lassen sich Zustandsinformationen natürlich nicht immer. Trotzdem sollte man die zwingend erforderlichen Zustandsinformationen durch geschicktes Design so gering wie möglich halten. Probates Mittel zum Verwalten von Zustandsinformationen sind z. B. Tabellen in einer InMemory-Datenbank oder Caches. Auch Lambda-Funktionen helfen beim Implementieren einer zustandslosen Geschäftslogik. Ein Parade-Beispiel für eine solche zustandslose Kommunikation und damit prädestiniert für skalierbare Deployments in AWS sind übrigens Microservices.

Microservices

Microservices sind im Grunde nur ein weiterer Ansatz zum Modularisieren von Software. Dazu gibt es historisch bedingt auch eine ganze Reihe weiterer, wie z. B. JARs, Klassen oder Packages bei Java- und Web-Anwendungen. Während letzte vorrangig dazu dienen, Projekte in gut wartbare und erweiterbare Einheiten aufzuteilen, haben Microservices ein anderes Ziel, nämlich erstrangig das unabhängige Deployment. So lässt sich ein Microservice bekanntlich in Produktion bringen, ohne das andere im Rahmen der gesamten Applikation verknüpfte Microservices für sich ebenfalls neu ausgerollt werden müssten. Das gilt bei den klassischen monolithischen Deployment-Modellen nicht, auch wenn eine monolithische Anwendung für sich durchaus sauber modularisiert sein kann. Microservices kann man z. B. mit Containern umsetzen, eine der derzeit beliebtesten Optionen, denn jeder Miroservice kann hierbei auf Basis einer anderen Plattform und mit Hilfe einer anderen Programmiersprache realisiert sein, da Docker-Container auf nahezu jeder Architektur laufen. Zudem kann jeder Microservice für sich allein - unabhängig von den anderen - skalieren. Microservices tragen auch zur Robustheit des Gesamt-Service bei. Belastet z. B. ein Microservice CPU und/oder Memory überdurchschnittlich stark, hat das keinen Einfluss auf andere Microservices.

Microservices und Lambda

Allerdings ist Docker nicht die einzige Möglichkeit zur Realisierung von Microservices. So lassen sich auch mit AWS Lambda einzelne, in Java, JavaScript oder Python geschriebene „Funktionen“ direkt in der Cloud „deployen“, die Abrechnung erfolgt seitens Amazon pro Funktionsaufruf. Lambda-Funktionen verringern damit den Aufwand zum Aufbau einer Microservices-Architektur erheblich, da keine Docker-Container oder ähnliches benötigt werden. Lambda-Funktionen bieten trotzdem eine gute Isolation und Skalierbarkeit der einzelnen Services. Und damit zurück zur Geschäfts-Logik eines AWS-Deployments: für das Erstellen komplexer, individueller Geschäftslogiken kann Lambda Events aus SQS, SNS oder Kinesis Streams vernüpfen.

Was ist Lambda genau?

AWS bezeichnet Lambda konkret als serverlosen Datenverarbeitungsservice, der den vom Nutzer hochgeladenen Code beim Eintreten bestimmter Ereignisse ausführt und automatisch auf Basis der zugrunde liegenden Datenverarbeitungsressourcen verwaltet. Lambda-Funktionen erweitern so andere AWS-Services mit benutzerdefinierter Logik. Alternativ können Nutzer mit Lambda eigene Backend-Services erstellen und trotzdem mit der Leistung und Sicherheit von AWS betreiben.

Lambda-Funktionen können getriggert durch Events andere AWS-Dienste „ansteuern“.
Lambda-Funktionen können getriggert durch Events andere AWS-Dienste „ansteuern“. (Bild: AWS)

Dabei kann Lambda Code automatisch als Reaktion auf bestimmte Ereignisse (auch mehrere) ausführen, etwa wenn sich ein Objekt, wie z. B. ein Amazon S3-Bucket geändert hat oder eine Tabelle in Amazon DynamoDB verändert wurde.

Ein weiteres klassisches Lambda-Beispiel mit Amazon S3: mit einer S3-Funktion könnte der Nutzer eine Lambda-Funktion erzeugen, die eine Benachrichtigung sendet, sobald es eine Änderung in S3 gab. Man kann den Faden auch weiterspinnen. Lädt ein Benutzer ein neues Bild in S3 hoch, könnte eine Lambda-Funktion dafür sorgen, dass eine andere Komponente das Bild in ein Thumbnail konvertiert und in ein anderes S3-Bucket ablegt.

Die Lambda-Funktion verarbeitet dabei nur das Ereignis (die Business-Logik); unabhängig davon, wo der Konvertierungscode liegt und ausgeführt wird. Dabei führt Lambda den Code immer automatisch auf der hochverfügbaren Datenverarbeitungsinfrastruktur von AWS aus, einschließlich der gesamten Administration der Datenverarbeitungsressourcen, Server- und Betriebssystemwartung, Kapazitätsbereitstellung, automatischer Skalierung, Code- und Sicherheitspatch-Bereitstellung sowie der Code-Überwachung und -Protokollierung. Der Nutzer muss wirklich nichts anderes tun, als den Code zur Verfügung zu stellen, wobei der Begriff „Code“ hier synonym für "Lambda-Funktion" steht.

Eine einmal hochgeladene Lambda-Funktion ist „sofort“ zum Ausführen bereit, etwa wenn sie durch ein Ereignis getriggert wird, vergleichbar einer Formel in einer Tabellenkalkulation. Neben dem eigentlichen Code enthält jede Lambda-Funktion einige Konfigurationsinformationen, wie z. B. den Namen der Funktion und die Ressourcenanforderungen. Da Lambda-Funktionen immer "zustandslos" sind, also keine unmittelbare Beziehung zur zugrunde liegenden Infrastruktur haben, kann Lambda bei Bedarf so viele Kopien der Funktionen starten, wie zum Skalieren mit der Häufigkeit der eingehenden Ereignisse erforderlich sind.

Hat der Nutzer seinen Code auf AWS Lambda hochgeladen, kann er seine Funktion ausgewählten AWS-Ressourcen zuordnen, wie z. B. dem erwähnten Amazon S3-Bucket, einer Amazon DynamoDB-Tabelle, einer Amazon SNS-Benachrichtigung oder einem Amazon Kinesis-Stream. Ändert sich etwas bei einer dieser Ressourcen, führt Lambda die definierte Funktion aus und verwaltet gleichzeitig die benötigten Datenverarbeitungsressourcen, die für die Verarbeitung der eingehenden Anforderungen erforderlich sind. AWS-Lambda-Code lässt sich zudem über die AWS-SDK auch innerhalb von anderen AWS-Services ausführen, wobei man mit AWS IAM-Rollen dafür sorgen kann, den Zugriff auf ausgewählte Ressourcen für einen Service mit Hilfe einer IAM-Rolle oder einen Anwender mit Hilfe eines IAM-Users zu beschränken.

AWS rechnet die Lambda-Nutzung auf Basis der bedienten Anfragen und der benötigten Rechenzeit (gemessen in 100-Millisekunden-Samples) ab, die zum Ausführen des Codes benötigt wird. Dabei sind eine Million Anforderungen und 400.000 GB/s Datenverarbeitungszeit pro Monat kostenlos. Erst jede weitere Million Anfragen wird mit 0,20 US-Dollar berechnet.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44799050 / Microservices)