Wie Amazon Web Services den Lambda-Service weiterentwickelt

Der Dualismus bei Lambda

In zweierlei Hinsicht veranschaulicht Lambda, was Cloud Computing von lokalen Rechenzentren unterscheidet. Lambdas, auch Funktionen genannt, sind elastisch und agil, ein Modell für Software Power on Demand. Ein paralleles – und vielleicht weniger hochgestecktes – Ziel dieses Dienstes ist es, Cloud Hosting anzubieten, ohne dass sich die Nutzer um den Serverbetrieb kümmern müssen.

Vor der Einführung von Lambda hatten Unternehmen nie eine Plattform, die taktisches Hosting unterstützen konnte – damit sind Berechnungen gemeint, die nur dann zur Verfügung stehen, wenn sie benötigt werden. Es machte also Sinn, dass Firmen nie Software zur Unterstützung dieses Modells entwickelten. Hinzu kommt, dass Lambda bei seiner Einführung einige Einschränkungen aufwies. Unternehmen, die sich schon früh mit Lambda beschäftigten, hatten Schwierigkeiten, in ihren IT-Betrieb einzugreifen, und die Prinzipien waren für die Entwicklungsteams alles andere als offensichtlich.

Und obwohl den Anwendern die Pay-as-you-use-Struktur gefiel, lernten sie schnell, dass das Lambda-Modell der On-Demand-Codeausführung am besten für die Behandlung von Ereignissen geeignet war, die in unregelmäßigen Abständen auftraten und weniger Verarbeitung pro Ereignis erforderte. Es gibt Verzögerungen beim Laden und Ausführen eines Lambdas, und die Gesamtkosten für den kontinuierlichen Betrieb von Lambdas können insgesamt höher sein als die Kosten für traditionelles Hosting.

Fünf Jahre später: Lambda sind funktionsfähiger

Insgesamt ist echtes Functional Computing in Bezug auf die damit zu erreichenden Möglichkeiten sehr restriktiv. Sie können keine Daten in einer Lambda-Instanz speichern, da diese zwischen den Schritten nicht persistent sind. Tatsächlich hat man keine Schritte, da Lambda den Verarbeitungsstatus nicht erkennt. Dadurch wurde Lambda schon früh zu einem Event Handling Tool. Das mag für das Internet der Dinge (Internet of Things, IoT) funktionieren, aber nicht für die Verarbeitung von Geschäftstransaktionen, die die Mehrheit der IT-Projekte ausmachen.

Der Service AWS Step Functions, der zwei Jahre nach Lambda eingeführt wurde, war der folgenreichste Schritt in Richtung Kommerzialisierung von Lambda. Tatsächlich ist Step Functions für AWS wohl wichtiger als Lambda selbst. Der Service integriert zwei kritische Konzepte der Transaktionsverarbeitung: den Begriff eines Workflows als geordnete Abfolge von Schritten und den Begriff des Status als Indikator dafür, wo sich die Dinge in einem mehrstufigen Prozess befinden. Die meisten Unternehmensanwendungen, die heute auf Lambda basieren, verwenden Step Functions.

Im Jahr 2017 kündigte Amazon Fargate an, ein quasi-serverloses Modell für das Container-Hosting. Obwohl Fargate nicht direkt mit Lambda verbunden ist, bietet es einen Pfad für Unternehmensanwendungen, die mehr Persistenz und die Unterstützung für Serveroperationen erfordern.

Auf den ersten Blick erscheint dies als ein Schritt, Lambda abzulösen. Stattdessen bedient Fargate lediglich Workloads, die von vornherein nicht für Lambda in Betracht kommen. Dies hat die Zahl der enttäuschenden oder gescheiterten Projekte, die über Lambda ausgeführt wurden, verringert.

Ab 2018 begannen auch Verschiebungen in der App-Entwicklung die Lambda-Nutzung zu beeinflussen. Unternehmen, die verbesserte Schnittstellen für Web- und mobile Anwendungen benötigten, führten ein Cloud-Frontend- und ein Backend-Modell für Rechenzentren ein. Der Frontend-Teil dieser Anwendungen ist für die Lambda-Implementierung wesentlich besser geeignet, und genau an diesem Punkt in der Entwicklung von Lambda begann auch die Akzeptanz in den Unternehmen deutlich zu steigen.

Etwa zur gleichen Zeit begann AWS, die ereignisbasierte Integration mit anderen Diensten und Hosting-Modellen zu verbessern. Mit diesen Funktionen konnten Unternehmen Lambda zur Verarbeitung von Software- und Anwendungsereignissen nutzen, anstatt sich auf externe Ereignisse zu konzentrieren, wie sie beispielsweise von IoT-Geräten erzeugt werden.

Dies öffnete die Tür zu mehr Betriebs- und Managementautomatisierung. Zum Beispiel können CloudWatch Events in Kombination mit Lambda Anwendungsreaktionen auf Laständerungen automatisieren, Ressourcen- und Anwendungsfehler und sogar Cloudburst verwalten oder Anwendungskomponenten, die selbst keine Lambda-Funktionen sind, skalieren.

Im November 2019 führte AWS Lambda Destinations ein. Mit dem Service können IT-Teams ihre Funktionen überwachen, indem sie einen Ereignispfad für Erfolgs-/Ausfallbenachrichtigungen definieren. Dies ist ein großer Fortschritt bei der Erkennung von Problemen mit Lambda-Aufrufen und der Ergreifung von Abhilfemaßnahmen. Es kann auch Lambda-Aufrufe mit traditionellen Amazon-Cloud-Diensten synchronisieren.

Eine klarere Perspektive für AWS Lambda

AWS Lambda hat seit seiner ersten Veröffentlichung erhebliche Fortschritte gemacht. Das Verständnis der Industrie für serverlose und Cloud-native Technologien hat sich seitdem ebenfalls weiterentwickelt. Anwender haben mittlerweile ein gutes Verständnis dafür, was Serverless Computing und AWS Lambda können – und was nicht. Dieser Überblick über AWS Lambda macht deutlich, dass Serverless Computing kein Allheilmittel ist.

In Zukunft wird AWS Lambda erfolgreich sein, wenn Amazon die Grenzen des Dienstes erkennt und ihnen angemessen Rechnung trägt. In vielen Fällen können die Probleme der Nutzer besser mit alternativen Diensten angegangen werden.

Allerdings gehört Lambda heute wahrscheinlich in viele Cloud-Frontend-Anwendungen und dürfte langfristig in den meisten eine Rolle spielen. Lambda ist nicht die Antwort auf alle Anforderungen der Transaktionsverarbeitung und des Kerngeschäfts. virtuelle Maschinen (VM), Container und Bare Metal werden auch in Zukunft wichtig sein. Es ist jedoch zu erwarten, dass Lambda neben diesen Technologien zunehmend eine Rolle spielt.