Ein Frontend in der Cloud mit Serverless Computing umsetzen
Frontends von Anwendungen wandern immer öfter in die Cloud. Entwickler sollten beachten, wie sich Serverless Computing und ähnliche Modelle auf Leistung und Kosten auswirken.
Statt eine komplette Cloud-Migration zu starten, können Unternehmen auch nur das Frontend einer Anwendung in die Cloud verlagern. Dafür haben sie verschiedene Methoden zur Wahl, unter anderem Container und Serverless Computing.
Es ist keine neue Idee, Frontends für den Onlinezugriff auf Webservern zu hosten. Gleiches gilt für die Integration von Webseiten mit gehosteten Prozessen – das Common Gateway Interface (CGI) ist seit Jahrzehnten in Gebrauch. Mit Frondends, die für die Cloud entwickelt wurden, lassen sich jedoch Präsentations- oder GUI-Funktionen (Grafic User Interface, graphische Benutzeroberfläche) in der Cloud hosten. Das verbessert die Skalierbarkeit, Belastbarkeit und Leistung und erlaubt eine flexible Platzierung des Backend der Anwendung.
Man kann dieses hybride Modell wie gehabt über einen Webserver- und ein CGI umsetzen. Doch moderne Cloud-Technologien bieten bessere Möglichkeiten. Mit Serverless Computing und Microservices können Anwender den Overhead und die Kosten für den Betrieb ihres Frontend senken und gleichzeitig die Flexibilität und Skalierbarkeit der Anwendungen erhöhen.
Modernisierungsdruck
Typische moderne Frontends sind über einen API-Gateway oder Broker angebunden. Der Broker besteht aus einer Reihe von APIs, die entweder von Webseiten oder von mobilen Anwendungen aus aufgerufen werden. Diese APIs können entweder mit Webservern verbunden sein oder direkt von Webseiten über eine Programmiersprache, wie zum Beispiel JavaScript, aufgerufen werden. Über die APIs erreichen die Anfragen die Softwarekomponenten der Anwendungen, die in der Cloud oder im Rechenzentrum gehostet werden.
Obwohl dieses Frontend-Cloud-Computing-Modell erst in den letzten zwei Jahren Fuß gefasst hat, gibt es bereits Modernisierungsdruck. Aktuelle Frontend-Designs verwenden Microservices. Eine Möglichkeit zu deren Umsetzung ist Serverless Computing, bei dem Anwendungen nur Ressourcen verbrauchen, wenn ihr Code ausgeführt wird.
Durch die Kombination dieser beiden Technologien wird das Frontend vollständig skalierbar und gegen Ausfälle abgesichert. Der Aufwand für die Serververwaltung entfällt und der Cloud-Client zahlt nur für aktives Hosting – bei geringer Aktivität ist das günstiger, als die Anwendung dauerhaft laufen zu lassen.
Transaktionen und Ereignisse
Bei Microservice- und Serverless-Designs geht es um Ereignisse, während andere Anwendungsdesigns um Transaktionen herum aufgebaut sind. Wollen Entwickler ein Frontend über Microservices und Serverless Computing umsetzen, müssen sie also ihre Transaktionen in Ereignisse übersetzen.
In einer typischen Anwendung erstellen Benutzer in einem mehrstufigen Prozess eine Transaktion. Die einzelnen Schritte der Transaktion entsprechen Ereignissen. Jedes Ereignis muss irgendwo in den transaktionalen Kontext eingehen. Entwickler für Microservices und Serverless Computing zerlegen eine Transaktion üblicherweise in Ereignisse an der Quelle, das heißt auf dem Mobilgerät oder Webserver.
Das API-Gateway-Modell eignet sich für eine serverlose Implementierung. Das Gateway kann auf einen Aufruf des Frontend-Webservers oder der mobilen Anwendung hin den richtigen Serverless-Code aufrufen. Das Frontend kann auch auf eine Onlinedatenbank zugreifen, zum Beispiel für die Auftragserstellung. Das löst dann einen Workflow aus, um den verarbeiteten Auftrag – zum Beispiel für die Bestandsverwaltung – an die Backend-Anwendung zu übertragen.
Einige Frontends sind sehr umfangreich und ähneln eher einer verteilten Verarbeitungsfunktion. Bei diesen Designs können Cloud-Entwickler Werkzeuge zur Workflow-Orchestrierung – wie AWS Step Functions oder Microsoft Azure Durable Functions – verwenden, um komplexe Workflows mit mehreren serverlosen Funktionen zu erstellen. Diese Workflows ähneln der traditionellen Anwendungslogik, außer dass sie in Microservices zerlegt werden, um den Nutzen der Cloud zu maximieren.
Microservices, Serverless und Container
Die großen Cloud-Anbieter ermöglichen es, leicht zwischen einer Serverless-Bereitstellung mit Microservices und einer stets verfügbaren Containerbereitstellung zu wechseln. Microsoft konzentriert sich vermehrt auf die Bereitstellung von Microservices, AWS und Google ermöglichen dies jedoch ebenfalls.
Anwendungsteams sind gut beraten, eher aus der Perspektive Microservices und nicht Serverless Computing an die Sache heranzugehen. Die Microservice-Architektur umgeht ein bekanntes Problem mit Serverless Computing: Serverless ist nur dann kosteneffektiv, wenn es sparsam eingesetzt wird. Kunden ohne Server zahlen für die Nutzung, so dass bei einer hohen Zahl von Anfragen die Kosten höher sein könnte, als für ein dediziertes, immer eingeschaltetes Container-Hosting.
Wer erwägt, einige Serverless Microservices in persistente Container umzuwandeln, sollte vorab klären, wie dieser Prozess bei verschiedenen Cloud-Providern umgesetzt ist, bevor er sich auf einen Anbieter oder ein Orchestrierungs-Modell festlegt.
Zustände sind ein wichtiger Gesichtspunkt beim Erstellen von Serverless-Anwendungen, insbesondere wenn die Möglichkeit besteht, dass die Anwendung später zu einem traditionellen Cloud-nativen Hosting in Containern wechseln könnte. Microservices und Serverless-Funktionen sind zustandslos. Sie können zwischen den Aktivierungen keine Informationen speichern. Deshalb eignen sie sich dafür, auf Abruf aktiviert, skaliert oder ausgewechselt zu werden. In der Folge benötigen Anwendungen mit mehreren Schritten, die wiederum Informationen aus vorherigen Schritten brauchen, eine zusätzliche Lösung zum Speichern des Zustandes.
Es gibt mehrere Möglichkeiten, den Zustand mit dem API-Gateway-Modell eines Cloud Frontends herzustellen. Das Abrufen des Zustandes kann eines der Ereignisse sein, die der Webserver oder das Mobilgerät bei einer Anfrage auslöst. Dabei kann der API-Gateway den Zustand speichern und wieder abgeben. Oder die Statusinformation wird aus der Backend-Datenbank gezogen, die den Kontext für jede Benutzertransaktion speichert.
Eine weitere Methode zum Erhalt von Zuständen ist die Orchestrierung über interne Prozesse oder Workflow Maps. Dafür muss zunächst sichergestellt werden, dass der Cloud Provider solche Maps für Microservices in Containern anbietet. Wer erwägt, einige Serverless Microservices in persistente Container umzuwandeln, sollte vorab klären, wie dieser Prozess bei verschiedenen Cloud-Providern umgesetzt ist, bevor er sich auf einen Anbieter oder ein Orchestrierungsmodell festlegt.
Man sollte seine Serverless Workflows genau prüfen. Serverless-Komponenten laden erst beim Aufruf und verbleiben ansonsten inaktiv. Das bedeutet eine Verzögerung zwischen Aufruf und Ausführen. Zu viele Serverless-Elemente in einem Workflow können sich zu einer spürbaren Verzögerung bei der Reaktionszeit addieren. Dieses Problem lässt sich in Containern vermeiden.
Das serverlose Hosting-Modell eignet sich für viele Frontends, aber es gibt auch viele Anwendungen, die kostengünstiger und sogar leistungsfähiger sind, wenn sie anders aufgebaut sind. Es lohnt sich daher, für Anwendungen vorab Workflow Maps zu erstellen und auf dieser Basis zu entscheiden, ob Serverless Computing sich eignet oder das Frontend besser in einem Container laufen sollte.
Nicht immer ist die neueste Technik auch die geeignete.
