Workload
Last updated
Was this helpful?
Last updated
Was this helpful?
Es gibt verschiedene AnsÀtze Workloads in AWS abzubilden. Mit Workloads meine ich Workflows, die das Business abbilden, z. B. einen Microservice oder einen Batch-Job.
Man hat 3 Optionen:
Compute Instanzen via EC2
Containers via
ECS - Elastic Container Service
Die AnsĂ€tze unterscheiden sich im wesentlichen im Abstraktionsgrad und das sorgt letztlich fĂŒr Unterschiede im Konfigurationsaufwand und der FlexibilitĂ€t - hier sollte man einen guten Trade-off finden. Man muss also die Anforderungen der Anwednung in verschiedenen Aspekten kennen (z. B. Performance, Ausfallsicherheit) und die eigenen Anforderungen hinsichtlich Developemnt/Betrieb (z. B. Know-How, Kosten, Maintenance) und gegeneinander abwĂ€gen. Es gibt immer verschiedene Optionen.
NatĂŒrlich kann ich einen Docker Container auf einer EC2 Instanz deployen. Allerdings bietet AWS mit EKS (via Fargate oder EC2) und ECS bereits fertige Lösungen, die neben dem Start auch noch weitere wichtige Aspekte (z. B. Konfiguration, Secret-Management, Skalierung, Health-Checks, Self-Healing) mitbringen. Deshalb macht es dann Sinn, sich fĂŒr einen höherwertigeren Ansatz zu entscheiden.
Serverless bedeutet hier nicht, dass es keine Server gibt - stattdessen muss man keine Server selbst managen ... das ĂŒbernimmt die AWS-Platform.
Das generelle Ziel des Cloudcomputings ist in der Anzahl der Ressourcen nicht limitiert zu sein und so Lastspitzen leicht ausgleichen zu können, ohne das a-priori planen zu mĂŒssen. Computing on-demand. Um dies kosteneffizient umsetzen zu können, ist elastische Skalierung (up and down) erforderlich.
Dieser Ansatz bildet die OnPrem gehostete Serverfarm (z. B. via VMWare) in der AWS Cloud ab. Deshalb war das der natĂŒrliche Einstiegpunkt, wenn man von OnPrem in die Cloud wechselte. Anwendungen waren meistens als langlaufende stateful Service-Anwendungen und liefen dauerhaft auf einer/mehreren physikalischen Instanzen.
Die Serverless-AnsĂ€tze liefern mittlerweile die Grundlage fĂŒr Event-Driven kurzlebigen Prozessierungen, die nach wenigen Sekunden oder Minuten beendet sind. Nichtsdestotrotz ist EC2 immer noch der unterliegende Building-Block, auf dem die anderen AnsĂ€tze basieren (als Backend sozusagen).
Der Nachteil von EC2 ist, dass hier nach Laufzeit (in AbhĂ€ngigkeit von der LeistungsfĂ€higkeit) der Instanz abgerechnet wird (Status Running). Auch wenn die Instanz nichts zu tun hat, kostet sie Geld. Das ist bei anderen Workload-Solutions (z. B. Serverless, Containers) kosteneffizienter, weil sie elastisches Scaling unterstĂŒtzten bzw. bereits eingebaut haben.
HĂ€ngt ein EBS-Volume an einer STOPPED Instanz, dann kostet das EBS Volume aber weiterhin.
Die wichtigste Entscheidung bei einer EC2-Instanz ist die Art von Instanz (z. B. t3.medium, a1.large):
Instanztyp (z. B. t3, a2) bestehend aus
Instanz-Family (z. B. t, a)
Generation (z. B. 3, 2)
InstanzgröĂe (z. B. medium, large)
Die Instanzen sind fĂŒr unterschiedliche Anwendungszwecke optimiert und haben unterschiedliche Kosten. Auf diese Weise kann man den Best-Fit (Features, Preis) finden und bei Bedarf ohne weitere Aufwand anpassen.
Bei einem "stop " wird die Instanz runtergefahren, d. h. der Memory geht verloren - bei einem stop-hibernate bleibt der Memory nach einem start erhalten. Hierzu muss die Instanz allerdings mit Hibernation-Support konfiguriert worden sein.
On-Demand Instanzen stehen solange zur VerfĂŒgung wie ICH sie nutzen will. Bei SPOT Instanzen könnte es passieren, dass sie wĂ€hrend der Nutzung gestopt werden, weil ein anderer Kunde mehr Ressourcen braucht und auch bereit ist mehr Geld zu zahlen. Die Anwendung, die auf einer solchen Instanz lĂ€uft, muss hierfĂŒr natĂŒrlich geeignet sein ... ganz grundsĂ€tzlich sollten das aber generell alle Anwendungen, denn es kann immer mal passieren, dass ein Server im laufenden Betrieb ausfĂ€llt (z. B. Stromausfall, Festplatte kaputt, Feuer). Mit SPOT Instanzen kann man viel Geld sparen - man gibt einen maximalen Preis an ... kann aber auch passieren, dass man eine solche Instanz nicht bekommt oder sie unter dem Hintern weggezogen bekommt.
Kann man ĂŒber ein attached ssh-Key-Pair bekommen ... geht aber auch direkt aus AWS Management Console via Cloud Shell.
Man sollte versuchen, ohne einen solche Zugriff auszukommen ... zumnindest wenn die Application, die man dort bereitstellt, einen gewissen Reifegrad hat. In Produktionsumgebungen ist es hÀufig sogar verboten auf diese Weise zuzugreifen. Dort hat man dann aber Monitoring-Lösungen, die bei der Fehlersuche helfen. Am besten man gewöhnt sich das gleich mal ab.
Hierbei handelt es sich um ein Shell-Script, das nach dem Boot-Vorgang gestartet wird.
eine EC2 Instanz muss einem VPC zugewiesen werden (jeder Account kommt mit einem VPC vorkonfiguriert, um den Einstieg zu erleichtern)
Container bieten den Vorteil, dass sie neben der Anwendung auch gleichzeitig die Laufzeitumgebung und Konfiguration (hÀufig injected) mitbringen und somit sehr leicht von einem Server auf einen anderen geschoben werden können. Genau das machen sich Container-Lösungen zu nutze ... sie starten auf verschiedenen Compute-Enheiten beliegig viele Container. Sie können beliebig von einem System (z. B. DEV Stage) auf ein anderes System (z. B. LIVE Stage) gebracht werden. Dabei skalieren sowohl die Compute-Einheiten als auch die Anzahl der Container einer Anwendung. Dadurch kann dieser Ansatz nahezu beliebig skalieren ... nur die Kosten limitieren es.
Containers sind deutlich leichtgewichtiger als EC2 Instanzen. Sie können innerhalb weniger Millisekunden gestartet werden. Der Startup einer EC2 Instanz dauert vielleicht 30-120 Sekunden und damit schneckenlahm. Hat man eine Anwendung die fĂŒr jede prozessierte Nachricht (Event-Driven-Applikation) einen neuen Container startet, dann macht das schon einen groĂen Unterschied ... es wĂŒrde nicht funktionieren, wenn man fĂŒr jede Nachricht eine neue EC2 Instanz starten mĂŒsste.
FĂŒr Container Deployments stellt Amazon zwei AnsĂ€tze bereit
ECS - Elastic Container Service
Beide lassen sich auf
selbst-gehosteten EC2 Instanzen
via (serverless) Fargate
betreiben.
Mit Fargate lassen sich Docker Container Images im Kontext von Amazon ECS und Amazon EKS deployen. Es ist ein managed Service und insofern auch serverless.
Serverless ist schon lÀnger ein Hype und tatsÀchlich hat es Vorteile hinsichtlich Wartung und Kosten, da die Bereitstellung von Ressourcen (vor der Serverless-Zeit per EC2-Instanz bereitgestellt) von Amazon erfolgt und man nur bezahlt was man nutzt.
Letztlich ist "serverless" ein wenig irrefĂŒhrend, denn auf unterster Ebene sind es dann doch Server, die genutzt werden. Allerdings wird dieses Layer von dem jeweiligen höherwertigen Layer (Lambda, Fargate) durch die AWS gemanaged. Durch den geringeren Aufwand auf Operating-Management (u. a. Patching, High-Availability, Skaling), kann man sich mehr auf die Applikation fokussieren. Den Komfort zahlt man allerdings muss weniger FlexibilitĂ€t.
Serverless erinnert an PaaS AnsÀtze, bei denen der Entwickler eine Artefakt bereitstellt, das dann auf einer Platform deployed wird.
Entscheidet man sich fĂŒr einen serverless Ansatz, dann hat man hohen Komfort (wenig Administrative TĂ€tigkeiten) aber auch weniger Kontrolle
WĂ€hrend der EC2-Ansatz der typische Einstiegspunkt fĂŒr Unternehmen ist, die schon auf OnPrem ihre Hardware selbst administriert haben und nun auf die Cloud umziehen wollen, ist der Serverless Ansatz der typische Einstiegpunkt fĂŒr Startups, die auf der grĂŒnen Wiese anfangen und sich auf ihre Features fokussieren wollen. Obwohl das hĂ€ufig so gelebt wird, sollte die man die Entscheidung fĂŒr den richtigen Ansatz von den Anforderungen abhĂ€ngig machen ... nicht von dem was man gerade hat - auch wenn das natĂŒrlich verlockend ist. KOmmen man von OnPrem, so sind die Anwendungen hĂ€ufig auf die "alte" OnPrem-Welt zugeschnitten. Macht man eine 1:1 Migration, dann bleiben dabei viele Vorteile der Cloud und der AWS Features auf der Strecke. Aspekte wie elastisches Scaling hat man hĂ€ufig OnPrem nicht ... darĂŒber macht man die Cloud aber erst bezahlbar.
Serverless Ansatz fĂŒr Containers.