Eine kurze Einführung in das Paradigma der Serverless-Architekturen – am Beispiel der AWS Cloud
Da das Schlagwort „serverlose Technologien“ im Kontext der Cloud Nutzung immer wieder genannt wird, fragen Sie sich möglicherweise, was den „serverlos“ in der Praxis genau bedeutet.
Es ist allgemein bekannt, dass man keine Rechenleistung (Compute-Workload) ohne einen physisch vorhandenen Computer bzw. Server erbringen kann. Das führt zu der Frage, wie spiegelt sich dies in den verschiedenen Serverless-Technologien wie Docker, Kubernetes und Function-as-a-Service (FaaS) wider?
Beginnen wir damit warum man diese Technologien überhaupt als „serverless“ bezeichnet, wenn doch immer noch ein Server zur eigentlichen Ausführung benötigt wird?
Ohne Software geht es nicht
Im Grunde genommen ist es aber ganz einfach: Es kommt auf den Betrachtungswinkel an.
In einer klassischen IT-Umgebung würde man einen Server bereitstellen, seine Anwendung dort installieren und diese dann dort ausführen lassen. Dabei muss man natürlich dafür sorgen, dass alle technischen Abhängigkeiten der betreffenden Anwendung (wie z.B. Sprachbibliotheken, Datenbanken, Visualisierungstools, usw.) auf dem betreffenden Server installiert sind.
Wenn ein neues Release der Anwendung verfügbar ist oder man weitere Ressourcen benötigt, weil das System zum Beispiel mehr Rechenleistung erbringen soll, muss ein Entwickler oder Administrator auf den Server zugreifen und dort die betreffende Software installieren. Das kann zwar mit Tools wie Configuration-Management, Continous-Delivery-Pipelines, zentralisiertem Logging, usw. vereinfacht werden, aber am Ende des Tages muss immer eine Person, also ein Entwickler oder Administrator, zumindest etwas Kenntnis über den betreffenden Server und seine darauf installierten Anwendungen haben. Nur dann ist sie in der Lage, im Falle, dass es technische Probleme gibt, nach einer Lösung zu suchen und diese zu beheben.
Container
An diesem Punkt müssen wir einen kleinen Abstecher in das grundlegende Konzept von Serverless machen – den sogenannten „Container“.
Ein „Container“ ermöglicht es eine Anwendung inklusive der benötigten Systemumgebung auszuliefern. Dies macht es überflüssig, anwendungsspezifische Abhängigkeiten separat zu installieren, da sie bereits zusammen mit der Anwendung als Image ausgeliefert werden.
Und daraus resultiert auch der große Vorteil von Containern: Sie laufen praktisch überall.
Mit dem Begriff „Container“ ist übrigens nicht unbedingt nur ein „Docker Container“ gemeint, sondern auch der gute alte LXC Container (worauf Docker basiert) oder jede andere Container-Technologie.
Die Nutzung von Containern verschiebt die Verwaltung der Abhängigkeiten und die Bereitstellung der für die Ausführung der Anwendung erforderliche Umgebung vom Administrator des Servers hin zu den Entwicklern der Anwendung.
Ich bin mir sicher, dass auch Ihr Betriebsteam ein Mitspracherecht haben will und sollte. Im Wesentlichen ist dies der Punkt, an dem Sie eine DevOps-Kultur oder noch besser eine DevSecOps-Kultur benötigen.
Container können verwendet werden, ohne große Änderungen in der klassischen Umgebung umzusetzen. Es ändern sich lediglich ein paar Zuständigkeiten.
Geht man einen Schritt weiter bei der Verwendung von Serverless-Technologien, verschiebt sich die Interaktion zwischen Entwickler und Anwendung vom Server zu dem gewählten Orchestration-Tool (ich verwende für den Rest des Artikels Kubernetes als Beispiel, aber dasselbe gilt auch für andere Tools). Es gibt kein direktes Deployen von Anwendungen auf dem Server oder manuelle Konfiguration von Netzwerk-Komponenten, z.B. ein Load-Balancer. Man übergibt Kubernetes einfach eine neue Konfiguration und die neuste Version der Anwendung wird auf dem verfügbaren Server (Node) oder auf mehreren Servern (Nodes) ausgeliefert.
Doch hier sind sie ja schon wieder, diese verflixten Server!?!
Ohne Server geht es nicht
Die Verwaltung dieser Server häng davon ab ob man sein Kubernetes-Cluster On-Premise oder in der Cloud als Managed-Service betreibt. Das macht einen großen Unterschied, wenn es darum geht, sein Cluster zu verwalten.
Läuft es On-Premise, so muss man das Kubernetes-Cluster selbst verwalten und pflegen. Die Systemadministratoren müssen sich nicht länger mit dem Verwalten einzelner Anwendungen beschäftigen, sondern nur um das Cluster (oder mehrere Cluster) und alle dazugehörigen Server kümmern.
Wenn Kubernetes als Managed-Service in einer Cloud wie Amazon (AWS) Elastic Kubernetes Service (EKS), Google (GCP) Google Kubernetes Engine (GKE) oder Azure Kubernetes Service (AKS) läuft, reduziert sich der Verwaltungsaufwand aufgrund der automatischen Updates und des Betriebs der Master-Nodes durch den Provider drastisch. Das einzige, was von dem Prozess übrig bleibt, ist die Sicherheitskonfiguration der Umgebung.
In beiden Fällen hat man immer noch Zugriff auf die Server VM-Instanzen, auch wenn man einen Cloud-Service verwendet, da die Server als ganz normale virtuelle Maschinen bereitgestellt werden. Aber nachdem das Cluster eingerichtet ist, kann man nach Belieben Server zum Cluster hinzufügen und das Bereitstellen geschieht automatisch. In der On-Premise Variante kommt man um den normalen Verwaltungsprozess nicht herum.
Also hat man bei einem verwalteten Kubernetes-Service zwar immer noch Server aus denen der Cluster besteht und man verwaltet lediglich, wie stark automatisiert es skaliert, aber die Server muss man nicht direkt verwalten.
Somit sind wir schon ein wenig weiter mit unserer Erwartung an eine Serverless-Infrastruktur: Der Entwickler sieht den Server nicht mehr und man muss ihn auch nicht mehr verwalten.
Weg mit der Zuständigkeit
Aber können wir noch ein Stück weiter gehen und Server komplett aus unserer Zuständigkeit entfernen?
Ja, das können wir! Da jedoch das Rechnen ohne Computer / Server nicht möglich ist, ist dies nur durch Dienste möglich, bei denen die untergeordneten Rechenressourcen von jemand anderem verwaltet werden und entsprechend abstrahiert sind.
AWS bietet derzeit den Fargate-Service an, mit dem Sie Docker-Container ausführen können, ohne Compute-Instances (EC2) bereitzustellen, auf denen die Container ausgeführt werden. Dies bedeutet, dass Sie Ihre Docker-Container ausführen können, ohne jemals einen Server zu sehen oder zu verwalten. Es besteht auch die Möglichkeit, dass AWS in Kürze eine Option anbietet, dass EKS-Cluster von Fargate unterstützt werden (https://github.com/aws/containers-roadmap/issues/32). Dies würde bedeuten, dass auch Server (EC2-Instanzen) aus Ihrem EKS-Cluster wegfallen.
Eine andere Möglichkeit, die Server, die Sie mit Rechenleistung versorgen, vollständig loszuwerden, ist FaaS. AWS bietet den Dienst AWS Lambda an, in dem die Anwendung nur dann ausgeführt wird, wenn sie tatsächlich gebraucht wird. Der Service wird ausgeführt, wenn er ausgelöst wird. Wie eine Funktion ausgelöst werden kann, hängt von dem von Ihnen ausgewählten Cloud-Anbieter ab, da diese alle unterschiedliche Funktionsumfänge in diesem Bereich haben. Die Verwendung des systemeigenen Dienstes der Plattform für Nachrichtenwarteschlangen und HTTPs funktioniert mit allen Anbietern. FaaS führt Ihre Anwendung auch in einem Container aus – dies ist möglicherweise nicht direkt ersichtlich, wenn Sie die Dienste verwenden, da Sie kein Container-Image bereitstellen. Ihre Anwendung wird jedoch in einem Container ausgeführt, um sie zu isolieren. GCP bietet außerdem auch einen Dienst „Cloud Run“ an, welcher zwar Docker Container unterstützt aber aktuell nur über einen HTTPS Aufruf getriggert werden kann.
Fazit
Sie können nur dann wirklich „serverlos“ werden, wenn Sie Managed-Services von Cloud-Providern wie z.B. AWS verwenden, welche die Interaktion mit den Servern so weit abstrahieren, dass Sie diese nicht mehr direkt verwalten müssen.
Das bedeutet in der Regel, dass die Architektur einer Anwendung entsprechend ausgelegt werden muss. Ja, das macht zunächst ein wenig Arbeit, aber die gesparten Kosten sowohl bei der Administration der Anwendung als auch beim Betrieb in der Cloud machen sich erfahrungsgemäß recht schnell bezahlt.
Gerne beraten Sie unsere Spezialisten zum Thema Serverless mit AWS und unterstützen Sie bei Ihren IoT-Projekten.
Nehmen Sie Kontakt mit uns auf:
