Die Wahl zwischen Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Fargate, AWS Lambda und AWS Batch ist eine Entscheidung darüber, wo Code ausgeführt wird und wer die Verantwortung für den operativen Betrieb trägt. In diesem Kurs entwickeln wir einen wiederholbaren Entscheidungsrahmen, der die Anforderungen von Workloads mit Skalierungsverhalten, Fehlergrenzen, operativer Verantwortung und den Treibern der Gesamtkosten verknüpft. Wir vermeiden das Denken in reinen Service-Katalogen und begründen stattdessen jede Entscheidung fundiert anhand von Rahmenbedingungen und Nachweisen.
Definieren wir zunächst die Achse der Verantwortlichkeit, da sie die meisten Abwägungen erklärt. Operative Verantwortung bezeichnet die Zuständigkeit für das Patchen des Betriebssystems, die Verwaltung der Kapazität und den Betrieb des Schedulers, der Aufgaben auf Rechenressourcen verteilt.
Bei Amazon EC2 betreiben wir virtuelle Maschinen; wir wählen also das AMI, die Patch-Strategie und den Skalierungsansatz aus. Bei Amazon ECS oder Amazon EKS betreiben wir einen Orchestrator, der Container plant, müssen aber dennoch entscheiden, was die zugrundeliegende Kapazität bereitstellt. Bei AWS Fargate wird die Ebene der Container-Kapazität von AWS verwaltet, sodass wir uns auf Task-Definitionen und die Skalierung von Services konzentrieren, anstatt auf Node-Flotten. Bei AWS Lambda übernimmt AWS den Betrieb der Recheninfrastruktur und die Skalierung, während wir uns auf den Funktionscode und dessen Aufrufmodell konzentrieren. Bei AWS Batch übernimmt AWS die Warteschlangenverwaltung und die Zeitplanung (Scheduling) für Batch-Aufträge und kann diese auf Ressourcen von ECS, EKS, Fargate oder EC2 verteilen.
Betrachten wir nun im Überblick, wie sich die Verantwortlichkeiten bei diesen Optionen verlagern.
Wir können die Wahl der Rechenressourcen nun eher als Abgleich mit technischen Rahmenbedingungen denn als Debatte über persönliche Vorlieben betrachten. Das Ausführungsmodell bestimmt, ob eine Aufgabe als langlebiger Dienst, als ereignisgesteuerte Funktion oder als Job in einer Warteschlange mit definiertem Start- und Endpunkt ausgeführt wird.
Das Verkehrsmuster ist oft die erste Einschränkung, die ins Gewicht fällt. Spitzenlasten mit langen Leerlaufphasen begünstigen eher Modelle, die pro Anfrage abrechnen, während ein gleichmäßiger Datenverkehr eher für dauerhaft verfügbare Kapazitäten spricht, die eine hohe Auslastung gewährleisten.
Dauer und Zustandsverwaltung schränken die Auswahl schnell ein. AWS Lambda unterliegt einer maximalen Laufzeitbegrenzung (Timeout) von derzeit 900 Sekunden; daher werden länger laufende Aufgaben meist in Container oder Batch-Verarbeitungsprozesse verlagert. Zustandsbehaftete Workloads, die einen lokalen Zustand beibehalten oder eine spezifische Host-Konfiguration erfordern, eignen sich oft besser für Amazon EC2 oder Container auf EC2-Instanzen.
Auch die Latenzempfindlichkeit hat betriebliche Auswirkungen. Bei Request-Response-Abläufen sind das Risiko von Kaltstarts, die Netzwerkplatzierung und die Geschwindigkeit, mit der die Plattform parallele Kapazitäten bereitstellen kann, von Bedeutung. Bei asynchronen Abläufen stehen das Wachstum des Arbeitsrückstands (Backlog), das Wiederholungsverhalten sowie die Isolierung und erneute Ausführung bei Fehlern im Vordergrund.
Veranschaulichen wir uns, wie diese Anforderungskarten den technischen Rahmenbedingungen für Rechenressourcen zugeordnet werden.