Von der serverbasierten zur serverlosen Umgebung

Der Austausch von Informationen braucht einen Server.

Stellen Sie sich vor: Sie suchen bei Google nach einem Thema und erhalten eine Liste von Suchergebnissen zurück. Im Hintergrund verarbeitet ein Server – nichts anderes als ein weiterer Computer – diese Anfragen und liefert Ihnen die Daten über ein Netzwerk zurück.

In der heutigen Ära der digitalen Revolution arbeitet jedes Unternehmen wie ein Softwareunternehmen: Eine Vielzahl von Anwendungen läuft, um Geschäftsprozesse zu beschleunigen und das Unternehmen im Wettbewerb zu halten.

Die Architektur von Server-Deployments hat einen weiten Weg zurückgelegt: von riesigen Bare-Metal-Servern, bei denen Entwickler die gesamte dahinterliegende Infrastruktur im Blick behalten mussten, bis hin zum serverlosen Deployment, bei dem nur noch Funktionen als Service bereitgestellt werden und der Anbieter die komplette Einrichtung und den Betrieb der Server übernimmt.

Sehen wir uns die Entwicklung von serverbasiertem Computing hin zu serverlosen Functions as a Service genauer an.

Serverbasiertes Computing

Diese Server, auch Bare-Metal-Server genannt, werden in Rechenzentren in Racks eingebaut. Sie stellen Rechenressourcen wie CPU, Arbeitsspeicher, Storage und Netzwerk bereit und laufen drei bis fünf Jahre, bevor neuere Hardware sie ersetzt.

Für die Konfiguration der Anwendungen braucht es einen dedizierten Administrator. Er installiert das Betriebssystem auf der Hardware und muss dafür sorgen, dass es über die gesamte Lebensdauer des Servers hinweg aktuell bleibt, um Risiken zu minimieren.

Die Kapazität dieser Bare-Metal-Server wird vor der Installation geschätzt, und der komplette Deployment-Ablauf vom Kauf über die Lieferung bis zur Installation dauert rund sechs Wochen.

Was die Skalierbarkeit dieser Server angeht: Sie sind durchaus skalierbar, und zwar vertikal wie horizontal.

Vertikale Skalierung bedeutet, dass Sie die Rechenressourcen (CPU, Arbeitsspeicher, Storage und Netzwerk) eines Servers während seiner Lebensdauer aufrüsten. Das ist allerdings mühsam und teuer, weil der Server dafür offline gehen muss und der Ablauf derselbe ist wie beim ursprünglichen Deployment nach dem Kauf.

Horizontale Skalierung ist praktikabler, denn dabei werden dem Verarbeitungspool oder dem Datenbank-Cluster weitere gleichartige Server hinzugefügt. Da die neuen Server jedoch zu den bestehenden hinzukommen, entsteht ein Mix aus alten und neuen CPU-Generationen, was die neueren Server ausbremst.

Serverbasiertes Computing war lange der Standard. Die Kosten für das Hoch- und Herunterskalieren der Server und die enormen Ressourcen, die der Betrieb von Anwendungen, Datenbanken und Diensten verschlingt, haben die Verbreitung jedoch erheblich gebremst.

Virtuelle Maschinen oder VMs

Was macht eine virtuelle Maschine?

Um die Skalierungsgrenzen und den massiven Ressourcenverbrauch des serverbasierten Computings zu überwinden, entstand die eher innovative Idee, mehrere Maschinen auf einem einzigen physischen Server zu virtualisieren.

Es gibt einen physischen Server, also eine Hardware beziehungsweise einen Host, und auf diesem Host laufen mehrere virtuelle Maschinen gleichzeitig. Stellen Sie sich vor, Sie ließen Windows 10 und Windows XP zugleich auf Ihrem PC laufen: dieselbe Hardware, aber zwei unterschiedliche Softwarestände gleichzeitig.

Ein Hypervisor, der auf dem Betriebssystem des Hosts installiert ist, sorgt dafür, dass die Host-Ressourcen effizient auf alle VMs verteilt werden und dass keine VM die Daten einer anderen lesen kann, obwohl sie auf demselben Host liegen.

Was macht eine virtuelle Maschine besser als einen physischen Server?

Im Vergleich zum serverbasierten Computing sind virtuelle Maschinen skalierbar, einfach zu sichern und wiederherzustellen und erlauben Live-Migrationen, bei denen laufende virtuelle Maschinen ohne Ausfallzeit von einem Host auf einen anderen umziehen.

Auch VMs haben ihre Nachteile, was Zeit und Budget angeht,

Ein Virtualisierungspool mit Hunderten oder Tausenden virtuellen Maschinen, die alle unterschiedliche Betriebssysteme und Software nutzen, braucht regelmäßige Updates und Patches.
Diese Updates muss entweder ein Administrator einspielen, was zeitaufwendig ist, oder eine Automatisierungssoftware, die eher teuer ist.
Weil ein Teil dieser Virtualisierungspools für die Wartung der Betriebssysteme und Anwendungen der VMs gebunden ist, sinkt ihre Effizienz erheblich – und jedes Update verbraucht weitere Ressourcen.
Ist eine VM für Hochverfügbarkeit konfiguriert, läuft permanent ein Backup-Host für den Fall, dass der primäre Host ausfällt. Das kostet Zeit, Geld und Ressourcen, und das gilt auch für automatisches Resource Scheduling.
Zusätzliche Backup-Server lassen sich vermeiden, indem Sie VMs in der Cloud hosten, allerdings stehen dort manche Funktionen wie Live-Migrationen nicht zur Verfügung.

Trotz dieser Nachteile sind virtuelle Maschinen weiterhin die erste Wahl, wenn Sie alte Anwendungen oder Software von Drittanbietern betreiben, die jahrelang weitgehend unverändert läuft. In solchen Fällen ist Virtualisierung die deutlich günstigere Option.

Container

Virtuelle Maschinen waren übermäßig überladen, und für jede Anwendung erneut ein Gastbetriebssystem zu installieren – selbst für ähnliche Anwendungen – wurde zu einer zeitraubenden Aufgabe. Das Ergebnis war ein Server, der nur ein Zehntel seiner Leistungsfähigkeit erreichte, weil der Speicherplatz von Gastbetriebssystemen und weiteren Abhängigkeiten belegt war.

Container dagegen bieten alle Vorteile virtueller Maschinen, etwa den getrennten Betrieb auf demselben Host. Statt für jede Anwendung ein Gastbetriebssystem zu installieren, werden Container vor dem Deployment als Container-Images bereitgestellt.

Diese Container-Images sind Softwarepakete, die den Anwendungscode, die Bibliotheken und alle weiteren Abhängigkeiten gebündelt enthalten.

Sie fragen sich vielleicht, wo das Gastbetriebssystem bleibt: Container nutzen den Kernel des Host-Betriebssystems, sodass sich ein eigenes Gastbetriebssystem pro Anwendung erübrigt.

Statt eines Hypervisors gibt es eine Runtime-Engine beziehungsweise einen Container-Host, die Docker Engine (sofern Sie Docker zur Virtualisierung einsetzen). Werden Container-Images auf der Docker Engine ausgerollt, werden aus ihnen Container.

Um die containerisierten Anwendungen zu verwalten – also ihr Deployment zu orchestrieren, die Laufzeit zu steuern, die geteilten Ressourcen zu bewerten und so weiter – kommt das Orchestrierungssystem Kubernetes zum Einsatz. Kubernetes sorgt für Anwendungssicherheit, automatisiert das Deployment, skaliert Anwendungen, erlaubt das Clustering von Containern und mehr.

Container sind beliebt, weil

sie sich sowohl on-premise als auch über Cloud-Dienste wie AWS Fargate innerhalb von Minuten automatisch skalieren lassen.
ein Load Balancer genügt, um Container je nach eingehenden Anfragen hoch- und herunterzuskalieren.
sich die Anwendungen wiederverwenden und als Microservices einsetzen lassen.
agiles DevOps mit Containerisierung leichter fällt und Anwendungen ohne Bugs und technische Fehler ausgerollt werden können.
sie im Vergleich zu einer virtuellen Maschine weniger Rechenressourcen verbrauchen.

Container wirken wie die perfekte Weiterentwicklung des physischen Servers – aber nein! Auch sie haben ein paar Grenzen.

Es müssen immer zwei Container laufen, um eingehende Anfragen zu bedienen, und zwar auch dann, wenn gar keine Anfragen eintreffen. Für den Betrieb einer Anwendung als Container fallen also immer Grundkosten an.
Container verkraften einen üblichen Anstieg eingehender Anfragen, weil sie bis 80 Prozent Auslastung laufen und immer Reserve bleibt, um weitere Container zu starten. Bei einem plötzlichen Anstieg – etwa von 1 auf 100 oder 1.000 – überlastet der Container jedoch und antwortet nicht mehr, bis zusätzliche Server bereitstehen.
Ein weiterer erheblicher Nachteil: Während eines solchen Lastanstiegs gehen zusätzliche Anfragen verloren, weil die Anwendungen nicht erreichbar sind.

Serverless oder Function as a Service

Jede andere Deployment-Architektur verlangte den Betrieb mindestens eines Servers, unabhängig davon, ob Anfragen eintrafen oder nicht. Das verursachte hohe Wartungskosten, und Skalierbarkeit war in allen bisher genannten Serverumgebungen ein Dauerthema.

Beim Ausrollen von Software müssen Sie stets an Wartung und Administration der Server denken – und nicht nur an die Anwendungen, die Sie entwickeln.

Um diese Sorgen zu entschärfen, sind zahlreiche Cloud-Dienste entstanden: Infrastructure as a Service (IaaS) abstrahiert die zugrunde liegende Hardware vom Software-Deployment, Platform as a Service (PaaS) abstrahiert Hardware und Software, sodass sich Entwickler ausschließlich auf die Anwendungsentwicklung konzentrieren können, und Software as a Service (SaaS) stellt Nutzern fertige Anwendungen in der Cloud bereit.

Darüber hinaus ist mit FaaS oder Functions as a Service in jüngerer Zeit ein Modell entstanden, das sämtliche Schichten des darunterliegenden Stacks einschließlich der Anwendungsschicht abstrahiert, sodass sich Entwickler allein auf die Funktionen dieser Anwendungen konzentrieren können.

Diese Funktionen werden in der Cloud-Umgebung ausgeführt, ohne dass Nutzer irgendetwas verwalten müssen! Mit „irgendetwas“ meinen wir den gesamten Stack: von den darunterliegenden Anwendungen über Betriebssysteme und Server bis hin zu Rechenzentren und allem Weiteren.

Konkrete Anfragen eines Nutzers gehen an ein API-Gateway, das daraufhin eine Funktion aufruft, die auf die Datenbank zugreift, die nötigen Informationen abruft und sie an den Endnutzer zurückschickt. Diese Funktionen laufen so lange, bis das Ergebnis vorliegt. Da sie zustandslos sind, werden die Daten in einer Datenbank oder Speicherschicht abgelegt.

Ein Beispiel: Ein neuer Nutzer registriert sich in einem E-Commerce-Shop. Diese Anfrage ruft eine API auf, die wiederum eine Funktion zum Anlegen des Kontos startet, welche auf die Kundendatenbank zugreift. Diese Funktion zum Anlegen des Kontos ist die Function as a Service – eine einzelne Aufgabe aus der größeren Anwendung.

Functions as a Service oder FaaS ist damit eine Computing-Plattform, auf der Sie Ihre Funktionen beziehungsweise einzelnen Bausteine Ihrer Anwendung in einer Cloud-Umgebung ausführen können; sie wird auch als Serverless bezeichnet.

Warum wird Serverless als neue Deployment-Plattform so beliebt?

Pay as you go

Da sich der Cloud-Anbieter um CPU, Arbeitsspeicher, Netzwerk und Ähnliches kümmert, entstehen in einer serverlosen Umgebung keine Grundkosten.

Abgerechnet wird nach den ausgeführten Funktionen, also nach Zeit und Speicher, die für die Ausführung nötig sind. Werden keine Funktionen ausgeführt, entstehen auch keine Kosten.

Weil der Cloud-Anbieter Hardware, Netzwerk, Betriebssystem und Ausführungsumgebung verwaltet, fallen keine direkten Kosten für Verwaltung und Wartung der Umgebung an.

Skalierbarkeit

Steigt die Zahl der eingehenden Anfragen, steigt die Zahl der ausgeführten Funktionen. Umgekehrt gehen die Ausführungen drastisch zurück, sobald die Anfragen nachlassen. Das geschieht automatisch, ohne externe Eingriffe wie das Herunterfahren von Servern, VMs oder Containern.

Polyglott

Da die Funktionen unabhängig voneinander sind, können sie in beliebigen Programmiersprachen geschrieben werden. Vor der Wahl einer Sprache sollten Sie allerdings Kosten, Ausführungszeit, verfügbare Bibliotheken, Verbindungszeiten zu Datenbanken und Startzeiten berücksichtigen.

Hochverfügbar

Da eine Function-as-a-Service-Plattform in verschiedenen geografischen Regionen verfügbar ist, lässt sie sich dort ohne zusätzliche Kosten ausrollen. Damit ist FaaS von Haus aus hochverfügbar.

Anwendungen lassen sich leicht aktualisieren

Das ist ein wesentlicher Unterschied zwischen Functions as a Service und Containern: Container verarbeiten typischerweise viele Anfragen gleichzeitig, Functions as a Service dagegen nur eine Anfrage pro Funktion. Das erleichtert das Ausrollen von Anwendungsupdates.

Sehr sichere Umgebung

Da der Cloud-Anbieter sämtliche Schichten des darunterliegenden Stacks verwaltet, erfolgt der Zugriff ausschließlich über Konfiguration und Autorisierung. So wird jeder Zugriff auf Sicherheitsverletzungen hin überwacht.

Wie andere Deployment-Modelle hat auch FaaS ein paar Grenzen.

Treten Fehler auf oder bricht eine Funktion ab, ist die erzeugte Anfrage verloren, da die nächste Funktion zu laufen beginnt – allerdings ohne Beeinträchtigung der Anwendung.
Da die Anwendungen in der serverlosen Umgebung nicht dauerhaft laufen, muss die Umgebung immer erst starten, wenn die erste Anfrage den Endpunkt erreicht. Schlecht umgesetzt führt das zu Verzögerungen und langsamen Antwortzeiten.
Richtig umgesetzt lassen sich kalte Funktionen jedoch in weniger als 100 ms ausführen. Die folgende Anfrage läuft deutlich schneller, weil die Funktion bereits gestartet ist und rund 15 Minuten auf die nächste Anfrage wartet. Kommt in diesen 15 Minuten keine Anfrage, ist für die Wartezeit nichts zu zahlen.
Wenn Sie mit einem Anstieg der Anfragen rechnen, können Sie einige Funktionen vorab initialisieren, sodass sie für die kommenden Anfragen aufgewärmt sind. Das lohnt sich nur für latenzkritische Workloads, denn der Pool aufgewärmter Funktionen muss bezahlt werden.
Da in einer solchen Umgebung kein manuelles „Nachjustieren“ möglich ist, sollten alle Deployment- und sonstigen Prozesse mit Infrastructure-as-Code-Werkzeugen automatisiert werden.

Fazit

Der einzige Grund für die Entwicklung von der serverbasierten zur serverlosen Umgebung waren Skalierbarkeit und die Geschwindigkeit, mit der der Server Client-Anfragen verarbeitet. Ein wettbewerbsintensives Geschäftsumfeld verlangt nach einem wettbewerbsfähigen Server, der blitzschnell arbeitet und möglichst wenig Aufwand für das Infrastrukturmanagement lässt.

Genau das bietet eine serverlose Umgebung beziehungsweise Functions as a Service: eine schnellere, funktionsbasierte Umgebung, die Funktionen zügig ausführt, bis die gewünschte Nutzeranfrage erfüllt ist. Für ein wachsendes Unternehmen ist diese Plattform der beste Weg.