Weiter zum Inhalt

Serverless Architecture – Was ist das und warum ist sie relevant?

Die Serverless-Technologie ist in aller Munde, und die Cloud-Anbieter drängen mit Nachdruck auf ihre Einführung. Die Frage ist, ob es sich dabei um einen überbewerteten Hype handelt oder ob es tatsächlich etwas zu gewinnen gibt, wenn man auf dieses Modell umsteigt. In diesem Artikel gehen wir kurz auf einige Punkte ein, die Ihnen eine klarere Vorstellung vom Potenzial der Serverless Architektur für heute und die Zukunft vermitteln.

Die Entwicklung von Technologien, die von Unternehmen zur Bereitstellung von Anwendungen genutzt werden.

Serverless behauptet, in vielen Aspekten der Anwendungsentwicklung und -bereitstellung ein klarer Sieger zu sein. Wir haben eine Auswahl davon getroffen, um einen Vergleich zwischen dieser neuen Technologie und zwei traditionelleren Ansätzen zu ermöglichen, nämlich der Virtualisierung (EC2s) und der Containerisierung (Kubernetes) auf der AWS-Plattform. Wir werden jede Technologie anhand folgender Kriterien vergleichen:

  • Kosten
  • Skalierbarkeit
  • Benutzerfreundlichkeit
  • Nachhaltigkeit

Gute Nachrichten für das Endergebnis – Kostenvergleich

Die Kosten sind der Aspekt, bei dem Serverless im Vergleich zu den Alternativen wirklich glänzt. Es hat sich gezeigt, dass serverlose Anwendungen in einer Vielzahl von Fällen eine geringere finanzielle Belastung darstellen als ihre Gegenstücke. Bevor diese nachgewiesen werden können, muss man zunächst verstehen, was mit dem Begriff „Serverless“ gemeint ist und warum es sich um ein Substantiv und nicht um ein Adjektiv handelt.

Da es beim Serverless-Ansatz darum geht, Code auszuführen, ohne die eigene Hardware verwalten zu müssen, ersetzen wir im Wesentlichen die Idee eines „always-on“-Servers durch ereignisgesteuerte Prozesse, oder besser gesagt, wir abstrahieren sie. Auf diese Weise lassen sich die Kosten bei den meisten Anwendungen, die keine rechenintensiven Arbeitslasten erfordern oder bei denen eine umfangreiche Verarbeitungsleistung für die Bearbeitung großer Datenmengen erforderlich ist, drastisch senken.

Und warum? Weil der Hauptvorteil von Serverless-Angeboten das Pay-as-you-go-Modell ist, das dem Eigentümer nur den Speicher, die Rechenleistung oder die Daten in Rechnung stellt, die er tatsächlich nutzt. Wenn die Anwendung ruht und nicht verwendet wird, kostet sie den Eigentümer im Grunde nichts (im Gegensatz zu einem Kubernetes-Cluster oder EC2-Instanzen). Der Preis für AWS Lambda richtet sich beispielsweise nach der Anzahl der Aufrufe (0,20 $/1 Mio. Anforderungen) und den Kosten für die während dieser Zeit genutzte Rechenleistung (0,0000166667 $ pro GB-Sekunde). Die Ausführung eines 128-MB-Lambdas für 100 ms würde Sie also in der irischen Region $0,00000041 kosten.

Nehmen wir eine einfache Webanwendung, in diesem Fall eine Wahlanwendung. Traditionell würden wir einen Kubernetes-Cluster auf EKS laufen lassen, der Pods verwaltet, die die verschiedenen Anwendungen enthalten, die für das Funktionieren der Webanwendung von Anfang bis Ende erforderlich sind. Diese Pods können, je nach Größe, auf demselben Knoten liegen oder auch nicht. In jedem Fall benötigt eine solche Webanwendung eine leistungsstarke EC2-Instanz, damit 5 verschiedene Anwendungen kontinuierlich ausgeführt werden können.

Eine Serverless-Implementierung der gleichen Webanwendung würde dagegen Komponenten enthalten, die nicht kontinuierlich laufen, so dass nur ein Bruchteil der Rechenleistung erforderlich ist. Außerdem würde eine serverlose Implementierung Komponenten enthalten, die besser für den Betrieb in Cloud-Umgebungen optimiert sind.

Architekturdiagramm für eine einfache Abstimmungs-Webapp, das die Unterschiede zwischen einem Kubernetes- (erster) und einem Serverless-Ansatz (zweiter) zeigt.

Stellen Sie sich vor, diese Anwendung erhält 50 Sitzungen pro Tag. Mit dem von Xavier Lefèvre entwickelten Kostenrechner, der auf dem offiziellen Kostenrechner von AWS basiert, würde diese Art von Anwendung 0,50 $ pro Monat kosten, wenn sie mit der Serverless-Architektur entwickelt wird, kostenlose Ebene inklusive. Das ist minimal im Vergleich zu den Kosten, die man bräuchte, um die kleinste EC2-Instanz einen ganzen Monat lang zu betreiben (t3a.nano zu 3,43 $, was immer noch nicht ausreichen würde, um den gesamten K8s-Cluster zu betreiben). Noch bevor man die Kosten für die selbstverwaltete Überwachung und Skalierbarkeit berücksichtigt, kann man bereits das Potenzial für weitere Kosteneinsparungen in größerem Maßstab erkennen.

Ein weiterer Vorteil von Serverless ist, dass es eine granulare Kostenkontrolle über jede Funktion und jeden Teil der Architektur ermöglicht, die Sie bereitstellen, und so effizientere FinOps ermöglicht.

Aber wird es skalierbar sein? 

Die Skalierbarkeit ist ein weiteres Aushängeschild der Serverless-Architektur, das die in sie gesetzten Erwartungen tatsächlich erfüllt. Und warum? Nun, gehen wir zurück zum Beispiel der Wahl-Webapp. Wenn in Kubernetes die Last steigt und einzelne Pods belastet werden, werden automatisch mehr Pods erstellt, um den Bedarf zu decken (allerdings nur, wenn Sie ein Deployment/ReplicaSet angegeben haben). Das bedeutet, dass neue Container auf neuen Nodes aufgesetzt und mehr EC2-Instanzen gestartet werden, mit all dem damit verbundenen Overhead.

Serverlose Komponenten wie Lambdas hingegen ermöglichen eine große Anzahl gleichzeitiger Ausführungen, was bedeutet, dass es keine Wartezeit für das Einschalten virtueller Maschinen gibt und die Skalierung nahezu sofort erfolgt. In Irland werden während eines Burst 3000 Lambdas gleichzeitig gestartet, und AWS fügt jede Minute Kapazität für 500 weitere hinzu. Und das alles, ohne dass Sie etwas dafür tun müssen.

Der Hauptunterschied besteht darin, dass sich der Entwickler bei einem Serverless-Ansatz nicht um die Skalierungsrichtlinien kümmern muss (da diese vollständig vom Cloud-Anbieter verwaltet werden), während dies bei Containern nicht der Fall ist, da diese Automatisierung im Voraus eingerichtet und konfiguriert werden muss.

Berücksichtigung der Benutzerfreundlichkeit

Serverless eignet sich besonders für Anwendungsfälle, bei denen die Zeit bis zur Markteinführung wichtig ist und das Entwicklungsteam keine operativen Kenntnisse hat oder keine Zeit, sich mit der zugrunde liegenden Infrastruktur zu befassen. Das bedeutet, dass Entwickler mehr Zeit damit verbringen können, sich auf die Anwendung zu konzentrieren, anstatt die Infrastruktur zu implementieren, die sie unterstützt.

Mit Serverless können Entwickler Anwendungen schnell erstellen. Serverlose Komponenten abstrahieren die Infrastruktur und übergeben sie zur Verwaltung an AWS. Dies ermöglicht es Entwicklern, die wenig oder gar keine Erfahrung mit AWS haben, schnell mit der Entwicklung zu beginnen. Das bedeutet, dass sie sich auf das konzentrieren können, was ihnen wichtig ist, und sich nicht um Upgrades und Patches für die Server kümmern müssen.

Die schnelle Entwicklung wird auch durch Lambda erleichtert, das eine Vielzahl von Programmiersprachen unterstützt, so dass Entwickler mit unterschiedlichen Fähigkeiten den Dienst nutzen können.

Lambda ist jedoch nicht die einzige serverlose Alternative, die die Markteinführungszeit auf ähnliche Weise verkürzt. Fargate ist ein weiteres AWS-Angebot, das es Ihnen ermöglicht, Kubernetes auf einer Pay-as-you-go-Basis weiter zu nutzen, ohne dass Sie Ihre Anwendung radikal neu entwickeln müssen, um sie an eine neue Architektur anzupassen. Dies ist eine sehr beliebte Option für Legacy-Anwendungen, da sie viel einfacher zu verwalten ist als eine herkömmliche EC2-Instanz oder ein EKS-Cluster.

AWS kümmert sich um die Wartung der zugrundeliegenden Infrastruktur für Fargate, so dass Sie sich nicht mit dem Aufwand für Patches und Updates befassen müssen. Wenn es eine Sicherheitslücke gibt, müssen EC2-Benutzer diese manuell schließen, während Fargate-Benutzer sich keine Sorgen machen müssen, da dies AWS überlassen wird. Aus diesem Grund wird Fargate als die sicherere Option angesehen.

Im Allgemeinen bietet Fargate keine nennenswerten Kosteneinsparungen gegenüber EC2/EKS, aber im richtigen Anwendungsfall kann Fargate große Vorteile bieten. Fargate bietet ein Pay-as-you-go-Modell, bei dem die Abrechnung nach der Anzahl der CPU-Kerne und des Arbeitsspeichers pro Sekunde erfolgt, d. h. Sie zahlen nur für das, was Sie tatsächlich nutzen. Bei EC2 kann es vorkommen, dass Benutzer ihre Instanzen unterdotieren, d.h. sie haben nicht genügend Instanzen für den Bedarf ihrer Anwendung, oder sie überdotieren ihre Instanzen, d.h. sie zahlen zu viel für die genutzten Ressourcen. Fargate hingegen bietet eine automatische Skalierung, die dieses Problem vollständig beseitigt (und damit die Nutzung wesentlich erleichtert).


Visualisierung einer CI/CD-Pipeline mit mehreren Konten, die nur AWS Serverless-Komponenten zur Bereitstellung von Änderungen verwendet.

AWS bietet auch eine Reihe von Serverless-Entwickler-Tools zum Aufbau eines CICD-Workflows für Ihre Anwendungen, was wiederum die Markteinführung beschleunigt. Zu diesen Services gehören CodeCommit (Versionskontrolle), CodeBuild (kontinuierliche Integration), CodeDeploy (Bereitstellungsservice), CodePipeline (kontinuierliche Bereitstellung) und CodeArtifact (Artefakt-Repository). Der Vorteil dieser vollständig von AWS verwalteten Services ist, dass sie im Vergleich zu Alternativen wie Jenkins und Gitlab nur eine minimale Einrichtung erfordern. Im obigen Diagramm können Sie sehen, wie diese Dienste zusammen integriert werden können und wie die Architektur aussehen würde.

NACHHALTIGKEIT

Nachhaltigkeit ist ein wichtiger Aspekt, den Sie bei der Entwicklung von Lösungen im Auge behalten sollten, da die Nachhaltigkeit in der Cloud in der Verantwortung des Nutzers liegt. Die Ausführung einer Anwendung in einer serverlosen Architektur kann ein effizienter Weg sein, um den CO2-Fußabdruck Ihrer Workloads zu verringern.

Vergleichen wir einmal, wie sich der CO2-Fußabdruck einer Anwendung auf EC2 und Lambda unterscheidet. Wenn Sie eine Anwendung auf einer EC2-Instanz ausführen, kann es Zeiten geben, in denen die Instanz im Leerlauf ist. Das bedeutet, dass die Instanz nicht ausgelastet ist und Energie verschwendet.

Die Ausführung über Lambda ist energieeffizienter. Wenn ein Lambda ausgelöst wird, läuft es innerhalb einer microVM auf einer von AWS verwalteten EC2-Instanz. Wenn die Ausführung des Lambdas beendet ist, wird die microVM durch eine andere ersetzt, damit ein anderes Lambda ausgeführt werden kann. Dieser Ansatz gewährleistet eine höhere Auslastung der vorhandenen Ressourcen im Gegensatz zur Nutzung eines Teils der neuen Ressourcen.

Ist es also an der Zeit, serverless zu werden?

Nach dem Vergleich und der Gegenüberstellung der Architekturlösungen lässt sich sagen, dass Serverless nicht für alle Anwendungsfälle geeignet ist und die Containerisierung für bestimmte Anwendungen die beste Option bleibt.

In der Tat gibt es viele Fälle, in denen Serverless nicht die richtige Lösung für ein Problem ist und am Ende mehr kosten kann als die älteren Alternativen. Beispiele hierfür sind Anwendungen, bei denen Java/JVM zum Einsatz kommt, langwierige Aufgaben erforderlich sind oder bei der Erstellung von Anwendungen, die Zugang zu APIs auf niedriger Ebene benötigen (z. B. Thread-Kontrolle).

Darüber hinaus können bestimmte Unternehmen (z. B. Finanzdienstleister oder staatliche Organisationen) aufgrund gesetzlicher Bestimmungen nicht in der Lage sein, Software und Hardware zu nutzen, die von mehreren Kunden gemeinsam verwendet werden. Serverlose Anwendungen sind in der Regel nicht auf dedizierten Hosts verfügbar und wären daher für diese Anwendungsfälle ungeeignet.

Wenn Serverless jedoch richtig implementiert wird, bietet es erhebliche Kosteneinsparungen gegenüber herkömmlichen Ansätzen und positioniert sich nicht nur als echte Alternative, sondern auch als eine, die erhebliche Verbesserungen gegenüber den aktuellen Technologien bietet.

Wenn Sie weitere Informationen oder Beratung darüber wünschen, wie Sie mit Serverless-Architekturen Kosten sparen können – und Kohlenstoff – kontaktieren Sie uns hier.

Erfahren Sie mehr über unsere Partnerschaft mit AWS.