Ankündigung von AWS Lambda Web Functions
🇬🇧 Read in English~3 min read
devopsawslambdaserverlessweb
GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.
Lambda Web Functions ist eine neue Formfaktor-Option, mit der Sie standardmäßige HTTP-Webanwendungen auf Lambda ausführen können, ohne Ihren Code in einen Event-Handler umzuschreiben. Nehmen Sie einen standardmäßigen Port-lauschenden Server, der mit Express, Hono, Fastify, Next.js oder einem beliebigen Node.js-Framework erstellt wurde, stellen Sie ihn mit einem einzigen Befehl bereit, und Lambda übernimmt Skalierung, Multi-Region-Verteilung und Abrechnung nach aktiver CPU-Nutzung. Keine Adapter, keine zu verwaltende Infrastruktur, keine Framework-Bindung.
Mit diesem Launch bietet AWS Lambda drei verschiedene Formfaktoren an, die alle auf derselben Firecracker-Isolationstechnologie basieren und jeweils auf ein anderes Programmiermodell abzielen:
Lambda Event Functions sind das, was Sie bisher als einfache Lambda-Funktionen kannten: das ereignisgesteuerte Modell mit einem einzelnen gleichzeitigen Handler und Abrechnung nach Wanduhrzeit. Jetzt mit einem expliziten Namen versehen – Ihre Funktion empfängt ein Ereignis, verarbeitet es und gibt eine Antwort zurück. Ideal für Ereignisverarbeitung, Queue-Consumer und Aufrufe, die von anderen AWS-Services ausgelöst werden.
Lambda Web Functions verwenden ein HTTP-natives Programmiermodell mit mehrfacher gleichzeitiger Ausführung und Abrechnung nach aktiver CPU-Nutzung (Sie zahlen für die CPU, die Sie tatsächlich nutzen, nicht für die Wanduhrzeit). Ihr Code lauscht auf einem Port und verarbeitet standardmäßige HTTP-Anfragen. Ideal für Webanwendungen, API-Backends und interaktive HTTP-Workloads, bei denen mehrere gleichzeitige Anfragen und I/O-intensive Verarbeitung die Norm sind.
Lambda MicroVMs bieten isolierte, zustandsbehaftete Sandbox-Umgebungen mit kundenseitig verwalteten Lebenszyklen für die Ausführung von nicht vertrauenswürdigem oder benutzergeneriertem Code.
Die drei ergänzen sich gegenseitig – eine einzelne Anwendung könnte Event Functions für die asynchrone Backend-Verarbeitung, Web Functions für die benutzerorientierte API und das serverseitige Rendering sowie MicroVMs für interaktive Code-Ausführungsfunktionen verwenden, alles im selben Konto mit demselben Betriebsmodell.
Das bisherige Modell erzwang einen mentalen Moduswechsel: HTTP-Frameworks denken in Verbindungen und gleichzeitigen Anfragen, Lambda-Funktionen denken in Ereignissen und einzelnen Aufrufen. Web Functions beseitigen diese Impedanz-Diskrepanz – Sie bringen Ihr vorhandenes Node.js-Framework, Ihre vorhandene Middleware, Ihren vorhandenen Anfrage-Lebenszyklus mit, und Lambda führt sie mit serverloser Skalierung aus.
Die Abrechnung nach aktiver CPU-Nutzung ist die stille Schlagzeile: HTTP-Workloads verbringen viel Zeit mit dem Warten auf I/O, und die Abrechnung nach Wanduhrzeit berechnete Ihnen dieses Warten, selbst wenn die CPU im Leerlauf war. Die Abrechnung nach aktiver CPU-Nutzung gleicht die Kosten an den tatsächlich verbrauchten Rechenaufwand an, was die Wirtschaftlichkeit serverloser Web-Workloads erheblich verändert.
Lambda Web Functions schließen die Lücke zwischen „serverlos" und „gewöhnlichem Web-Framework". Wenn Sie Lambda bisher gemieden haben, weil Ihre Express-/Fastify-/Hono-/Next.js-App nicht in das Event-Handler-Modell passte – oder weil die Abrechnung nach Wanduhrzeit I/O-intensives HTTP teuer machte –, beseitigt dies beide Einwände. Das Framework, das Sie bereitstellen, behält sein normales Programmiermodell; Lambda führt es einfach aus.