Serverlos für Anwendungen: Architektur in der Praxis

serverless zu verstehen ist eine Sache. Es gut umzusetzen ist etwas ganz anderes. Viele Menschen, die das Konzept annahmen, stellten nebenbei fest, dass die versprochene Erleichterung mit schwierigen Entscheidungen einherging, die niemand erwähnt hatte.

Der Abstand zwischen dem serverlosen der Folien und dem serverlosen Produktionscode ist der Punkt, an dem Teams verletzt werden. Nicht weil die Technologie schlecht ist, sondern weil sie eine Denkweise erfordert, die nur wenige entwickeln, bevor sie bereits in Schwierigkeiten geraten.

Dieser Text richtet sich an diejenigen, die sich entschieden haben, mit serverless zu bauen und es richtig machen wollen. Lassen Sie uns über die tatsächlichen Designentscheidungen, die Fallstricke, die bei der Implementierung auftreten, und die Disziplin sprechen, die eine solide Architektur von einem Durcheinander schwer zu wartender Funktionen trennt.

Die trügerische Leichtigkeit des Anfangs

Serverless hat einen verführerischen Anfang. In wenigen Minuten laden Sie Ihre erste Funktion hoch, sie reagiert und es scheint, als wäre alles so einfach. Da liegt die Falle.

Das Problem besteht nicht darin, eine Funktion zu schreiben. Es geht darum, fünfzig Funktionen zu schreiben, die miteinander kommunizieren, die Logik teilen, auf Daten basieren und sechs Monate später von einem Team verstanden werden müssen. Die Komplexität verschwindet nicht mit serverlos. Es wechselt den Standort, verlässt die Infrastruktur und wendet sich der Architektur zu.

Wer dies nicht erkennt, baut einen sogenannten „verteilten Monolithen“: alle Nachteile eines verteilten Systems, ohne die Vorteile eines durchdachten Designs. Es ist die schlimmste aller Welten und kommt häufiger vor, als Sie vielleicht denken.

Die These: Serverlos erfordert mehr Design, nicht weniger

Hier ist meine zentrale Position. Serverless verzichtet nicht auf Architektur, sondern verlangt mehr von ihr.

Bei der Verwaltung von Servern wird ein Teil der Disziplin durch die Infrastruktur vorgegeben. Sie müssen darüber nachdenken, wie die Teile organisiert sind. Serverless beseitigt diese Zumutung und gibt völlige Freiheit zurück. Und Freiheit ohne Disziplin wird zum Chaos.

Daher ist die gute Implementierung von serverless eine Übung in bewusstem Design. Sie müssen gezielt entscheiden, wie die Verantwortlichkeiten aufgeteilt werden, wie Funktionen kommunizieren, wo der Staat angesiedelt ist und wie alles verständlich bleibt. Wer Serverless als „schnellen Serverless-Code“ betrachtet, erntet in Rekordgeschwindigkeit technische Schulden.

Designentscheidungen, die das Ergebnis definieren

Granularität: Wie klein jede Funktion sein sollte

Die erste schwierige Entscheidung ist die Größe. Zu kleine Funktionen vervielfachen die Komplexität der Kommunikation. Zu große Funktionen verlieren die Vorteile der Modularität und unabhängigen Skalierbarkeit.

Eine gute Faustregel besteht darin, die Rollen nach klaren geschäftlichen Verantwortlichkeiten und nicht nach trivialen Vorgängen zu organisieren. Jede Funktion muss etwas Zusammenhängendes und Verständliches tun. Widerstehen Sie der Versuchung, alles in Mikrostücke zu fragmentieren, denn die Verführung des „extrem Granularen“ endet normalerweise in der Unregierbarkeit.

Status: Wo die Daten tatsächlich gespeichert sind

serverlose Funktionen sind von Natur aus zustandslos. Sie werden geboren, sie werden hingerichtet und sie sterben. Das bedeutet, dass alle Staaten außerhalb von ihnen leben müssen, in Datenbanken, Caches und Speichern.

Dies ist einer der größten Veränderungen in der Denkweise. Sie können zwischen den Läufen nichts im Speicher behalten. Alle Beharrlichkeit ist explizit und äußerlich. Eine gute Gestaltung und Auswahl der richtigen Speicher für jeden Datentyp unterscheidet eine zuverlässige Anwendung von einer Anwendung voller unvorhersehbarem Verhalten.

Kommunikation: Wie die Teile miteinander kommunizieren

In einer echten serverlosen Architektur müssen Funktionen interagieren. Die Entscheidung, wie sie kommunizieren, synchron, indem sie auf eine Antwort warten, oder asynchron, über Ereignisse und Warteschlangen, prägt die gesamte Robustheit des Systems.

Asynchrone Kommunikation über Ereignisse sorgt tendenziell für mehr Ausfallsicherheit: Fällt ein Teil aus, wartet die Nachricht. Aber es erhöht die Komplexität der Nachverfolgung. Synchrone Kommunikation ist einfacher zu verstehen, führt jedoch zu Kopplungen und verbreitet Fehler. Diese Wahl ist nicht von geringer technischer Bedeutung, sondern struktureller Natur.

Ein Beispiel für bewusste Umsetzung

Stellen Sie sich vor, Sie erstellen das Backend einer Liefer-App mit serverless. Der Ablauf einer Bestellung umfasst mehrere Schritte: Validierung, Abrechnung, Benachrichtigung des Restaurants, Nachverfolgung der Lieferung.

Die naive Implementierung würde eine riesige Funktion ergeben, die versucht, alles synchron zu orchestrieren. Ergebnis: langsam, anfällig und unmöglich zu debuggen. Wenn die Benachrichtigung fehlschlägt, bleibt die gesamte Anfrage hängen.

Bewusste Umsetzung trennt Verantwortlichkeiten. Eine Funktion empfängt und validiert die Anfrage und zeichnet sie auf. Dadurch wird ein Ereignis ausgegeben, das unabhängig Abrechnung, Benachrichtigung und Nachverfolgung auslöst. Jeder Teil fällt aus und erholt sich von selbst. Der Bestellstatus befindet sich in einer Datenbank, auf die jeder zugreifen kann.

Der Unterschied zwischen den beiden ist nicht die Technologie. Es ist die Sorgfalt beim Design, bevor die erste Zeile geschrieben wird.

Die Fallstricke der Umsetzung

Die erste Gefahr ist das Debuggen. Wenn in einem System, das sich über Dutzende Funktionen und Ereignisse erstreckt, etwas schiefgeht, ist es schwierig, die Ursache zu finden. Ohne die richtige Verfolgung von Anfang an bleiben Sie blind. Investitionen in Beobachtbarkeit sind keine Option, sondern eine Überlebensbedingung.

Die zweite ist die Konfigurationsexplosion. Jede Funktion hat ihre Berechtigungen, ihre Variablen, ihre Auslöser. Im großen Maßstab wird die manuelle Verwaltung zu einer Fehlerquelle. Die Behandlung der Infrastruktur als Code, versioniert und automatisiert, ist keine Verfeinerung mehr, sondern eine Notwendigkeit.

Das dritte ist die Illusion der Isolation. Funktionen scheinen unabhängig zu sein, haben jedoch dieselben Banken, Warteschlangen und Anbietergrenzen. Eine sich schlecht verhaltende Funktion kann sich auf die anderen auswirken. Das Nachdenken über diese unsichtbaren Abhängigkeiten gehört zum Job.

Disziplin ist die wahre Infrastruktur

Was ich in der Praxis festgestellt habe, ist, dass serverless harte Arbeit nicht eliminiert, sondern verdrängt. Sie hören auf, sich um Maschinen zu kümmern, und beginnen, sich um Design, Kommunikation und Zustand zu kümmern. Wer diszipliniert an die Sache herangeht, für den ist das Ergebnis überzeugend: flexible, skalierbare und kostengünstige Systeme.

Für diejenigen, die es als Abkürzung betrachten, ist das Ergebnis ein Gewirr, das niemand versteht und niemand aufrechterhalten möchte. Die Technologie ist die gleiche. Was sich ändert, ist die Strenge derjenigen, die sie anwenden.

Serverlos ist nicht einfacher. Es ist anders. Und der Unterschied wird durch Design erreicht, nicht durch Eile.

Wenn Sie eine [serverlose 10-Architektur implementieren und die klassischen Fallstricke vermeiden möchten, lohnt es sich, Ihre Meinung zu ändern. Ich habe weitere Artikel auf dem Blog über das Konzept von Serverless, Anwendungsfälle und alltägliche Abläufe, die diese Implementierungsvision ergänzen.