Die Zukunft der Software mit Serverless .NET

In der Entwicklung verteilter Systeme stehen zwei Hauptansätze zur Gestaltung von Verarbeitungseinheiten im Vordergrund. Der server-first Ansatz basiert auf vorkonfigurierter Infrastruktur, die vom Entwickler verwaltet wird, sei es eine VM oder ein Container, und läuft typischerweise rund um die Uhr.

Der serverless Ansatz hingegen verlagert die Infrastrukturverantwortung auf den Cloud Anbieter. Anstatt Server oder Container bereitzustellen und zu verwalten, mietet man Recheneinheiten, die man nur bei Bedarf verwendet, und nur für die tatsächliche Nutzung zahlt.

Serverless Einheiten sind der Cloud Funktionen ähnlich. Sie werden nur bei Auslösung gestartet, erledigen die Aufgabe und werden dann wieder heruntergefahren. Das macht Serverless für bestimmte Workloads äußerst kosteneffizient, aber nicht für alle. Beispielsweise können diese Einheiten beim Start eine gewisse Latenz verursachen, was für latenzkritische Systeme unerwünscht ist.

In diesem Artikel geht es um die Kernmerkmale der Serverless Architektur in .NET, populäre Tools wie Azure Functions und reale Kompromisse zwischen serverless und serverbasierten Architekturen.

Was ist Serverless Architektur in .NET?

Wie Serverless mit .NET funktioniert

Eine serverlose Einheit implementiert das Function-as-a-Service Geschäftsmodell (FaaS Modell), was bedeutet, dass wir einen Dienst ähnlich wie einen Funktionsaufruf im Code mieten können. Die Einheit funktioniert, indem der Server hochgefahren wird, um eine Anfrage im Netzwerk anzunehmen, die Antwort an den Client zu verarbeiten und dann wieder offline zu gehen. Daher befindet sie sich im Ruhezustand und es fallen keine Kosten an, bis eine Anfrage eingeht.

Obwohl der Name etwas anderes vermuten lässt, funktioniert Serverless, indem der Cloud Anbieter einen Server verwaltet, auf dem der Funktionscode läuft. Wenn wir beispielsweise einen Dienst wie Azure Functions mit .NET mieten, erhalten wir eine vorkonfigurierte Einheit, um den Quellcode auszuführen. Im Gegensatz dazu müssen wir im server-first Ansatz einen Webserver wie .NET Kestrel konfigurieren und ihn mit dem Quellcode in eine Azure Virtual Machine containerisieren.

Vorteile von Serverless für .NET Anwendungen

Serverlose Funktionen bleiben im Ruhezustand, bis eine Anfrage eingeht. Solange eine Funktion keinen Datenverkehr empfängt, fallen beim Cloud Anbieter keine Kosten an. Dies ist ein großer Vorteil in Architekturen, die Kostenoptimierung priorisieren.

Ein typischer ereignisgesteuerter Workflow kann von der Funktionsweise serverloser Funktionen profitieren, wie etwa in asynchronen Event-Pipelines, bei denen eine Antwort nicht sofort erforderlich ist. In solchen Szenarien können wir Algorithmen entwerfen, die Minuten oder sogar Stunden zur Ausführung benötigen, und die Startzeit der Serverless-Funktion spielt dabei kaum eine Rolle.

Stellen Sie sich beispielsweise eine Machine Learning Pipeline vor, die alle Actionszenen in einem Film identifiziert, um den Nutzern Filme zu empfehlen. Die Validierung, Transformation und Verarbeitung eines Videos kann lange dauern. Zwischenschritte wie Validierung und Input Transformationen könnten daher als Azure Functions umgesetzt werden, ohne das Nutzererlebnis zu beeinträchtigen.

Besonders vorteilhaft ist die .NET Serverless-Architektur, wenn keine Echtzeit Ergebnisse erforderlich sind, da es günstiger ist.

Einschränkungen und Kompromisse von Serverless

Ein Problem bei serverlosen Funktionen entsteht, wenn das System in Echtzeit reagieren muss. Durch den Einsatz von Serverless in solchen Fällen wird der Anfrage durch sogenannte Cold-Starts Latenz hinzugefügt, was die Reaktionszeit verlangsamt und das Nutzererlebnis negativ beeinflusst. Auch wenn die Kosten bei Serverless typischerweise niedriger sind als bei server-first-Ansätzen, lohnt sich das Einsparen möglicherweise nicht, wenn infolgedessen Nutzer die Plattform verlassen.

In Fällen, in denen eine Plattform 24/7 (oder nahezu) einsatzbereit sein muss, ist der server-first Ansatz zuverlässiger, da der Server nicht herunterfährt, wenn kein Traffic eingeht. Dadurch gibt es weniger Startvorgänge und geringere Latenz, was die Kundenzufriedenheit steigert. 

Natürlich ist alles möglich, da eine serverlose Funktion im Backend  einfach ein vom Cloud Anbieter verwalteter Server ist. Das Nutzererlebnis ist bei Business Produkten in der Regel wichtiger als die Cloud Kosten.

Schließlich bietet Serverless nur begrenzte Kontrolle über die Serverkonfigurationen, da wir lediglich eine Funktion aufrufen, um eine Antwort zu erhalten. Im traditionellen server-first-Ansatz können wir nach Bedarf fast alle Server Einstellungen anpassen.

Hybride Serverless Strategien mit .NET

Wie früher erwähnt, gibt es sowohl serverlose Funktionen als auch den server-first Ansatz und es gibt auch Situationen, in denen eine Kombination beider sinnvoll ist. In diesem Abschnitt geht es darum, wie man beide Ansätze zu einer hybriden Serverless Architektur kombiniert, um die Vorteile zu nutzen.

Kombination von Serverless und traditionellen Servern

Serverless ist am besten geeignet, wenn Latenz keine Rolle spielt. Server-first Ansätze reagieren hingegen schneller und sind für latenzkritische Systeme besser geeignet. Viele Geschäftsanwendungen lassen sich als hybride Architektur gestalten, sodass der Endnutzer mit server-first interagiert, während bei Hintergrundaufgaben und Prozessen .NET Serverless Funktionen eingesetzt werden.

Stellen wir uns erneut eine Videostreaming Plattform vor. Unsere Plattform hat zwei zentrale Funktionen: einen Mediaplayer und ein System der Filmempfehlung.

Der Mediaplayer ermöglicht dem Nutzer das Abspielen, Pausieren, Zurück- und Vorspulen. Diese Funktion ist latenzkritisch, da der Nutzer eine sofortige Reaktion erwartet. Das Empfehlungssystem hingegen zeigt dem Nutzer auf dem Startbildschirm weitere Filme basierend auf seinem bisherigen Streaming Verhalten an. Diese Anforderung ist nicht latenzkritisch, da der Nutzer die wichtigen Funktionen auch ohne Echtzeit Empfehlungen nutzen kann.

Technisch gesehen, könnte die erste Funktion mit server-first Ansatz aufgebaut werden, um schneller auf Interaktionen im Mediaplayer zu reagieren. Da keine Startvorgänge nötig sind, ist die Latenz geringer, was das Nutzererlebnis verbessert. Die zweite Funktion hingegen könnte aus mehreren serverlosen Funktionen bestehen, die über Queues miteinander verbunden sind, um die Nutzerdaten asynchron zu verarbeiten und Filme zu empfehlen.

Best Practices für einen hybriden Ansatz

Auch wenn ein hybrider Ansatz von server-first und serverless möglich ist, müssen einige Aspekte besonders beachtet werden, insbesondere Observability und Entkopplung.
Im Hinblick auf Observability ist ein zentrales Dashboard für Metriken sehr wichtig, um den Betrieb von Server und Serverless in verständliche Geschäftsmetriken zu übersetzen. Es ist beispielsweise gut zu wissen, ob der Nutzer den Play Button reibungslos betätigen kann und ob die Empfehlungsalgorithmen korrekt funktionieren.

Außerdem ist es wichtig, die Verantwortlichkeiten zwischen server-first und serverless zu trennen. Nehmen wir an, dass der Media Player Dienst von einem weiteren Dienst B abhängt, der wiederum von einem serverlosen Dienst C abhängt. Auch wenn der Media Player keine serverlose Architektur hat, wirkt sich die Latenz seiner Abhängigkeiten dennoch auf die Nutzererfahrung aus. Daher ist es entscheidend, Server-first und Serverless Workflows in hybriden Architekturen zu entkoppeln.

Serverless Tools und Plattformen für .NET

Nachdem wir uns mit den Unterschieden zwischen Serverless, Server-first und hybriden Architekturen vertraut gemacht haben, betrachten wir nun die verfügbaren Tools für diese Architekturen.

Azure Functions und Durable Functions

Zuerst schauen wir uns Microsoft-eigene Azure Funktionen an. Azure Functions sind serverlose Einheiten mit integrierter .NET Kompatibilität und daher eine gute Wahl für Teams, die bereits .NET einsetzen.

Durable Functions ermöglichen es Entwicklern, zustandsbehaftete serverlose Funktionen zu erstellen. Das bedeutet, dass die Funktion einen internen Zustand beibehält und nicht nur eine Ausgabe aus einer Eingabe erzeugt. Das ist in asynchronen Workflows wie async HTTP APIs hilfreich.

Microsoft hat letztes Jahr Maßnahmen ergriffen, um die Cold Start Zeit von Azure Functions zu verkürzen und die Latenz um 53% zu senken.

AWS Lambda für .NET

Eine weitere Option sind AWS Lambda-Funktionen mit .NET SDKs. AWS bietet native Kompatibilität für .NET Core Anwendungen. Für .NET 6 oder höher erfolgt die Integration der .NET über eine angepasste Laufzeit oder ein Container Image.

Für Teams, die AWS aktiv einsetzen, ist dies eine gute Option, da es nahtlos mit verschiedenen AWS Cloud Diensten wie Route 53, S3 und DynamoDB kompatibel ist. Die Einrichtung kann jedoch für .NET Anwendungen komplexer sein als bei Azure.

Google Cloud Run Functions

Google hat kürzlich Integration mit .NET in seinen Cloud Run Serverless Funktionen hinzugefügt und ist damit ein weiterer Wettbewerber im Serverless Markt.

Nachfolgend eine Tabelle mit einigen Aspekten der Serverless Funktionen von AWS, Azure und GCP, um die beste Wahl für Ihre Architektur zu treffen.

Fazit

Die Wahl zwischen serverbasierter und serverloser Architektur ist ein vielschichtiges Thema. Es ist entscheidend, beide Ansätze genau zu analysieren, um typische Architektur Fehler zu vermeiden.

In diesem Artikel haben wir die Unterschiede zwischen serverbasierten und serverlosen Architekturen an konkreten Beispielen gezeigt. Außerdem haben wir gängige Tools vorgestellt, mit denen sich serverlose Architekturen umsetzen lassen.

Doch das reine Verständnis reicht nicht aus – entscheidend ist, auch funktionale und skalierbare Lösungen mit diesen Technologien zu entwickeln. Deshalb kann es äußerst hilfreich sein, einen erfahrenen und zuverlässigen Partner wie Chudovo an der Seite zu haben. Das Unternehmen arbeitet mit den besten 1 % der .NET Entwickler auf dem Markt zusammen und realisiert Architekturen und .NET Anwendungen, die zahlreiche Unternehmen zum Erfolg gebracht haben.