Serverless Architecture, der neue Trend

Die Industrie hat gerade erst kürzlich den letzten größeren architekturellen Hype durchgemacht. Das Aufteilen traditionell monolithischer Applikationen in Microservices und das Betreiben dieser in der Cloud ist ein großer Schritt in eine neue Welt. In dieser neuen Welt scheint alles unendlich skalierbar und modularisierbar. Nun soll es aber jenseits dessen, in Form der Serverless Architecture, noch einen Schritt weiter gehen. Dieser Blog-Post beschäftigt sich mit den grundlegenden Fragen: was ist eigentlich Serverless und welche Vor- und Nachteile hat es?

Was ist eigentlich Serverless?

Eine Serverless Architecture, anders als der Name vermuten lässt, verwendet immer noch Server. Allerdings befinden sich diese fest unter der Kontrolle und damit auch im Verantwortungsbereich eines Cloud-Dienstes. Serverless ist wie viele Trends in der Software Industrie noch nicht hinreichend definiert. Nun lassen sich allerdings zwei Begriffe relativ direkt damit in Verbindung bringen: Mobile Backend as a Service (MBaaS) und Function as a Service (FaaS).

Bevor wir zu den Details dieser beiden Ansätze übergehen, wollen wir uns zunächst einmal anschauen, wie sich diese generell von den aktuellen Standards der Software-Industrie unterscheiden. Das Everything as a Service-Modell beschreibt verschiedene Ebenen der Dienste, die ein Cloud Anbieter übernimmt. Diese reichen von Infrastructure as a Service (IaaS), über Platform as a Service (PaaS) zu Software as a Service (SaaS). In der Reihenfolge der Nennung sinkt hierbei der Anteil an Entwicklungs- und Administrationsaufwand. Gleichzeitig sinkt jedoch auch die Kontrolle der Entwickler über die von den Services abgedeckten Bereiche. Serverless lässt sich hierbei relativ mittig zwischen PaaS und SaaS einordnen, während MBaaS in Richtung SaaS und FaaS in Richtung PaaS ausschlägt.

Anfangs tauchte der Begriff Serverless hauptsächlich im Kontext von Mobile Backend as a Service auf. Dieses speziell für mobile Anwendungen und Single-Page-Applikationen/Rich-Clients verwendete Architekturmuster beschreibt das Bestreben, sämtliche Backend-Aufgaben an Dritte zu outsourcen. Beispielsweise könnte mithilfe von Geolokalisationsdiensten und Wetterdiensten in der Cloud eine Anwendung zur Vorhersage des Wetters gebaut werden, die keinerlei eigens betriebene Server benötigt. Durch den Verzicht auf ein individualisierbares Backend verlagert sich sämtlicher Individualcode entsprechend in den Client.

Neuerdings steht der Begriff Serverless eher als Synonym für Function as a Service. Bei FaaS handelt es sich um vollständig in der Cloud ausgeführte Funktionen (in Form von selbstgeschriebenem Code). Diese werden durch Events oder gegenseitige Aufrufe ausgeführt. Der Entwickler hat hierbei keinerlei Einfluss auf die Infrastruktur, die Ressourcen oder die Laufzeitumgebung, die für die Ausführung der Funktion benutzt werden. Die Funktionen sind darüber hinaus sehr kurzlebig. Das bedeutet, eine Instanz einer Funktion existiert ggf. nur für einen einzigen Aufruf und wird danach terminiert. Eine Funktion sollte idealerweise eine kleinstmögliche Einheit sein, um eine bestimmte Aufgabe auszuführen. Das kommt uns aus dem Grundgedanken der Microservices sehr bekannt vor.

Warum Serverless?

Die vollständige Loslösung vom Management der Ressourcen, Infrastruktur, Error-Handling usw. nimmt den Entwicklern viel der nicht domänenspezifischen Arbeit ab. So können sie sich rein auf die Business-Logik der Funktionen konzentrieren. Damit sinken nicht nur die Entwicklungskosten (vor allem bei MBaaS), sondern auch Wartungs- und Administrationskosten.

Einer der größten Vorteile und Grund für den Hype um das Thema ist, dass horizontale Skalierung bei einer FaaS Anwendung vollständig und automatisch vom Cloud-Anbieter übernommen wird. Sollten sich Zugriffsspitzen ergeben, werden einfach mehr Instanzen der benötigten Funktionen hochgefahren und danach wieder terminiert. Deshalb sollten die Funktionen bereits mit Rücksicht auf Skalierung und Parallelisierung entwickelt werden.

Durch die Kurzlebigkeit der Funktionen kann sich eine Anwendung, die rein aus Cloud-Funktionen besteht, bei ausbleibenden Aufrufen bis auf Null herunterskalieren. Solange es keine entsprechenden Aufrufe gibt, existieren auch keine Instanzen der Funktionen. Folglich entstehen weniger bis keine Kosten.

Probleme

FaaS-Funktionen werden grundsätzlich als zustandslos bezeichnet, sprich sie haben keinen lokalen Zustand in Form von instanzübergreifenden Variablen. Dies ist nicht ganz zutreffend, da es durchaus in sequenziellen Exekutionen einer Funktion einen internen Zustand geben kann. Dieser ist allerdings nicht sonderlich zuverlässig, da durch die kurzlebige Natur der Funktionen nicht garantiert ist, dass mehrere Ausführungen einer Funktion im selben Kontext stattfinden. Ein konsistenter Zustand oder instanzübergreifender Kontext muss extern, das heißt außerhalb der Funktionscontainer, gespeichert werden, von wo er dann während der Laufzeit der Funktion abgerufen werden kann.

Funktionen, die nicht auf einen Zustand zurückgreifen müssen, um aus ihrem Input einen Output zu generieren, sind davon nicht betroffen. In speziell für FaaS-Szenarien entwickelten Funktionen sollte eine solche Zustandslosigkeit angestrebt werden. Derart grundlegende Einschränkungen gestalten sich beispielsweise bei der Migration von existierendem Code meist schwierig.

Da die FaaS-Funktionen immer noch eine Laufzeitumgebung brauchen, kommt es hier zu ggf. hohen Latenzen, bis diese bereitgestellt werden kann. Wird eine neue Instanz einer Funktion benötigt, so kann diese ggf. eine bereits existierende Laufzeitumgebung einer zuvor ausgeführten Instanz der Funktion benutzen. Sollte kein “warmer” Container vorhanden sein, muss bei einem Cold-Start ein neuer Container hochgefahren und eine neue Umgebung für die Funktion eingerichtet werden. Dies kann entsprechende Schwankungen bei Funktionsaufrufen zwischen Millisekunden und mehreren Sekunden bedeuten. Je höher die Frequenz von Anfragen, die eine Funktion aufrufen, desto mehr warme Container gibt es. Folglich fällt die durchschnittliche Start-Latenz drastisch.

Darüber hinaus gibt es, zumindest bei den großen Anbietern (AWS, Google und Microsoft), eine Begrenzung der Laufzeit von Funktionen. Sollten diese nach beispielsweise fünf Minuten kein Ergebnis liefern, wird die Funktionsinstanz terminiert. Dies bringt Einschränkungen für komplexe Prozesse mit sich, welche dann in Sub-Funktionen geteilt oder anderweitig ausgelagert werden müssen.

Das Tooling für solche Serverless-Anwendungen ist noch nicht ausgereift. Dies bringt entsprechende Probleme für die Testbarkeit, Debugging, allgemeine Wartbarkeit und Entwicklungsgeschwindigkeit mit sich.

Durch die Wahl eines Cloud-Anbieters bindet man sich voraussichtlich sehr stark an dessen Plattform. Dies begründet sich darin, dass viele Dienste innerhalb der Plattform über anbieterspezifische Schnittstellen zur Verfügung gestellt werden und sich die Plattformen ggf. sehr eigen verhalten. Anbieterübergreifende Open Source Projekte könnten eine Lösung für dieses Problem bieten.

Fazit

Serverless ist ein interessantes Feld mit viel Potential. Wie mit allen jungen Trends gibt es noch einige Probleme. Es sind jedoch nicht alle diese Probleme auf das frühe Stadium der Technologie zurückzuführen. Nicht jeder Deckel passt auf jeden Topf und so gibt es auch für eine Serverless-Architektur passende und unpassende Anwendungsfälle.

Short URL for this post: https://wp.me/p4nxik-3r4
This entry was posted in Java Runtimes - VM, Appserver & Cloud and tagged , , , . Bookmark the permalink.

Leave a Reply