AWS Lambda ist ein ereignisgesteuerter Serverless Computing Service, mit dem Code für praktisch jede Art von Anwendung oder Backend-Service ausgeführt werden kann, ohne dass Server bereitgestellt oder verwaltet werden müssen. Lambda-Funktionen können durch Ereignisquellen wie verschiedene AWS-Services oder eigene Anwendungen ausgelöst werden. Dieser Artikel erläutert die Kernkonzepte von Serverless und AWS Lambda und zeigt anhand von zwei Beispielanwendungen, wie sich mit automatischer Skalierung, integrierter Hochverfügbarkeit und einem nutzungsbasierten Abrechnungsmodell neue Ideen schnell an den Markt bringen lassen.

Der Begriff „Serverless“ umfasst Technologien für die Ausführung von Code, die Verwaltung von Daten und die Integration von Anwendungen ohne die Verwaltung von Servern. In der Regel passen sich Serverless-Dienste automatisch an die Nachfrage an, ohne dass die Menge der bereitgestellten Ressourcen manuell erhöht oder verringert werden muss. Gleichzeitig bedeutet das nutzungsabhängige Abrechnungsmodell, dass sich die Kosten am tatsächlichen Bedarf orientieren, sodass Kosten nur für abgerufene Leistung anfallen und nicht für ungenutzte Kapazitäten oder Ressourcen.

Aufgaben der Infrastrukturverwaltung wie Server- und Betriebssystemwartung, Sicherheitsisolierung, Hochverfügbarkeit, Aktualisierungen der Anwendungslaufzeiten und Logging werden vom Serverless-Dienst übernommen. Da diese Aufgaben in den Kosten des Diensts enthalten sind, können Serverless-Architekturen die Gesamtbetriebskosten (Total Cost of Ownership) einer Anwendung senken.

Dank des reduzierten Zeitaufwands für die Infrastrukturverwaltung können sich Nutzer von Serverless-Diensten auf Aktivitäten konzentrieren, die den Geschäftswert der eigenen Kunden maximieren. Durch Automatisierung und Minimierung des Betriebsaufwands kann mehr Zeit und Energie in die Entwicklung von Geschäftslogik, die schnellere Bereitstellung von Funktionen, die Entwicklung neuer Produkte und Dienstleistungen und damit in die Gewinnung neuer Kunden fließen.

Amazon Web Services (AWS) bietet Serverless-Dienste in mehreren Kategorien an. Dazu gehören Computing-Dienste wie AWS Lambda [1] für ereignisgesteuertes Computing oder AWS Fargate [2] für Serverless-Container. Serverless-Integrationsdienste wie der Amazon Simple Notification Service (Amazon SNS) [3], der Amazon Simple Queue Service (Amazon SQS) [4] oder Amazon EventBridge [5] erleichtern die Integration und Orchestrierung verschiedener Service-Bausteine in Anwendungen. Schließlich bieten Services wie Amazon Simple Storage Service (Amazon S3) [6] und Amazon DynamoDB [7] eine Serverless-Datenspeicherung. Einen umfassenderen Überblick über die verfügbaren Serverless-Dienste sind unter [8] verfügbar.

Serverless mit AWS Lambda

Mit AWS Lambda kann Code, der in einer Vielzahl von Programmiersprachen wie Python, Java oder TypeScript geschrieben wurde, in einer Serverless-Computing-Umgebung ausgeführt werden, ohne dass die Infrastruktur verwaltet werden muss [9]. Lambda-Funktionen können in der präferierten IDE oder in der AWS Management Console erstellt werden. Um eine Lambda-Funktion bereitzustellen, werden die Code-Assets oder kompilierten Programme und ihre Dependencies in ein .zip-Archiv oder ein Container-Image gepackt. In der Praxis übernehmen IaC-Tools (Infrastructure as Code) wie das AWS Serverless Application Model (AWS SAM) [10], das AWS Cloud Development Kit (AWS CDK) [11], Terraform [12] oder andere diese Bereitstellung.

Lambda eignet sich hervorragend für eine Vielzahl von Anwendungsfällen, darunter Webanwendungen und Back-ends für Mobile-Apps, Datei- und Streamverarbeitung, Backends für das Internet der Dinge (IoT), maschinelle Lernverfahren, IT-Automatisierung und vieles mehr.

Skalierung und Nebenläufigkeit

Lambda ist so konzipiert, dass es automatisch und nahtlos mit der Anzahl der eingehenden Anfragen skaliert. Der Lambda-Dienst erreicht das, indem er die Anzahl der gleichzeitigen Ausführungen ihrer Funktionen erhöht. Wird eine Lambda-Funktion aufgerufen, erstellt der Lambda-Dienst eine Ausführungsumgebung (Execution Environment) mit der von Ihnen gewählten Laufzeit (Runtime), dem Funktionscode und den Dependencies. Der Funktionscode wird ausgeführt, um das eingehende Ereignis zu verarbeiten. Sobald die Verarbeitung abgeschlossen ist, bleibt die Ausführungsumgebung einige Zeit aktiv und ist bereit, weitere Ereignisse zu verarbeiten.

Wenn neue Ereignisse eintreffen, während die Ausführungsumgebung beschäftigt ist, erstellt Lambda zusätzliche Ausführungsumgebungen der Funktion, um diese Anfragen gleichzeitig zu bearbeiten. Abhängig von Faktoren wie der Größe und Konfiguration der Lambda-Funktion werden neue Ausführungsumgebungen im zweistelligen Millisekundenbereich erstellt. Die Latenz ist höher, wenn eine Funktion unmittelbar nach ihrer Erstellung oder Aktualisierung aufgerufen wird oder wenn sie in letzter Zeit nicht verwendet wurde.

Standardmäßig kann ein AWS-Konto auf bis zu 1 000 gleichzeitige Lambda-Ausführungen pro AWS-Region skalieren [13]. Darüber hinaus legt das Burst-Kontingent (Burst Concurrency Quota) [14] fest, wie schnell Lambda-Funktionen skalieren können. Diese Kontingente können über die Service Quotas Console [15] oder den AWS-Support erhöht werden, um den Anforderungen einer Anwendung gerecht zu werden.

Um mehr über das Skalierungsverhalten von Lambda anhand von Beispielen zu erfahren, siehe die Abschnitte „Skalierung und Durchsatz verstehen“ unter [16], das Beispiel für die bedarfsbasierte Skalierung im AWS Lambda Operator Guide unter [17] und den ausführlichen Talk darüber, wie AWS Lambda „unter der Haube“ funktioniert unter [18].

Abrechnung, richtige Dimensionierung und Zusammenspiel von CPU und Speicher

Die Preisgestaltung für Lambda hat zwei Komponenten: die Anzahl der an eine Funktion gestellten Anfragen und die Ausführungsdauer in GB pro Sekunde. Diese Aus-führungsdauer wird in 1-Millisekunden-Schritten multipliziert mit dem der Funktion zugewiesenen Speicher berechnet. So wird eine Funktion, die 100 ms lang mit 2 GB zugewiesenem Speicher läuft, zum gleichen Preis abgerechnet wie eine Funktion, die 200 ms lang mit nur 1 GB zugewiesenem Speicher läuft.

Die CPU-Ressourcen werden einer Lambda-Funktion im Verhältnis zur gewählten Speichergröße zugewiesen. Durch Hinzufügen von mehr Speicher erhöhen sich proportional die CPU-Ressourcen und damit die Gesamtrechenleistung der Funktion. Wenn eine Funktion CPU-intensiv ist, kann eine Erhöhung des konfigurierten Speichers ihre Leistung verbessern. Mit 1 769 MB zugewiesenem Speicher kann eine Funktion auf das Äquivalent einer vCPU zugreifen. Wenn der zugewiesene Speicher größer wird, skaliert Lambda die Anzahl der vCPUs proportional, d. h. 2 vCPUs bei 3 538 MB und bis zu 6 vCPUs bei 10 GB.

Die richtige Dimensionierung des Speichers einer Lambda-Funktion kann zu Kosteneinsparungen und Leistungssteigerungen für Lambda-Funktionen führen. AWS Lambda PowerTuning [19] ist ein Open-Source...