Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Die Wahl der Infrastrukturarchitektur ist keine Frage technologischer Überlegenheit, sondern das Ergebnis mathematischer Berechnungen des Traffic-Profils. Ein bekanntes Beispiel ist das Team von Amazon Prime Video, das nach der Verteilung von Videokontroll-Diensten auf zahlreiche AWS Lambda-Funktionen und Step Functions mit explodierenden Kosten konfrontiert war. Da die Kosten für Zustandsübergänge bei steigendem Traffic linear in die Höhe schossen, migrierten sie die Logik zurück auf In-Memory-Prozesse in einzelnen Computing-Knoten innerhalb einer Amazon ECS-Container-Umgebung. Das Ergebnis war eine Senkung der gesamten Infrastrukturkosten um 90 %.
Der Kosten-Break-even-Punkt zwischen Serverless-Funktionen und Container-Runtime ist klar definiert. Unter der Annahme einer durchschnittlichen Antwortlatenz von 118 ms bei AWS Lambda und einer Speicherzuweisung von 1 GB sowie eines AWS Fargate-Containers als Alternative, der zur Gewährleistung der Hochverfügbarkeit mit 2 Tasks (Spezifikation: 2 vCPU, 4 GB RAM) dauerhaft betrieben wird, liegt der Break-even-Punkt bei etwa 96 Millionen Anfragen pro Monat. Unterhalb dieser Schwelle ist das verbrauchsbasierte Abrechnungsmodell von Serverless vorteilhaft, doch sobald diese Marke überschritten wird, steigt die Kosteneffizienz der Fargate-Container-Runtime, bei der Ressourcen vorab reserviert und als Fixkosten betrieben werden.
Bei Architekturen mit Dauerbetrieb müssen für eine exakte Break-even-Analyse unbedingt die Netzwerkkosten einbezogen werden, die oft 30 % der Gesamtrechnung ausmachen. Dazu gehören NAT-Gateway-Gebühren bei Isolierung der Container in privaten Subnetzen (0,045 USD pro Stunde, ca. 32,40 USD pro Monat bei einer einzelnen Availability Zone), Grundgebühren für den Application Load Balancer (16,20 USD pro Monat) sowie Kosten für feste öffentliche IP-Adressen (3,60 USD pro Monat und Task).
Die Berechnungsformel zur Bewertung einer Infrastrukturmigration mittels Tabellenkalkulation sieht wie folgt aus:
![Cloud-Anbieter verändern sich RASANT [ERNEUT HOCHGELADEN]](https://i.ytimg.com/vi/UVz8_JljpGQ/hqdefault.jpg)
=( (R / 1000000) * Grundpreis_pro_Aufruf ) + ( R * D * (M / 1024) * Preis_pro_GB_Sekunde )=( Anzahl_Dauerbetrieb_Container * ( (vCPU_Anzahl * Preis_pro_vCPU_Stunde) + (Speicher_GB * Preis_pro_Speicher_Stunde) ) * 720 ) + Fixkosten_InfrastrukturWenn Geschäftslogik eng an proprietäre Cloud-SDK-Bibliotheken oder spezifische Laufzeit-Schnittstellen gekoppelt wird, begibt man sich in eine Abhängigkeit von der jeweiligen Plattform. Ein häufiger Fehler ist das Injizieren eines Express.js-Webserver-Pakets in die AWS Lambda-Laufzeitumgebung und dessen Kapselung mittels einer Adapter-Bibliothek (z. B. @codegenie/serverless-express), um es mit API Gateway Proxy-Ereignissen zu verknüpfen. Diese Struktur verschwendet CPU-Ressourcen der FaaS-VM, da bei jeder Anfrage eine virtuelle Socket-Stream-Emulation und Puffer-Umwandlung erzwungen wird. Zudem vergrößert es die node_modules-Paketgröße, was Kaltstarts begünstigt und eine Plattformmigration erschwert.
Um dieses Kopplungsrisiko zu umgehen und die Migrationsdauer auf andere Clouds um 80 % zu verkürzen, sollte die Hexagonale Architektur (Hexagonal Architecture) als Designprinzip für das Domain-Layout verwendet werden. Dabei wird die Kern-Geschäftslogik (die Domain-Ebene) von externen Kommunikationskanälen wie API Gateway, Datenbank-Engines oder Message Queues entkoppelt. Die Domain sollte nur von abstrahierten Schnittstellen, den sogenannten Ports, abhängen, während die konkrete Implementierung der Infrastruktur durch Adapter-Komponenten erfolgt, was ein austauschbares Plugin-Design ermöglicht.
Zur Steigerung der Portabilität kann der AWS Lambda Web Adapter (LWA) eingesetzt werden. Hierbei wird lediglich eine Zeile für die Binary-Layer-Einbindung in die Dockerfile-Build-Spezifikation hinzugefügt: