Was ist AWS Lambda und was kann man damit machen? Einführung in AWS Lambda – Teil 1

AWS-Lambda ist ein Event-getriebener Compute-Service in der Cloud.

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 Containernumsetzen, 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.

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.