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.