Serverlose Architekturen sind derzeit ein Trend in der IT-Welt. Die Diskussion dreht sich hauptsächlich um die Vorteile dieses Cloud-Modells, was nicht überrascht, da viele Artikel und Beispiele von Cloud-Anbietern stammen.

Allerdings bergen serverlose Architekturen auch einige Herausforderungen. Wie sehen diese aus und wie lassen sie sich bewältigen? Eine wichtige Voraussetzung für einen erfolgreichen Einsatz ist ein Verständnis der Merkmale und Auswirkungen serverloser Architektur, wie sie im Folgenden von Wisen Tanasa, Lead Developer bei ThoughtWorks, einer internationalen Softwareberatung beschrieben werden.

Niedrige Einstiegshürden

Es ist relativ einfach, bestehenden Code in einer serverlosen Architektur zum Laufen zu bringen. Sich das Wissen zu serverlosen Architekturen anzueignen, ist in vielerlei Hinsicht einfacher, als die typischen DevOps-Kompetenzen zu erwerben. Bei der Einführung einer serverlosen Architektur werden viele DevOps-Elemente nicht benötigt. So sind zum Beispiel Kompetenzen zur Serververwaltung, wie Konfigurations- und Patchmanagement nicht erforderlich. Die Möglichkeit für EntwicklerInnen, sich in serverlosen Projekten schneller auf den neuesten Stand zu bringen, könnte der Grund für eine schnellere Time-to-Market sein.

Etwas komplexer ist es aber doch. Aspekte wie Infrastructure as a Code, Log-Management, Continuous Delivery, Überwachung und gegebenenfalls Netzwerkbetrieb sind nach wie vor unverzichtbar. Software Developer müssen wissen, wie sich diese Prozesse in einer serverlosen Umgebung umsetzen lassen.

Einige EntwicklerInnen sind der Ansicht, dass sie sich in einer serverlosen Architektur nicht mehr mit Softwaredesign befassen müssen. Ihr Argument: Da es nur noch um Funktionen gehe, spiele das Softwaredesign keine Rolle mehr. In Wirklichkeit sind Designgrundsätze wie SOLID nach wie vor anwendbar, da die Wartbarkeit des Codes nicht auf die serverlose Plattform übertragen werden kann. Der Code lässt sich zwar einfach bündeln und zur Ausführung in die Cloud hochladen, dennoch ist dringend davon abzuraten, weil die Methoden der Continuous Delivery auch in einer serverlosen Architektur noch von Bedeutung sind.

 

Kein Host (serverlos)

 Ein Vorteil einer serverlosen Architektur besteht darin, dass die Betriebskosten für die Serververwaltung erheblich niedriger sind. Auch muss man sich keine Gedanken mehr um Server-Upgrades machen, und Sicherheits-Patches werden automatisch eingespielt. Keinen Host (Fußnote) zu haben, bedeutet aber auch, dass andere Arten von Messgrößen in der Anwendung überwacht werden müssen. Dies liegt daran, dass die meisten der zugrunde liegenden Services keine herkömmlichen Messgrößen wie CPU-, Speicher- und Plattengröße bereitstellen. Somit entfällt die Auswertung der systemnahen operativen Details der Architektur.
Aufgrund der andersartigen Überwachungsmessgrößen ist ein Umlernen erforderlich, um herausfinden, wie sich die Architektur optimieren lässt. AWS DynamoDB liefert Angaben zur Lese-/Schreibkapazität, die man verstehen muss, um sie überwachen und optimieren zu können. Dieser Lernprozess lässt sich nicht auf andere serverlose Plattformen übertragen. Außerdem hat jeder verwendete Service seine Grenzen.

Auch wenn Sicherheitspatches automatisch angewendet werden, ist es eine riskante Annahme, dass serverlose Anwendungen sicherer sind. Die klassischen Sicherheitsvorkehrungen greifen nicht, da eine serverlose Architektur andere Angriffsvektoren eröffnet. (Weitere Insights hier: OWASP Serverless Top 10)

 

Zustandslos

Serverlose Architekturen nutzen Function as a Service (FaaS). Dies hat zur Folge, dass im Speicher keine Daten abgelegt werden können, weil die Container, in denen der Code ausgeführt wird, von der Plattform automatisch erstellt und wieder zerstört werden. Somit ist Zustandslosigkeit ein Merkmal serverloser Architekturen.

In Bezug auf die Entwicklung von Anwendungen ist man nicht in der Lage, Technologie zu nutzen, die zustandsbehaftet ist, da die Last der Zustandsverwaltung beim aufrufenden Programm liegt. HTTP-Sessions können beispielsweise nicht verwendet werden, da man nicht über den traditionellen Webserver mit permanenter Datenspeicherung verfügt. Möchte man eine Technologie verwenden, die einen Zustand wie WebSockets erfordert, sollte man warten, bis sie vom entsprechenden Backend as a Service unterstützt wird, oder man wendet den eigenen Workaround an.

 

Elastisch

Eine serverlose Architektur weist außerdem das Merkmal der Elastizität auf. Die meisten serverlosen Services lassen sich elastisch skalieren – von null auf den zulässigen Höchstwert und zurück auf null – und werden dabei größtenteils automatisch verwaltet.

Wenn es um die Skalierbarkeit geht, ist Elastizität von großem Vorteil, da man Ressourcen nicht mehr manuell skalieren muss. Viele Probleme der Ressourcenzuweisung bestehen damit nicht mehr. In einigen Fällen bedeutet Elastizität unter Umständen lediglich, dass genutzte Ressourcen exakt abgerechnet werden. Bei einer geringen Nutzung lassen sich auf diese Weise die laufenden Kosten reduzieren.

Möglicherweise ist es erforderlich, in die serverlose Architektur Legacy-Systeme zu integrieren, die eine solche Elastizität nicht unterstützen. In diesem Fall sind nachgelagerte Systeme eventuell nicht mehr nutzbar, da sie nicht so gut skalierbar sind wie die serverlose Architektur.

Eine hohe Elastizität erschwert zwar Denial-of-Service-Angriffe, dafür besteht jedoch eine höhere Anfälligkeit gegenüber Denial-of-Wallet-Angriffen. Dabei versucht ein Angreifer, durch eine Erhöhung der Ressourcenzuweisung zu erzwingen, dass das Cloud-Konto überzogen wird, und die Anwendung infolgedessen unterbrochen wird. Um solchen Angriffen vorzubeugen, lässt sich beispielsweise ein DDoS-Schutz wie AWS Shield in der Anwendung implementieren. AWS-Budgets bietet zudem eine Benachrichtigung, sobald die Cloud-Kosten den veranschlagten Betrag überschreiten.

 

Verteilt

Aufgrund der Zustandslosigkeit müssen sämtliche Persistenzanforderungen im Backend as a Service (BaaS) bzw. in einer Kombination mehrerer Backend-Dienste gespeichert werden. In einer FaaS-Umgebung sind die Deployment-Units – die Funktionen – kleiner als gewohnt. Infolgedessen sind serverlose Architekturen standardmäßig verteilt, sodass eine Vielzahl von Komponenten ins Netzwerk integriert werden muss. In der Architektur müssen außerdem Services für Authentifizierung, Datenbanken, verteilte Warteschlangen usw. miteinander verbunden werden.

Eine verteilte Architektur verwendet nur eine einzige Region und bietet standardmäßig eine hohe Verfügbarkeit. In einer serverlosen Umgebung greift die Architektur bei Ausfall einer Verfügbarkeitszone in der Region des Cloud-Anbieters auf andere erreichbare Verfügbarkeitszonen zurück, was für EntwicklerInnen nicht transparent ist.

Bei der Wahl der Architektur müssen immer Abstriche gemacht werden. In einer verteilten Persistenzarchitektur verzichtet man zugunsten der Verfügbarkeit auf Konsistenz. Außerdem verwendet jeder serverlose Service in der Cloud normalerweise sein eigenes Konsistenzmodell. Darüber hinaus ist es erforderlich, sich mit dem Verhalten verteilter Transaktionen vertraut zu machen. Die Lernressourcen für den Aufbau verteilter Systeme werden jedoch kontinuierlich verbessert, da Microservices immer beliebter werden.

 

Ereignisgesteuert

Viele BaaS-Services serverloser Plattformen unterstützen grundsätzlich Events. Dies ist bei Services von Drittanbietern nützlich, weil die User damit die Möglichkeit erhalten, die Services zu erweitern – denn auf den Code solcher Services kann nicht zugegriffen werden. Die meisten serverlosen Architekturen verwenden zahlreiche BaaS-Services, sodass die Architektur ereignisgesteuert sein sollte.

Eine ereignisgesteuerte Architektur bringt viele Vorteile mit sich. Die Komponenten der Architektur müssen nur in geringem Maße gekoppelt werden. In einer serverlosen Architektur lässt sich problemlos eine neue Funktion einführen, die Änderungen in einem Blob-Speicher überwacht.

Der Nachteil einer ereignisgesteuerten Architektur besteht darin, dass man möglicherweise die Übersicht über das System als Ganzes verliert. Dies erschwert die Fehlerbehebung des Systems. Es ist daher erforderlich, sich mit einer verteilten Ablaufverfolgung zu befassen, auch wenn dieses Thema im Zusammenhang mit serverlosen Architekturen relativ neu ist. Mit AWS lässt sich der vorgefertigte Service AWS X-Ray unverändert verwenden. Wer an die Grenzen von AWS X-Ray stößt, sollte nach Angeboten von Drittanbietern Ausschau halten, die allmählich verfügbar werden.

 

Fazit

Serverlose Architekturen haben zu einem interessanten Paradigmenwechsel geführt, der viele Aspekte der Softwareentwicklung vereinfacht. Allerdings stellt dieser Paradigmenwechsel TechnologInnen auch vor neue Herausforderungen. Wenn man jedoch einige wichtige Aspekte beachtet, sollte der erfolgreichen Einführung einer serverlosen Architektur nichts im Wege stehen.

 

Quelle Titelbild: iStock / Natali_Mis