![](\"https:\/\/lh5.googleusercontent.com\/hnARrH3Mz7d41IhTltMgTCpuUfKpg8k6ur_0Ir46moShZzCf53cVBMeUogOFgp2yD-maHIuCu3CIOsnqE_oBCOrEEaB-KfPc8lsQ5jWanA8hFVPvMdC5XYLBboHJ_lUbrtMT5aVqtMNUjTbsLQQNuoM\")
<\/p>\n\n\n\nDie \u201cCloud\u201d ist ein Begriff, der in den letzten Jahren immens an Bedeutung gewonnen hat. H\u00e4ufig wird sie f\u00fcr die Bereitstellung von Diensten und Services genutzt. Im Lauf der Zeit haben sich dabei verschiedene Architekturen entwickelt, die in der Cloud eingesetzt werden und unterschiedliche Ans\u00e4tze f\u00fcr die Handhabung des Codes der Entwickler und die Anfragen von Nutzern haben. Eine davon ist die sogenannte Serverless-Architektur. Doch wie genau funktioniert dieser Ansatz, welche Vor- und Nachteile bietet er und handelt es sich dabei um die Zukunft der Cloud-Entwicklung?<\/p>\n\n\n\n
Wie bereits erkl\u00e4rt handelt es sich bei Serverless (auf deutsch serverlos) um eine Architektur zur Entwicklung von Anwendungen in der Cloud. Der Name l\u00e4sst vermuten, dass es bei diesem Ansatz darum geht, auf die Verwendung von Servern zu verzichten. Ganz ohne Server funktioniert es nat\u00fcrlich nicht, da die Anwendung und Services trotzdem \u00fcber das Internet (und damit \u00fcber irgendeine Art von Server) f\u00fcr die Nutzer erreichbar sein m\u00fcssen.
<\/p>\n\n\n\n
Das \u201cServerlose\u201d bezieht sich darauf, wie die Entwickler mit der Cloud umgehen und mit ihr interagieren. Denn im Gegensatz zum klassischen Cloud-Computing muss sich das Entwicklerteam hier keine Gedanken \u00fcber die Bereitstellung der Anwendung f\u00fcr die Nutzer, die Skalierung oder die Verwaltung des Codes machen. Diese Aufgaben \u00fcbernimmt alle der Cloud-Anbieter und folgt damit ein bisschen dem Prinzip \u201caus dem Auge aus dem Sinn\u201d, da die Entwickler ihren Code nur hochladen m\u00fcssen und sich danach keine, bzw. nur noch wenige Gedanken mehr machen m\u00fcssen.<\/p>\n\n\n\n
Man unterscheidet dabei zwischen BaaS (Backend-as-a-Service) und Faas (Function-as-a-Service). Die zwei M\u00f6glichkeiten differenzieren, was genau der Cloud-Anbieter bereitstellt.
Bei BaaS kann man auf bereits vorhandene Dienste zur\u00fcckgreifen, die der Cloud-Anbieter schon im Repertoir hat. AWS Amplify beispielsweise erm\u00f6glicht es den Entwicklern, einfach Datenbanken, Authentifizierung, etc. nach ihren W\u00fcnschen zu konfigurieren und einzubauen.
Bei FaaS wird auf diese Art der Drittanbieter-Services verzichtet und die Entwickler schreiben ihre Logik und System selbst. Statt das Ganze dann auf einem eigenen Server laufen zu lassen, wird der Code bei dem Cloud-Anbieter hochgeladen, der diesen dann verwaltet. Je nach Bedarf wird dann durch Events der passende Code aufgerufen und ausgef\u00fchrt, ohne dass der Entwickler dies manuell handhaben muss.<\/p>\n\n\n\n
Abb. 1: Monolithische Architektur und Microservice-Architektur [4]<\/em><\/p>\n\n\n\n Zusammenfassend bietet Serverless also wie in Abbildung 1 dargestellt den Zugang zu vordefinierten Services, zu M\u00f6glichkeiten der Datenverwaltung, zu Monitoring \u00fcber das System mit Metriken und Dashboards und nat\u00fcrlich eigene Zugangspunkte, die die Services und Funktionen der Entwickler ausf\u00fchren.<\/p>\n\n\n\n Doch wie sieht der Code, beziehungsweise das gesamte System eigentlich aus, dass so ein Ansatz funktionieren kann? Im Grunde MUSS <\/strong>der Code keine besondere Struktur aufweisen. Serverless bezieht sich lediglich auf die Bereitstellung des Systems \u00fcber einen Cloud-Anbieter, der sich um die Verwaltung dessen k\u00fcmmert und diese Aufgabe von den Entwicklern abnimmt. Abb. 2: Monolithische Architektur und Microservice-Architektur [3]<\/em><\/p>\n\n\n\n Bei einer monolithischen Software-Architektur (Abbildung 2 links) wird das System klassischerweise in ein Frontend, Backend und die Datenbankanbindung unterteilt. Die drei Teile arbeiten eng zusammen und sind stark voneinander abh\u00e4ngig. Sie lassen sich kaum auseinanderziehen oder separieren. Betrachtet man nun eine Microservice-Architektur und l\u00e4sst diese Serverless in der Cloud betreiben, kann man den Nutzen von Serverless gut erkennen: Die einzelnen Services k\u00f6nnen separat voneinander gestartet und ausgef\u00fchrt werden. Die Entwickler definieren eventbasierte Funktionen (siehe \u201cEvent-driven Computing\u201d), um beim Eintreten eines Events den passenden Service zu starten und auszuf\u00fchren. Wenn beispielsweise ein Nutzer nach einem Produkt auf unserer Webseite sucht, wird der Such-Service hochgefahren, dieser durchsucht die Datenbank nach passenden Treffern und gibt diese an das Frontend zur\u00fcck. Nachdem der Service diese Aufgabe erledigt hat, wird er durch den Cloud-Anbieter wieder heruntergefahren, wenn keine weiteren Anfragen hinzukommen.<\/p>\n\n\n\n Zusammenfassend l\u00e4sst sich zu der Funktionsweise von Serverless sagen, dass es sich dabei um eine Architektur oder ein Modell zur Verwaltung und Bereitstellung des Systems \u00fcber einen Cloud-Anbieter handelt. Dieser \u00fcbernimmt Funktionen, wie das Hoch- und Runterskalieren von Services\/Funktionen nach Bedarf durch die Bereitstellung von passender Rechen- und Speicherkapazit\u00e4t, die Wartung der darunterliegenden Hardware und stellt bei Bedarf auch vordefinierte Services bereit. Nun stellt sich die Frage, welche Vorteile der Serverless-Ansatz mit sich bringt und wann es Sinn macht, ihn einzusetzen:<\/p>\n\n\n\n Ihre Vorteile kann die Serverless-Architektur am Besten ausspielen, wenn die daf\u00fcr genutzte Applikation auch auf die genannten Vorteile eingeht. So macht es beispielsweise Sinn, Serverless einzusetzen, wenn man mit sehr unterschiedlichem Verkehrsaufkommen rechnen muss. Hier kann Serverless durch die einfache Skalierbarkeit und auch die dadurch effizientere Kostenverteilung besonders hilfreich sein, da man bei geringem Verkehr nur wenig bezahlt und bei vielen Anfragen diese trotzdem schnell behandeln kann. Nat\u00fcrlich hat Serverless auch seine Nachteile und Probleme, die in diesem Abschnitt aufgegriffen und erl\u00e4utert werden.<\/p>\n\n\n\n Betrachtet man die genannten Vor- und Nachteile von Serverless, so l\u00e4sst sich sagen, dass Serverless durchaus viele relevante Vorteile mit sich bringt, die es als die Cloud-Architektur der Zukunft rechtfertigen w\u00fcrde. Besonders die Einfachheit, die durch die automatische Skalierung erm\u00f6glicht wird und damit gleichzeitig das System kosteng\u00fcnstiger und einfacher bereitzustellen macht, sind wichtige Kriterien. Neben den angesprochenen Aspekten, warum Serverless vermutlich in der Zukunft weiterhin stark vertreten sein wird, sollte man sich auch etwas Gedanken \u00fcber die n\u00f6tige Weiterentwicklung machen. Meiner Ansicht nach ist Serverless besonders f\u00fcr die steigende Anzahl an IoT-Ger\u00e4ten und Applikationen eine optimale L\u00f6sung. Oft bieten diese n\u00e4mlich genau das, was Serverless bereitstellt: Kleine Funktionen und Services, die schnell ausgef\u00fchrt werden, die hochskaliert werden m\u00fcssen und die dadurch dem Entwickler einen kosteng\u00fcnstigen Weg bieten, diese Aspekte umzusetzen.<\/p>\n\n\n\n Ich k\u00f6nnte mir vorstellen, dass viele Systeme aufgrund dieser Einfachheit in die Cloud verlegt werden. Dadurch k\u00f6nnte es m\u00f6glich sein, dass in der Zukunft viele dieser Systeme sich auch untereinander vernetzen. Es entsteht quasi eine gro\u00dfe Welt aus miteinander verkn\u00fcpften Services und Diensten, die auch die Entwicklung neuer Systeme einfacher gestaltet. Denn Cloud-Anbieter werden ihr Repertoir kontinuierlich erweitern und eine immer gr\u00f6\u00dfere Sandbox aus vordefinierten Services erstellen, mit der Entwickler ihre Ideen schnell und einfach umsetzen k\u00f6nnen. [1] What is serverless? https:\/\/www.redhat.com\/en\/topics\/cloud-native-apps\/what-is-serverless<\/a><\/p>\n\n\n\n [2] What is Function-as-a-Service (FaaS)? https:\/\/www.redhat.com\/en\/topics\/cloud-native-apps\/what-is-faas<\/a><\/p>\n\n\n\n [3] The Pros and Cons of a Monolithic Application Vs. Microservices, https:\/\/www.openlegacy.com\/blog\/monolithic-application<\/a><\/p>\n\n\n\n [4] Serverless Architecture \u2013 The What, When and Why https:\/\/www.cloudnowtech.com\/blog\/serverless-architecture-the-what-when-and-why\/<\/a><\/p>\n\n\n\n [5] Serverless vs Microservices: What Should You Choose For Your Product? https:\/\/www.ideamotive.co\/blog\/serverless-vs-microservices-architecture<\/a><\/p>\n\n\n\n [6] Was ist Serverless Computing? https:\/\/www.vodafone.de\/business\/featured\/technologie\/was-ist-serverless-computing\/<\/a><\/p>\n\n\n\n [7] Introduction to Serverless Services https:\/\/blog.camelot-group.com\/2022\/05\/introduction-to-serverless-services\/<\/a><\/p>\n\n\n\n [8] Why Serverless Is the Future of Application Development https:\/\/www.arvato-systems.com\/blog\/why-serverless-is-the-future-of-application-development<\/a><\/p>\n\n\n\n
Es hilft jedoch, das System in einzelne, kleinere Services oder sogar einzelne Funktionen zu unterteilen, die unabh\u00e4ngig voneinander funktionieren, um die Vorteile von Serverless besser nutzen zu k\u00f6nnen. Hier kommt der Vergleich zwischen der traditionellen, monolithischen Software-Architektur und der Microservice-Architektur ins Spiel.<\/p>\n\n\n\n![](\"https:\/\/lh6.googleusercontent.com\/f0XfqN1l2HNLJ17VXSR7Fw4W3ubBV6yrJRZzWq2J4Svjo1OeWbFleNVfJvVIeFbBu-DXKG6dP_fcc-4e8UhNH-zAnVHXpC-9mzWoNkYzY_73bIjfgiKrVVIPMbJmcYm3O1WN23f_RGxWFifX-wE4U_Q\")
Im Gegensatz dazu nutzt die Microservice-Architektur (Abbildung 2 rechts) hinter dem Frontend mehrere, unabh\u00e4ngige Services (daher der Name). Diese k\u00f6nnen auch unterschiedliche Datenbanken verwenden. Mit diesem Ansatz wird die Logik des Backends in kleinere Teile aufgedr\u00f6selt. Besonders wichtig ist dabei die angesprochene Unabh\u00e4ngigkeit. Die Services sind dazu in der Lage, ihre Aufgabe selbstst\u00e4ndig zu erf\u00fcllen, k\u00f6nnen dazu auf ihre Datenbank zugreifen und m\u00fcssen nicht andere Services hinzuziehen. Beispiele f\u00fcr solche Services k\u00f6nnten die Authentifizierung von Nutzern, das Suchen nach Produkten oder das Kaufen von Produkten sein.<\/p>\n\n\n\n
<\/p>\n\n\n\nVorteile<\/h2>\n\n\n\n
\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\nNachteile<\/h2>\n\n\n\n
\n
<\/li>\n\n\n\n
Au\u00dferdem liegen die verwendeten Daten auch nicht mehr bei den Entwicklern selbst auf einem Server, sondern m\u00fcssen dem Cloud-Anbieter anvertraut werden.
<\/li>\n\n\n\n
<\/li>\n<\/ul>\n\n\n\nEvaluierung<\/h2>\n\n\n\n
Nat\u00fcrlich muss man die Abh\u00e4ngigkeit vom Cloud-Anbieter und den Kontrollverlust in Betracht ziehen. Besonders letzteres schlie\u00dft Serverless f\u00fcr manche Unternehmen aus, die den vollen Zugang zu den Servern ben\u00f6tigen und selbst an dem System aktiv arbeiten wollen. F\u00fcr viele Unternehmen er\u00f6ffnet Serverless jedoch eine M\u00f6glichkeit, sich voll und ganz auf die Entwicklung der Anwendung zu konzentrieren.
Wie bei vielen Aspekten ist Serverless ein Angebot f\u00fcr einen Tausch. Man bekommt Effizienz und Kostenersparnis, b\u00fc\u00dft dabei aber Kontrolle und Zug\u00e4nglichkeit ein. Im Endeffekt muss jedes Unternehmen selbst entscheiden, mit welcher Architektur sie arbeiten wollen.
Ich pers\u00f6nlich denke, dass der Ansatz besonders f\u00fcr kleine Unternehmen und Startups eine gute M\u00f6glichkeit bietet, ihr Produkt auf den Markt zu bringen, ohne sich \u00fcber die Verwaltung der Server Gedanken machen zu m\u00fcssen, sondern sich auf ihr Produkt selbst fokussieren zu k\u00f6nnen. Denn besonders f\u00fcr diese Unternehmen ist es sehr aufw\u00e4ndig und vor allem teuer, die ben\u00f6tigte Hardware bereitzustellen und auch funktionst\u00fcchtig und sicher zu halten. F\u00e4llt diese Komponente weg, so k\u00f6nnen mehr Entwickler das tun, was sie wirklich tun wollen und auch k\u00f6nnen, n\u00e4mlich entwickeln und m\u00fcssen sich nicht mehr um die Bereitstellung ihres Systems sorgen.
Dementsprechend halte ich Serverless durchaus f\u00fcr eine Architektur, die die Zukunft weiter mitgestalten wird.
<\/p>\n\n\n\nAusblick<\/h2>\n\n\n\n
<\/p>\n\n\n\nQuellen<\/h2>\n\n\n\n